An Emulator Related Plea (that will probably fall on deaf ears)

Could people please stop making Pokemon romhacks that only work in old decrepit versions of VBA? It's 2019 and more and more people out of the stone age are using mGBA (or VBA-M but I don't know how development of that is). There's a good chance that people trying to play these hacks on hardware are also having problems as well due to poor emulator-specific (well, somewhat) coding.

Do you have any suggestions on how to do that? I can't believe anybody is specifically trying to make their ROM hacks only work in old VBAs, so it would be really handy to have a quick list of "things you should look out for to have good emulator/hardware compatibility".

Yeah, nobody writes emulator specific code or sits thinking to themselves when making a hack "hmm, better make sure this will only work on one emulator!". That's not a thing x

There are hacks that do that with ZSNES, though. Or at least used to be. So it is a thing out there.

I didnt know this was a thing. What makes one romhack work on an emulator that another cant?

mgriffin said:

Do you have any suggestions on how to do that? I can't believe anybody is specifically trying to make their ROM hacks only work in old VBAs, so it would be really handy to have a quick list of "things you should look out for to have good emulator/hardware compatibility".

Click to expand...

literally just play test on an emulator that isnt vba

Wavee said:

literally just play test on an emulator that isnt vba

Click to expand...

Play the entire game on multiple emulators? ROM hackers don't have a massive QA team you know. Which is why I asked for a list of things that are likely to cause problems, because that's at least tractable—you could fire up a different emulator for the things that sometimes don't work, rather than for literally everything you've changed because as far as you (as the developer) are aware anything could be broken.

Or maybe you're trying to say "play on No$GBA because it has a much more faithful implementation of the GBA hardware"?

EDIT: My general point was more along the lines of "If you want to get people to do something for you, make it easy for them. Bitching isn't a good strategy, and nor is acting as if they are being lazy. People write games because it's fun, they're unlikely to do something that's tedious and boring so either do it yourself (it's totally possible for you to fix someone's RH) or at least try and support them with tips on what things are likely to be broken."

ALM5252 said:

I didnt know this was a thing. What makes one romhack work on an emulator that another cant?

Click to expand...

I'd like to know too...

I know emulators are built to hold larger save files than the original gen III cartridges, but this isn't an issue if you're not messing with the save block (most people aren't I would assume).
The only other thing I can come up with would be emulator specific debug printing and emulation accuracy.

If you're sitting around mapping, scripting and doing that sort of thing, your ROM should be compatible with all of the emulators. Just don't expand your ROM beyond the default cartridge size, and saveblock hacks should limit themselves to the sectors available, instead of using emulator mirrors.

mgriffin said:

Or maybe you're trying to say "play on No$GBA because it has a much more faithful implementation of the GBA hardware"?

Click to expand...

yes, but not no$gba because im pretty sure its even worse than vba. just using a more accurate emulator already does the work because if something breaks the game youll notice as soon as you test your game. with that said, you absolutely should thoroughly test your hack if you insert major asm hacks.

testing on real hardware is the most ideal but not everyone has access to it. all hacks absolutely should be compatible with the hardware or otherwise what is even the point of making a hack? A fan game is much easier.

I don't think there are a lot of (good) hacks that are not compatible with certain emulators... I certainly never encountered it.
Which hacks are even meant in this thread?

@wavee
A lot of people play via an emulator on a mobile device, in that case you'll have a similar handheld feel as an original GBC/GBA. Plus a romhack has a much more 'original' feel than a fangame.

Wavee said:

yes, but not no$gba because im pretty sure its even worse than vba. just using a more accurate emulator already does the work because if something breaks the game youll notice as soon as you test your game. with that said, you absolutely should thoroughly test your hack if you insert major asm hacks.

testing on real hardware is the most ideal but not everyone has access to it. all hacks absolutely should be compatible with the hardware or otherwise what is even the point of making a hack? A fan game is much easier.

Click to expand...

Really? I thought that No$ was the reference manual for how the GBA hardware worked, or at least it was back when I was developing for it. But I guess that was years ago now...

So what's your suggestion for a more accurate emulator? I can't imagine it being fun to test on hardware after every small tweak given that you'd be lacking even the most basic things to make that convenient/pleasant such as save states or (in the case of writing asm) a debugger and/or memory viewer.

Yeah vega has this problem the minus version works on mgba but the non one just crashes.

ALM5252 said:

I didnt know this was a thing. What makes one romhack work on an emulator that another cant?

Click to expand...

My wild guess is that there might be certain hacky ASM Routines out there that were written with VBA's inaccurate behavior in mind first and foremost, and are used by people who doesn't test the effects of said routines thoroughly.

For a quick example, the well known Pokémon Adventures Red Chapter crashes on mGBA if you try to get into a battle after changing your costume.
Now, when you change your costume in that hack things like the character's OW Sprite, Trainer Sprite and Trainer Backsprite are directly affected. Changing the backsprite of the main character is presumably handled by an ASM Routine and the hack uses JPAN's Engine for other things which does include a feature that allows you to swap Trainer Backsprites. That's what led me into thinking that some of the ASM Routine/s used there (like the ones injected into the ROM by using JPAN's Tool's "Apply Character Hacks" button) might not work all too well in real hardware or hardware accurate emulators like mGBA.

Even if that guess was correct though, JPAN's Routines are not the only problem.
As it's shown in the video I just linked up there, things like the Real Time Clock systems for Fire Red can become another matter of concern.
Certain implementations of RTC for Fire Red like Prime-Dialga's don't seem to work correctly in mGBA, not by default. The important thing to note about that is that, at least as far as I know, his implementation is the most used one, mainly because it can be quickly injected into a Fire Red ROM with a tool.

In my opinion (and this is related to Bonesy's plea), if we want to see a positive change, the foundation of the Pokémon ROM Hacking Community needs some changes, or a straight up revolution that redesigns the ways of Pokémon ROM Hacking as we know it.
The Pokémon Decompilation Projects created by Pret are one step towards that goal. With them, any issues a project may have can be easily repaired by anyone, by jumping straight into the function causing problems to read, debug and fix it. With the decomps, proper efforts can be made to avoid the problems currently plaguing the ROM Hacking of Pokémon Fire Red, and we can also have a more unified community overall, where people can help each other with their projects, doubts and problems easily, to avoid things like game breaking bugs or buggy features from happening ever again.
The problem is that right now, the learning curve to set up and use the decomps can be very intimidating to people with no experience beyond opening Microsoft Office or using a Web Browser.

Pokémon Sweets is this.
There is also Pokémon Resolute and Pokémon Dark Rising.

As Lunos said, Decomps can offer a cleaner environment for creating hacks (just be sure to test them on mGBA or hardware still!). Bugs can more easily be debugged due to version control like git which creates a snapshot of the current state of the repo and you can go back to older snapshots too.

If anyone has interest in Decomps, there are many helpful people out there that can get you started. PokeCommunity's Discord server even has a channel for it which is where you can find some of these people. All that's required is a willingness to learn and some patience, but you'll surely have a good hacking experience once you're up and running.

Currently pokeemerald and pokeruby are usable. pokeemerald is especially recommended because DizzyEgg and countless of other contributors have helped to create great resources such as the Battle Engine, Pokemon Expansion, and Item Expansion which you can add to your project. There's also more features in pokeemerald to utilize such as the Battle Frontier code, animations, and Match Call. pokeemerald is also more documented so it's easier to understand the code if you'd like to get very custom.

A bright future awaits for Decomps. It's only just getting started.

ALM5252 said:

I didnt know this was a thing. What makes one romhack work on an emulator that another cant?

Click to expand...

In general, emulators are often more permissive than the actual hardware because they're designed to allow conformant programs, not to disallow nonconformant ones.

There's apparently a graphics compression/decompression tool which produces misshapen output when compressing new art; the result works in VBA-M's BIOS emulation, but not on actual hardware (or anything else using the actual GBA BIOS) or in other emulators. That's the reason Vega is currently broken.

Three things coming from someone who's earning his living from software development:

1. Make sure that during your test phase the hack is tested by people with different emulators. That way you can find bugs that slipped under your radar more easily.
2. Write documentation. Let's assume something real quick: someone writes a new routine. You implement that routine and somewhere down the road the person who implemented that routine discovered and resolved some bugs. You didn't notice and all works well until it doesn't anymore.
You then ask why this function doesn't work anymore. Others reply, that it does work and then ask you, which version you are using. If you've noted down these things it becomes a lot easier to point out that your issue was fixed in whatever version it was fixed afterwards.
3. An issue that I had for a long time: lack of a unified editor. The game dev people use one tool to do all the important work. Be that mapping, story telling or scripting. In the ROM hacking scene things still seem to be divided among a lot of standalone tools that do only one thing and make you swap around constantly (You're allowed to correct me if I'm wrong, though).
The benefit of such an editor would be a well curated list of "libraries" of functions that people know work well on as many emulators as possible.