Jump to content
Visual Boy Advance-M
spacy51

Core rewrite

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
IMO' date=' there are enough GB emulators out there, but VBA is the ONLY [b']open source[/b] 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. :D

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

IMO' date=' there are enough GB emulators out there, but VBA is the ONLY [b']open source[/b] 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. :D

 

 

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

 

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :'(

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

We are really talking about rewriting the complete GBA core before a lot of the features of some forks are included.

And VBA-M started as a Merge of all the enhancements of the different forks... funny.

But it seems I also have really missed some good development and enhancements the last 6 weeks I was away.

Great job, all of you!

Share this post


Link to post
Share on other sites
We are really talking about rewriting the complete GBA core before a lot of the features of some forks are included.

And VBA-M started as a Merge of all the enhancements of the different forks... funny.

 

Well think about it:

 

* The current core is quite unclean

* Which means maintainability suffers

* If we do the rewrite right, then it wont affect the added enhancements.

* Plus we already made quite a fair few enhancements, even blargg has kindly assisted us with this.

Share this post


Link to post
Share on other sites

i don't see why we don't just use the AGB core as it is in the actual GBA hardware to run the other game types.

 

Anyhow, i dislike Gambatte, if i was forced to use another emulator it'd be an older version of VBA

Share this post


Link to post
Share on other sites
i don't see why we don't just use the AGB core as it is in the actual GBA hardware to run the other game types.

What are you referring to by "AGB core"? A GBA-only emulator is simpler than one that also supports GB/GBC games, as it doesn't need the GB Z-80 CPU emulator and GB/GBC graphics support. Supporting GB/GBC is basically a separate emulator.

 

Anyhow, i dislike Gambatte, if i was forced to use another emulator it'd be an older version of VBA

If Gambatte were used, it would be its core only, not its front-end. Or are you saying you dislike its accuracy and clean code? That's the only important difference.

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

×