After having a nice chat with blargg on IRC, we both agreed that the current core architecture is like "spaghetti" with all the callbacks and global variables.

Additionally, blargg informed me, that "...maintaing GB emulation seems like a real waste, since Gambatte exists and is probably the most accurate GB emulator."
IMO, there are enough GB emulators out there, but VBA is the ONLY open source GBA emulator.


Having written most of the Qt GUI part until now, I feel like it is useless to rewrite the GUI but leave the core in this state. The current architecture prevents or makes it much harder to run multiple instances of it in different threads, and of course it is anything else than self-explaining how to use the cores.


So guys, what do you think about rewriting the GBA core additionally to the Qt GUI? I know it will be a lot of work, but I think the result would be much more pleasant than the current mess.

While the "mess" you say we need to rewrite may be tedious work but I would say go for it, I may not program much but when I do I like to keep a nice clean look for my code.

(08-26-2008 06:40 AM)spacy51 Wrote:  IMO, there are enough GB emulators out there, but VBA is the ONLY open source GBA emulator.

There's also the new ReasonableGBA, which is really good, and the GBA driver for MESS, which I haven't tried yet.

By the way, VBA-M is the only GBA emulator that works full speed on my crappy computer.

Can't say I find it nicely-sounding (risking to break stuff, along probably with compatibility, in the rewrite doesnt sound like a pleasant thought. While a cleaner codebase is desirable, if functionalty, compatibility or reliability are sacrificed for it...).
Isnt the current state of the core already better than at 1.8 beta3? (other than being a mess, as you say?)

If the code for the current core remains available to be used just in case people prefer using it rather than a rewritten core, why not (if its left experiemental pre-alpha till ready for public testing. People would certainly prefer the betterperforming more reliable core (the internal design architecture does not matter to people other than devs after all, only performance, compatibility and reliability do)

(08-26-2008 07:07 AM)mzk Wrote:  

(08-26-2008 06:40 AM)spacy51 Wrote:  IMO, there are enough GB emulators out there, but VBA is the ONLY open source GBA emulator.

There's also the new ReasonableGBA, which is really good, and the GBA driver for MESS, which I haven't tried yet.

By the way, VBA-M is the only GBA emulator that works full speed on my crappy computer.

Ah thanks for the links. Maybe we can take a clean core form somewhere else

I say rewrite it but keep it separate from the current code for testing purposes.

Of course. There's a reason SVN supports branches.

The core code itself may be a mess, but as far as I can see (which isn't that far; I've only browsed through the sources for a bit; most of it's way beyond me anyway) the interface to it seems reasonably clean, with just a few functions that get called from outside of the core files. Maybe you could keep the changes "under the hood" so to speak?
Keeping the same interface could mean you can keep improving on the Qt and MFC GUIs while using the old core (and maybe get a working Qt port with emulation soon), while at the same time being able to test a modified/rewritten core by directly plugging it into the existing MFC GUI to see if it works.

I don't like the idea of removing GB support, but thats because i like to use as few emulators as possible. If development went that way, i'd support it regardless, but im just saying, i like as much support as possible.

Gambatte may be accurate and all, but i like the functionality of VBA, i would much prefer to expand on functionally, rather then remove it.

Thats just my input however.

Though maybe im reading into it wrong?. would keeping CGB support maintain the ability to play DMG games on VBA?

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

Quote:Gambatte may be accurate and all, but i like the functionality of VBA, i would much prefer to expand on functionally, rather then remove it.

Gambatte has a clean API, so it would be possible to use it for GB emulation and keep the same front-end as VBA. It's really too bad that emulators in general are so closely tied to their front-ends, causing people to often have to choose between an accurate emulator with a lousy front-end, or a less-accurate one with a good front-end.

Quote:Though maybe im reading into it wrong?. would keeping CGB support maintain the ability to play DMG games on VBA?

Dropping pre-GBA support would cause everything other than GBA games to become unsupported, since they're all handled by the separate GB emulator core. DMG/CGB/SGB/etc. are all variants of the classic Game Boy.

Core rewrite? Why not. I say go for it! As for open source GBA emulators, there is also mednafen: http://mednafen.sourceforge.net/

This emulator IS based on VBA though. But it does have improvements making it better than VBA. I do not know if the code is clean or not in mednafen, but you could check it out and see. The idea that Gambatte could replace the GB code sounds good to me too. Gambatte seems like a great emulator. I support the idea.

Are the TAS enhancements in the VBAR planned to be incorporated at some point in time? If so, I'd keep the GB core, and redo the GBA core. If not, I dunno. >.>

Mudlord and Spacy have apparently decided that it would be more worthwhile to cleanup and improve the existing code, then to rewrite entirely. Part of VBA's appeal is that it runs DMG - GBA, and the features it happens to include.

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

Hmm one thing though as far as I remember GB cheat codes (like game genie etc) don't work on VBA so that renders GB emulation in VBA rather useless to me as I always tend to go back and use it's predecessor VisualBoy instead. So I would not mind if GB support were removed.
I know the query has pretty much been resolved, but I just felt like adding my 2 cents anyways.

Well, if someone really wants to do it, it shouldn't be too hard to add better cheat code support.

I won't touch it until I work some more on learning more C++ until then I am more than happy with recompiling

(08-27-2008 06:44 AM)SCHUMI4EVER Wrote:  Hmm one thing though as far as I remember GB cheat codes (like game genie etc) don't work on VBA so that renders GB emulation in VBA rather useless to me as I always tend to go back and use it's predecessor VisualBoy instead. So I would not mind if GB support were removed.
I know the query has pretty much been resolved, but I just felt like adding my 2 cents anyways.

Cheats work in GB games O.o i have an entire list of Gameshark codes for pokemon/megaman1 which work perfectly

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

(08-26-2008 11:48 AM)Squall Leonhart Wrote:  I don't like the idea of removing GB support, but thats because i like to use as few emulators as possible. If development went that way, i'd support it regardless, but im just saying, i like as much support as possible.

Gambatte may be accurate and all, but i like the functionality of VBA, i would much prefer to expand on functionally, rather then remove it.

Thats just my input however.

Though maybe im reading into it wrong?. would keeping CGB support maintain the ability to play DMG games on VBA?

+1
We already have tons of emulators, and it really makes sense for a gb emu to handle the whole family, gb, gbc, gba, as one can play gb titles on gba.
More important, vgba is the only emu i found wich allow me to get a somehow accurate rendering of an lcd screen, using bilinearplus + motionblur blending + proper greenish palette.

PLEAAAASE keep it :'(

I was looking at the code earlier when preparing an OS X GUI (which I have not yet implemented, as real life has gotten in the way), and was surprised by the number of global variables. It's large, but it's not unmanageable. It certainly would speed up development to have a cleaner interface, so I'm for a core rewrite.

I like the fact that vba and vbam support DMG/GBC games, but since there are other emulators out there, I wouldn't be disappointed if it went away.

In any case, if support for the older games is removed, I would recommend designing the interface so that support for DMG/GBC games could be added in the future if someone wanted to take that on.

That's just my two cents.

this core, as it is, is newer and more optimised then the original vba core. As it is, the developers dont have much experience with the GB hardware and programming it into software.... so Rewriting the core would be massive job to take on.

lol, everyone talking about how it has so much of this, and so much of that.

Well duh, its not a normal program, you aren't going to get GBA games going by writing an app which loads x86 data.

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