Jump to content
Visual Boy Advance-M
dualscreenman

Qt GUI feature suggestion thread

Recommended Posts

Suggest features for the new cross-platform Qt GUI here!

 

Unimplemented

In progress

Implemented

 

Existing ideas:

-Rom browser that uses a tab system for the individual rom types.

 

-Cheat List dialog screen should be more like No$GBA's.

When adding a cheat it should group them by cheat name instead of the E/D items it should just show on and off.

 

-Cheats should be editable as well, just like NoGBA's.

 

-GSA and CBA should be unified into one button marked as Add Code.

Seeing as from what I've heard and tested' date=' AR Codes, GSA Codes. and CBA codes are all addable via the Gameshark and Codebreaker buttons.[/quote']

 

-Support for custom Qt themes.

As it stands' date=' the QT apps I've seen have had issues with showing radio buttons and confirmation button outlines when a non standard windows theme is in use.[/quote']

 

-An SVG splash startup-background.

splash.png

mocksplash-1.png

Note that the above is purely a mockup.

Mudlord suggested a 3D cube with the splash on the sides. :)

 

-Sidebar with common emu functions.

Work on this has already started with the cheat sidebar.

 

-Use Oxygen icons for teh sex valuez.

Integration has already begun.

Share this post


Link to post
Share on other sites

The splash screen will take up the whole window, won't it? (No, I am not counting in menu bars etc :P you know what I mean.) Just having it centered in the middle of a lot of gray space doesn't look so good. I know it's a mockup, and this may be a stupid question, but I wanted to make sure. ^^;;

Share this post


Link to post
Share on other sites

Yeah, it could be resized to show way less window space. I just was lazy and didn't want to for the mockup. :P

 

Oh, I also had another idea...

 

An SVG pause overlay.

pause.png

 

Mockup:

mockpause.png

This way you can easily tell that emulation is indeed paused.

 

It would probably be better to make that configurable if it ever did get implemented, since I can see times when I'd want to pause emulation and get a better look at the screen. Oh! Oh!. Idea! Maybe you could click to hide it...

Share this post


Link to post
Share on other sites

Why not do this for all messages? You could use Amarok-like OSD btw. If you reset for example, the OSD says Reset, looking nice and all :3

Share this post


Link to post
Share on other sites

OSD sounds like a good idea.

However, it is stupid to fill the whole screen with a pause message...

Just a little 50% transparent hint in one of the edges should be enough.

Share this post


Link to post
Share on other sites

You could *also* just make the window a little bit taller and put a scrolling log (history) of messages there ... preferably with a timestamp (and I would appreciate a current time indicator too :).

 

I wanted to do this myself (in the SDL port), but just ended up echoing all messages to STDOUT ...

 

Oh, and as for the "paused" state, I just printed Pause on/Pause off ...

 

This would also solve the "messages hide part of the picture" problem (like when I save/load a state ...). Simply send all the messages to the message window instead of laying them over the emulated screen.

Share this post


Link to post
Share on other sites

I don't like the whole splash screen thing or the pause thing. Too much going on which makes the emulator look unprofessional imo. Why not just have a hidable/showable status bar at the bottom like Nestopia where all of the status messages will go. I don't like the current in-screen red text method of the status messages. It should be separate from the gameplay completely except when it's in full screen mode.

Share this post


Link to post
Share on other sites

You could *also* just make the window a little bit taller and put a scrolling log (history) of messages there ... preferably with a timestamp (and I would appreciate a current time indicator too :).

 

Definitely not, GDI detracts from emulation performance as it is without further adding more gdi objects, VBA already has a logging window, we can improve upon this instead

 

 

Onscreen display is as such for a reason, granted theres no reason to have the cpu info shown in the window when set to windowed mode as the information is already in the title bar, but when in fullscreen, it is good to have an idea of performance levels especially for performance debugging.

 

Consistency between the render modes is to be worked on so that both d3d and opengl have the OSD in the same places, and the same sizes

Share this post


Link to post
Share on other sites

You could *also* just make the window a little bit taller and put a scrolling log (history) of messages there ... preferably with a timestamp (and I would appreciate a current time indicator too :).

 

Definitely not, GDI detracts from emulation performance as it is without further adding more gdi objects, VBA already has a logging window, we can improve upon this instead

...

 

1) How *much* does GDI detract from emulation performance?

2) How does "add (an GUI element)" imply "use GDI" - especially with the SDL or QT port?

 

First approximation: stretch the emulated display surface a bit below what is rendered now + use that new "screen estate" to render log and status messages, similar to the way they are rendered *over* the current display.

The worst problem I see with that approach is filters ... but VBAM already has its own routines for rendering text, right? Just resize (maybe even using the filters) the glyphs when the surface resizes ...

 

Of course, if I didn't have to focus on my diploma thesis, I would have already gone and started coding ... stupid real life :(

 

 

EDIT: besides, you already have your titlebar and menu (at least in the non-SDL ports), no?

Share this post


Link to post
Share on other sites

EDIT: besides, you already have your titlebar and menu (at least in the non-SDL ports), no?

 

the menus will be done via QT's Opengl or D3D acceleration in the qt builds.

Share this post


Link to post
Share on other sites

EDIT: besides, you already have your titlebar and menu (at least in the non-SDL ports), no?

 

the menus will be done via QT's Opengl or D3D acceleration in the qt builds.

 

(anyway, I just noticed this *is* a QT thread ...)

 

Exactly. How much harder than this (menus) is one scrolling window?

 

Performance: (GUI) code executes (*should* execute) only when user clicks on a GUI element (a slight slowdown doesn't matter when the user is not paying attention; this case *also* covers moving windows about, swithching virtual desktops, etc ...), or when a message is added

VS

currently: as far as I can tell, screenMessage is rendered *for every (non-skipped) frame* (unless it is empty).

 

 

And I don't believe that the performance penalty (even with GDI) would be worse than playing MP3s in the background ...

(which I do AND I don't notice any slowdown AND my computer is way old)

 

No hard evidence here, though - one of those days, I need to get off my back and build QT4 itself ...

Share this post


Link to post
Share on other sites

Okay, I started some prelim support for directories in the Qt4 GUI.

 

What we need, is a push to get emulation running under this GUI system.

 

Any help, as always, is appreciated.

Share this post


Link to post
Share on other sites

Well, I am busy preparing for my final final final exam (the one that will decide whether I get the degree), so maybe I will get a look this Wednesday.

Share this post


Link to post
Share on other sites

Status assessment:

- Final exams: passed. I has university education.

- Free time: at least until end of May.

- Done this day: built Qt4 ... took the whole day :( It is B*I*G

- built VBA-M/Qt: it runs

 

-------

 

Incidentally found a suspicious piece of code (gcc warned me):

[ ifndef FINAL_VERSION, ifdef BKPT_SUPPORT]

in agb/GBA.h

extern int oldregs[17];

extern int oldbuffer[10];

in Globals.cpp:

int oldregs[17];

int oldbuffer[10];

in agb/GBA.cpp, line 3434:

... , oldregs[17] );

int agb/GBA-thumb.cpp, line 3431:

for (i = 0; i < 18; i++) {

oldreg = reg.I;

}

 

Somebody know if this off-by-one (accessing oldreg[17] when it is only defined up to oldreg[16]) is intentional?

Share this post


Link to post
Share on other sites
Somebody know if this off-by-one (accessing oldreg[17] when it is only defined up to oldreg[16]) is intentional?

 

Hmm, thats actually something I didn't look into when I was adding in the new core. I will personally check that out when I can.

 

Forgive the ignorance but which OS is the QT build actually for? Linux?

 

It is built for all OSes, whether its for Linux, MacOSX or Windows.

 

 

(and yes, VBA-M supports MacOSX)

Share this post


Link to post
Share on other sites

Ahh so it's meant to be a universal build?

 

What does the QT actually stand for and other than it's possible universal running ability are there any other differences to the current builds?

Share this post


Link to post
Share on other sites
Ahh so it's meant to be a universal build?

 

If it is done right, it will allow VBA-M to run on any platform the Qt GUI toolkit supports. Which is Linux/Mac/Windows.

 

What does the QT actually stand for

Qt is named after Quasar Technologies, the original name of the company that develops the Qt GUI toolkit.

 

are there any other differences to the current builds?

Well, it allows for a standard GUI across any platform, so, not really. Unless we start using stuff that Trolltech has added to Qt, like their concurrency framework for multithreading.

Share this post


Link to post
Share on other sites

Still, the Qt build is by far not even in alpha state. Development just started some months ago.

Share this post


Link to post
Share on other sites

Well I am more than happy with the current implmentation as I am on Windows so I am not in the least bit bothered by that.

 

It is an interesting concept though I must admit.

Share this post


Link to post
Share on other sites

If it is done right, it will allow VBA-M to run on any platform the Qt GUI toolkit supports. Which is Linux/Mac/Windows.

It's much more than that. Qt works fine on anything that uses X, such as BSD, Solaris, HP-UX, AIX, and more.

 

It also works on Linux Embedded, as well as Windows CE.

 

 

http://trolltech.com/products/qt/features/platforms/desktop

http://trolltech.com/products/qt/features/platforms/embedded

 

You've also already seen Qt used in a bunch of popular applications, such as Google Earth, or Adobe Photoshop something or other.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×