Stop Using VBA! (For playtesting)

Hello! As many may know if you’ve been hanging around this website VBA is by far the most popular GBA emulator used by new romhackers and those who’re just looking for a hack to play.

However as many romhackers are aware VBA is completely overshadowed by MGBA and No$GBA in terms of accuracy, features, and general stability.

I created this thread mainly to notify those unaware of the problems with VBA and to advise new romhackers or hack players to use MGBA or No$GBA instead, it’s what most semi-experienced and experienced romhackers use and reporting bugs only found in VBA can cause easy confusion between dev and player.

If you have any documentation on these problems feel free to share them here.

As pointed out, I may have come off as saying that VBA is bad for using in general, which mostly isn’t true, it’s perfectly usable for playing most hacks, just not for playtesting

(as a side note I feel a bit surprised that a thread advising others to use MGBA hasn’t been made before)


This is true for hacking and playtesting, yes
but for casual usage, just use whatever you want

iirc VBA skips bad code to avoid crashes in game
No$GBA is very useful in debugging iirc, I remember some people used that
mGBA is the closest one of emulating real GBA console, that’s why it’s perfect for playtesting (to find bugs, to be precise)

because VBA isn’t exactly faulty to use
like i said before, use whatever you want
each emulator has its own advantages

please stop making these kind of threads, you sound like you’re gatekeeping or smth


This is a hard sell if you’re not offering examples.

True, but I think it’s only fair to mention that most bugs are not exclusively found in VBA. From what I’ve seen, people tend to assume a bit too quick an issue lies with VBA rather than with the code they’ve written.

I’m also confused why you would recommend No$gba for playing. It’s got a number of issues displaying graphics, and is mostly intended as a debugger, isn’t it?


yes of course I never intended to say to not use VBA for actual GBA games, just romhacks that don’t have the large teams necessary to sniff out bugs in both VBA and MGBA

that was not my intention (also what threads are you referring to? I’ve only really posted a bit of opinion based threads and a design thread dedicated specifically to what I find enjoyable in FE, in any case I don’t intend to make threads for a long while), I’m merely putting this thread out there in case any new hacker wants to find out why someone said ‘do not use VBA’

I apologize if it sounded too sharp or commanding, I only wished to draw in those just starting to this thread with the title.
In any case I’m sorry if I offended at all.

I mostly just recommended No$GBA to not sound like I’m saying “MGBA is the only good emulator to use” which isn’t the case

A year or so ago i was trying to play Iron Emblem with VBA, got emulator freezes and crashes every 20 or so minutes. After some testing it appeared to be irrelevant which emulator or setting, or even rom i was using.
I ended up switching to Linux either way around the same time, and Retroarch with mGBA works flawlessly on that.
Still don’t really know what caused it or how i would fix it, i just use Retroarch on Linux now.
Thought it was related to the topic so i might aswell say it


I fucking hate MGBA. I don’t care if it’s supposed to be ‘better’ or ‘more accurate’. It’s always an awful experience. I’ve tried switching on three occasions, and always run into annoying bullshit.

I don’t remember the reasons anymore, but a year and a half ago I tried it again and ended up quitting within a month. Something about savestates, roms simply not loading, the control options sucking, making speedup/rewind toggle didn’t work right, and other things.

Use it if you want, but I still break out old reliable every time. It has -never- failed me.


That’s strange I’ve never had MGBA operate poorly for me, even with my god awful laptop, I’m starting to wonder if we got a conspiracy in the making

Every copy of MGBA and VBA are personalized


That unfortunate. MGBA has been very good to me, Retroarch and VBA has given me constant problems with big rom hacks so I’ve always opted to use MGBA, granted I don’t use save states(I’m a filthy purist) and only use it on my psvita/ps3 (when I want a bigger screen and am at home). But I agree, nothing beats ol’ reliable.

I honestly wish we had an amazing new GBA emulator like Duckstation for Playstation 1 games.

1 Like

I understand it well.
I’m so used to VBA-M that I can’t move on to mGBA.
The various differences bother me, and I end up reverting to VBA-M.


You should submit data on which glitches are more common, those that occur only with VBA or those that occur only with mGBA.
You should also describe the cases of glitches that are fine with VBA but freeze with mGBA, and vice versa.

As for me, I think the one with more players should be used for test play.
In terms of number of players, I think the VBA-derived emulator will have the most players.


Really now. that I did not know about. I always thought that VBA was good to playtest

1 Like

VBA just is the most popular emulator, period. Going on to label its users as “new” doesn’t make your message look any more relatable, especially when you seem to be a rather new user yourself.

You claim to have made this thread to inform others of how VBA is inferior, but then proceed to not back that claim up, and also ask that others do it for you, so perhaps you’re not as confident in it as you say “many romhackers” are. Again you try to use a label and say that “(semi-)experienced romhackers use not-VBA”. That’s arguable, and even if it were a fact, that’s irrelevant if it’s not explained why.

Then you imply glitches are more common in VBA than others, again hoping others take it as a fact with no explanations. From personal experience it’s the other way around. If something glitches in VBA, it usually also glitches in others, but it’s less likely to be the other way around. I would say I’m past the “new romhacker” label, but I don’t want others to blindly follow what I just said due to my personal experience without them figuring out what works for themselves.

I always found it funny. If a bug is exclusively on VBA, then that’s a bad thing about VBA. If something doesn’t bug in VBA, then that’s a bad thing about VBA. But if you switch VBA to mGBA, suddenly both become good, apparently. Supposedly the reason is its “accuracy”, even though it’s hardly common for people to play ROMhacks on actual handhelds for that to be a priority. And it varies from person to person, I’ve never had issues running VBA/VBA-m, but had some with mGBA and No$ previously, while other people report the opposite.

It’s also disingenuous to claim you speak exclusively for playtesting. If more people playtest only with mGBA, then that makes it more likely that non-mGBA exclusive bugs will be missed, which leads to “it’s recommended to play this hack with mGBA” and we all know the response (from “experienced romhackers”) to that with VBA already.

I agree with 7743, if you want to attempt to select one emulator as the standard/objective to focus bugfixing with, I think it should be the one that’s more used for playing them, which is VBA/VBA-m, especially considering FEBuilder’s debugger works with them. If you’re running into an ASM-related issue, by all means No$gba’s debugger is ideal for locating it. Personally, mGBA’s in a weird spot where it’s outshined by both.


I don’t remember the last time I experienced a romhack bug in VBA that I could solve -just- by switching to mGBA. Hell, I don’t remember the last time I encountered a romhack bug attributable to VBA, period.

I ain’t even using VBA-M, I don’t think. I’m using plain old VBA 1.8… haven’t updated in like 10 years or so. Thing runs like a beauty. No issues at all.

Edit: Here’s some logs from when I last used mGBA.

mGBA is such a piece of shit. God, I hate it so much.

  • No$GBA isn’t cycle accurate. NanoBoyAdvance or mGBA is the recommended emulators in gba dev community nowadays.
  • VBA is open source. If you find any bug, feel free to contribute. Pls pull a request to fix it or open an issue to report it. It is better to help than complain. Btw I fixed two bugs for VBA.
  • Tools are not good or bad. Just choose the correct one for your purpose. For example, if you want your hack to run on real console instead of some emulator only, you will need to choose the most accurate one instead of the “best” one. In addition, I usually test my project using flashcarts to ensure it works on real console for some major version release.

The fast forward feature works well for me. It may be old bug or your operation miss idk. However, it doesn’t help to shout “xxx is such a piece of shit. God, I hate it so much.” like a baby/客様. It is better to report the bug you found (maybe not bug though) and wait for author’s response or even better fix it yourself and contribute the bugfix to the project. I know it may be difficult for you because you always complain everything like that, not only tools but also hacks or games. Of course it is your right to decide what you do, but I still keep my opinion on what you do. If you think it is your right to share your negative opinion like that, it is also mine to share my opinion on your behaviour.


Wait. Duckstation? I’ve been using Beetle PSX HW this whole time because it’s the least terrible but it runs horrifically on lower spec systems. What is Duckstation

It’s based that’s what :sunglasses:

it works just get good lmao

This is like unironically a bad idea, who cares if the emu is more widely used? It’s not like mgba is some like deep dark secret artifact you have to dig deep into the dark web to get in order to play FE hack number 685. It’s free lmao, already known to be more accurate and most importantly actually alive active and not dead since like 2007 which is huge and an underrated attribute. What is inaccurate has a higher potential to become more accurate without resulting to some obscure ass build.
That mindset is why communities exist where you need to download the 3rd fork of version 0.43096 alpha build of the crustiest emulator from 1792 to play hacks that fall apart when you run them anyway.

The debugging thing is valid tho.
I mean idk, the very notion that the chance of a one-sided compatibility bug is low undermines either side on this vs debate. you’re still more likely to cause one on vba tho

I’m not here to seriously butt in on this, frankly I couldn’t be assed to go back and forth on it y’all do y’all. I don’t even hack.
mgba is pretty epic tho yes I am biased

also vba has shitass visual options and if you post a maximized stretched resolution bilinear filtered screencap from it you’ve given me license to bully you

also mgba has real rewind for casual play

1 Like

WWIII has been started in the comments


Only one can win… or can peacefully coexist… fuck it, I choose war :smiling_imp:

Probably, VBA and mGBA are almost the same as an emulator.
Because if there is a problem as an emulator, the game will not work.
If the game works and can be played, then it is correct as an emulator.

On top of that, if there is a problem, I think it is undefined behavior.
In other words, when there is a bug in the code of your game, and it refers to memory that should not be referred to, or when it executes a strange undefined instruction, this is the behavior.

The mGBA aims to make this undefined behavior as close as possible to the actual game console,
The no$gba debugger, which aims to stop for debugger (although sometimes the debugger hangs because it cannot be stopped),
And the VBA that is neither of those.

In terms of test play, It best when the undefined behavior is stopped like the no$gba debugger.
The sooner it stops, the better, because if it doesn’t, you won’t know there is a bug.

The earlier the timing of the stop, the better.
For example, if it is stopped after the stack is exhausted, it cannot be debugged.
In this sense, I think no$gba debugger is superior.

I also appreciate the fact that it has the most decent debugger function among the three.
Compared to VBA and mGBA, which can set break points but have questionable continue behavior, the no$gba debugger works well.

However, when viewed as an emulator for playing games, the no$gba debugger is the worst.
This emulator is focused on debugging games, and I don’t think it thinks much about playing games.
And it is not open source.

This undefined behavior issue has been a popular topic in browsers.
As I’m sure you all know, it’s the IE vs mozilla(netscape) vs others war.
//In the end, KDE’s browser (Konqueror/KHTML), which was a weak force among others, became WebKit with the support of apple, and then became chrome by google, and won the world.

Browsers don’t work by magic, they work by code that interprets HTML, css, and javascript.
There is code written to interpret them, but undefined behaviors, such as “does it work if the value that is expected to be an integer is negative?” and other undefined behaviors caused a lot of trouble.

Of course, It’s your wrong HTML is bad, but from the user’s point of view, it’s not.
From the user’s point of view, it doesn’t matter if the code is right or wrong, they just want to see the website.
I think this is the same with emulators.
Since it is an emulator, it may be better to be faithful to the actual device, but the users don’t care about that, they just want to play the game.