It might not look like much for an outsider, but the new code lays the foundation for much much more to come in the future.

Anyway, here is the very first test build of what aims to be the successor to VisualBoyAdvance in general.

It can load & execute uncompressed gba ROM images and display the graphics. No sound and no input yet.


About the new architecture:
The GBA core communicates directly with graphics/sound output and user input through C++ interface classes.
Core and GUI are strictly seperated.
The GUI controls the Core using an easy to use manager class "CEmuGBA" which should take care of most of the complicated things.
CEmuGBA is currently just a front-end for a slimlined/cleaned GBA core taken from VBA-M, but I aim to incorporate the C code into the manager class and seperate classes.



Runtime DLLs:
You only need to download them once, they will probably only be updated half a year or so. Put them into the folder where vba2.exe resides.
http://code.google.com/p/gbxemu/download...akechanges


VBA2 binary:
http://code.google.com/p/gbxemu/download...akechanges


Source code:
http://code.google.com/p/gbxemu/source/checkout

Is this the rewrite that we've been dreaming about? I'm glad it's getting worked on. I do have concerns with the design of the GUI though. You may want to reconsider the buttons on the left. Actually, I don't even think we need a regular menubar. I once saw this GUI for a PSP emulator.. while I don't know much about the emulator itself, the GUI looked great to me:



It looks pretty much like the perfect GUI for an emulator.. it has all the essentials quickly accessible, while you can change more advanced options without much hassle, and it looks very clean and slick. If you made a GUI like this one, that'd be really awesome. Just a suggestion of mine.

Btw, I see you're using Qt! Awesome.

Quote:Is this the rewrite that we've been dreaming about?

Yes.

Thank you for that pic, you gave me ideas for my emu.

>.> I don't see a problem with the current menu structures, don't want to retard it down to much.

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

Less bloat perhaps?

I like simplicity, you know that

(10-05-2009 03:36 PM)mudlord Wrote:  Less bloat perhaps?

I like simplicity, you know that

Nothing wrong with that, but like... play/pause buttons? This isn't a video player. >.>

I think a media player like GUI is actually suited very well for emulators.

The collection of games can be managed like you manage a bunch of mp3 files.

The game can be compared to a video file, except that you can interact with it (like DVD menues).

Image placement and post-processing are also things a media player does.

Well, some emulators can even record videos.


About that toolbar on the left: I was thinking it might be a good idea to put the controls on the left or right, because on 16:9 monitors, this area won't be used by the GBA screen anyway, because of it's 3:2 aspect ratio.

Well, I can kind of see your point, but I still don't quite like it. I may be biased because of exclusively using 4:3 monitors, though.. I really prefer them. Maybe it could be user-configurable?

Here's today's build:
http://code.google.com/p/gbxemu/download...akechanges

It features basic keyboard input ( keys are Q W A S Y X RIGHT LEFT UP DOWN ).
I also added some pixel-exact only scaling code.


Why does it currently run slower than 60 fps?
I use a timer with an interval of 1000/60=16 ms (it should be 16,66..., but that does not matter for now).
So basically, the timer is triggered every frame and runs the CPU loop for exactly (240+68)*(160+68)*4 = 280896 CPU ticks. If I am not mistaken, this is the amount of CPU cycles available to a real GBA in the time of one frame being drawn to the screen including blanking time.
Concluding from that information, VBA2 currently runs slower than 60 fps because the core is not cycle accurate. Workaround: increase amount of cycles to emulate per frame. Long term fix: make GBA core cycle accurate.

Edit: Maybe I should also check that the Qt timer actually runs at the frequency I told it.

(10-05-2009 06:39 PM)spacy51 Wrote:  I think a media player like GUI is actually suited very well for emulators.

The collection of games can be managed like you manage a bunch of mp3 files.

The game can be compared to a video file, except that you can interact with it (like DVD menues).

Image placement and post-processing are also things a media player does.

Well, some emulators can even record videos.


About that toolbar on the left: I was thinking it might be a good idea to put the controls on the left or right, because on 16:9 monitors, this area won't be used by the GBA screen anyway, because of it's 3:2 aspect ratio.

emulation is not media playing. unless we're adding in a mp3 player..

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

(10-05-2009 10:49 PM)spacy51 Wrote:  Why does it currently run slower than 60 fps?
I use a timer with an interval of 1000/60=16 ms (it should be 16,66..., but that does not matter for now).
So basically, the timer is triggered every frame and runs the CPU loop for exactly (240+68)*(160+68)*4 = 280896 CPU ticks. If I am not mistaken, this is the amount of CPU cycles available to a real GBA in the time of one frame being drawn to the screen including blanking time.
Concluding from that information, VBA2 currently runs slower than 60 fps because the core is not cycle accurate. Workaround: increase amount of cycles to emulate per frame. Long term fix: make GBA core cycle accurate.

Edit: Maybe I should also check that the Qt timer actually runs at the frequency I told it.

Are you counting the number of frames per second and coming up short or is the game just appearing to be emulated too slowly? If it's the former then it doesn't matter how accurate or inaccurate the timing is, your timer loop is taking longer than you think it is. The granularity might not be as good as you expect. If it's the latter.. actually, the emulator would have to be considerably short changing the CPU before you'll notice internal slowdown or crashes in games, and it probably wouldn't be consistent. GBA games are synchronized around vblank signals, so so long as you put them out at 60Hz the game will update at 60fps.

Now, if you're only running the CPU by itself for an entire frame then I'm certain that's not going to work well in general, unless you have a sophisticated logging design that I don't think you do. You need to run it for intervals inbetween external events like scanline updates and timer triggers, or else mid-frame effects and sound won't work.

Hm, my latest test shows, that my QTimer only reaches 37fps, even without any workload to do. So it seems it's not the core's fault. I have to think up something else.

(10-06-2009 12:21 AM)Squall Leonhart Wrote:  

(10-05-2009 06:39 PM)spacy51 Wrote:  I think a media player like GUI is actually suited very well for emulators.

The collection of games can be managed like you manage a bunch of mp3 files.

The game can be compared to a video file, except that you can interact with it (like DVD menues).

Image placement and post-processing are also things a media player does.

Well, some emulators can even record videos.


About that toolbar on the left: I was thinking it might be a good idea to put the controls on the left or right, because on 16:9 monitors, this area won't be used by the GBA screen anyway, because of it's 3:2 aspect ratio.

emulation is not media playing. unless we're adding in a mp3 player..

True, but they have a lot in common. Having a game library akin to a media player library is a wonderful idea, albeit possibly outside the scope of this project. The closest thing that can be found now is external software such as mamewah, which is really more suited for arcade cabinets than regular home PCs, or programs that are really more focused on renaming than launching.