mGBA Forums
Romhacks targeting VBA-M: Accuracy vs (bug-for-bug) "Compatibility" - Printable Version

+- mGBA Forums (https://forums.mgba.io)
+-- Forum: mGBA (https://forums.mgba.io/forumdisplay.php?fid=1)
+--- Forum: General (https://forums.mgba.io/forumdisplay.php?fid=3)
+--- Thread: Romhacks targeting VBA-M: Accuracy vs (bug-for-bug) "Compatibility" (/showthread.php?tid=4858)



Romhacks targeting VBA-M: Accuracy vs (bug-for-bug) "Compatibility" - jimbo1qaz - 08-14-2018

I'm new to GBA romhacking, and my first impressions are absolutely negative. I tried downloading the Moemon romhack (please don't judge my tastes), but it crashes after the intro screen on mGBA.

I kinda made an unpleasant first impression in their Discord server, complaining about their usage of IPS patches (inability to tell which revision to use), and incompatibility with mGBA (and likely hardware). They complained I hadn't read the readme, which specified the ROM name (which doesn't help) and CRC32 (facepalm, it's a horrible and insecure checksum) to use.

In the project Discord, one user specified this:
Quote:Until mGBA is completed, it's still and experimental emu
Compatibility=Ability to play every title and rom hack without crashing or bugging
Which mGBA haven't
In response to me arguing that:
Quote:"bug-compatibility with vba-m = Ability to play every rom hack which doesn't work on hardware"
"compatibility = behaving like real hardware"
they responded:
Quote:Do what you want, but you're still wrong
Behaving like real hardware is not conpatibility
It's emulation
A good emulator is able to work like real.hardware
And a compatible emulator can do both work like real hadware and go out of the way to work like a slighty different one
and a good vba-m workalike supports anything that runs on vba-m. that's not a compatible emulator, merely one broken in the same ways
Quote:i wont stat a pointless argument about emulators. We use VBA-M as a base and that's it. We won't debug or support other emulators

I assume, given the Holy Grail articles and discussion on byuu's forum, that mGBA is the most accurate emulator, and that  Higan is second but slow. I'm assuming that hacks that break on mGBA are broken on hardware, so they're making a VBA-M game, not a GBA game. Are my assumptions correct? Having to deal with this kind of mindset is frustrating.

----------

Additionally are there any ways to detect VBA-M in GBA mode, and display a "only tested on VBA" warning when running on other emulators? I brought this up, the community mocked me and demanded me to "show them how". Echo RAM? VRAM locking? Are these GB-specific?


RE: Romhacks targeting VBA-M: Accuracy vs (bug-for-bug) "Compatibility" - endrift - 08-14-2018

Wow, how shameful. I haven't tried that hack on hardware but I will not break my back to support VBA-M bugs, nor will I put any effort into it at all. VBA-M bugs are bugs and reliance on them is just as bad as doing so with ZSNES (which is even worse accuracy-wise).

I'm sure if I thought about it I could detect VBA-M glitches, but there are just so many of them.

AFAIK mGBA is the most accurate GBA emulator, with higan in second, NO$GBA in third, VBA-M in a distant fourth and gpSP waaaaaay in last, but I don't have up to date data on this.