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.

Squall Wrote: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.

Squall Wrote:Seeing as from what I've heard and tested, AR Codes, GSA Codes. and CBA codes are all addable via the Gameshark and Codebreaker buttons.

-Support for custom Qt themes.

Squall Wrote:As it stands, 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.

-An SVG splash startup-background.


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.

Topic stuck.

The splash screen will take up the whole window, won't it? (No, I am not counting in menu bars etc 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. ^^;;

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

Oh, I also had another idea...

An SVG pause overlay.


Mockup:

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...

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

Good idea. I'd be willing to provide artwork if the idea ever gets implemented.

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.

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.

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.

xKiv Wrote: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

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

Squall Leonhart Wrote:

xKiv Wrote: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?

That's why he said "as it is". It would be bad performance to add more GDI objects than necessary.

xKiv Wrote: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.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

Squall Leonhart Wrote:

xKiv Wrote: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 ...

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.

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.

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[i] = reg[i].I;
}

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

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

Quote: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.

Quote: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)

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?