[ddnb]

I have absolutely no idea how emulator development is but I always wondered how specific bugs like these are fixed; is it just adding an if statement specific to this game or are these just general bugs that get fixed and could just as well also fix something undiscovered in other games as well?

[narnarpapadaddy]

Both, depending on the specific issue and the emulation technique.

There’s a slew of different approaches to emulation, such as bytecode interpretation (you read the ROM on the fly and try to “do the intended thing” using platform native APIs), bytecode translation (you convert the ROM into platform native code), hardware emulation (you simulate the original chips directly, and the ROMs “just work”), and more. In many cases all those techniques are used together for different parts of the system (such as emulating a CPU vs a GPU). Depending on what the issue is, how well the hardware is documented (you may even hit an undocumented hardware bug!), and how difficult it is to create a general-purpose fix for your particular approach to emulation, or how computational expensive it is to emulate correct behavior, you may choose to add a workaround.

Some emulation projects put more emphasis on 100% correct emulation than others. Console emulators tend to be biased towards performance.

[cogman10]

> Depending on what the issue is, how well the hardware is documented (you may even hit an undocumented hardware bug!)

What's fun is, particularly with older games and hardware, it wasn't uncommon for devs to use hardware bugs to their advantage. DK64 is notoriously hard to emulate because of that.

[zwirbl]

Can you elaborate on DK64? AFAIK it shipped with a memory leak that was known to the deva but could not be fixed in time for Christmas season 199x. This bug lead to a OOM crash in less than two hours or something so it was decided to require and ship it with the Expansion Pack with 8MB (?) RAM instead of the default jumper pack with half as much. I

[dallen33]

That turned out to not be true, FYI:

https://www.reddit.com/r/n64/comments/t2owki/psa_dk64s_expan...

[enjoytheview]

The answer is both. Devs will first try to fix it by correctly emulating the system behavior because like you said, that can also fix other games and because that is the right thing to do. There are occasions where doing that can result in a huge performance penalty or some other underised behavior so they just resort to hacks in the emulator or straight up patching the game.

[HideousKojima]

Also, at least in the Dolphin emulator for the Gamecube/Wii, they only use game-specific hacks as a last resort. They learned from a lot of older emulator projects that game-specific hacks pile up on each other and eventually make the code an unmaintainable mess.

[rolltrunhert]

> They learned from a lot of older emulator projects

They learned from themselves after doing just that for many years. Lately they have been working hard to get rid of game specific overrides.

They still have a gazillion tho, see here: https://github.com/dolphin-emu/dolphin/tree/master/Data/Sys/...

[JoshTriplett]

This is one of the differences between the bsnes/higan family of SNES emulators and the previous generation (ZSNES/snes9x/etc). bsnes/higan and emulators derived from them managed to emulate the SNES more accurately (which required more processing power), and this allowed having fewer game-specific hacks.

Emulation benefits hugely from increases to processing power over time.

[marksomnian]

This is (I believe) the PR that fixed this specific issue: https://github.com/Ryujinx/Ryujinx/pull/5933

In short, no - from my understanding, it does actually fix the underlying issue, rather than special-casing the game. I wouldn't be surprised if there are a few edge cases like that which are special-cased, particularly for older games (when "abuse" of CPU/GPU quirks was more common to eke out extra performance).