There was a bug in bsnes-performance's SMP core, which was ported and merged into Snes9X v1.54, and is also used by several bsnes/higan forks.
The bug causes severe audio issues in Dark Law, Haisei Mahjongg, and Super Pinball. I first found out about it two hours ago on /r/emulation.
Officially, this core has been retired from higan and is no longer under active development. But because this code is used by other projects, I went ahead and fixed the bug. I will not be releasing an updated version of higan v098-performance, sorry.
In core.cpp, you will find the following macros:
Essentially, direct-page accesses wrap around the active bank. The bug came about due to changing a function that took a uint8_t argument into a macro that no longer auto-masked the address parameter.
I'm very sorry for anyone inconvenienced by this bug.
[...]
RunToSave has never worked correctly over the entire life of bsnes. This was well known when the first bsnes movie was accepted to this site; if you pounded the savestate button a few dozen times at the beginning, the run would desync. Byuu has been presented facts about this a number of times and has flopped between viewpoints as needed, including denying the bugs, blaming them on the installation, and downplaying them as not significant for most users.
The best example I can think of is Tales of Phantasia. It uses a uniquely difficult sound engine that crashes the emulated game and in some cases even the emulator when you savestate too many times. This is 100% repeatable on any Bizhawk build of the appropriate version: Turn on 1frame rewind, load the game, and watch the attract always crash on the exact same frame <6000 frames in (the exact number escapes me now...). I fixed the emulator crash https://github.com/TASVideos/BizHawk/commit/451f786660744835be868c7fca91ef3fc33db687 but the game still crashed; then I fixed the game crash https://github.com/TASVideos/BizHawk/commit/587270cad2ec96eaeec0ae60e4247c31a0a06a2e (note: there are two commits before it that are also relevant; see end). The exact problem was completely plain under a debugger, and once the fix was implemented it never happened again in Bizhawk, but according to Byuu that couldn't possibly have been it because the game works in Snes9x, which is much less accurate!
Some other things are heavily broken too, all with the same MO: The game will work fine with no savestates, but the moment you start savestating every frame, things break. Super Game Boy, audio on some Rare games; Sonia knows more if you're interseted http://tasvideos.org/forum/viewtopic.php?t=19031
Besides complete breakage, there's also a lot of desync potential where a game will continue to run but handle timing subtlety differently. I believe Ilari has mitigated this by a combination of ignoring savestate requests at certain times and only taking savestates at known "good" times that happen to work out better, but I'm not sure; he's not the most cooperative and his code is impenetrable. Those solutions would be more duct tape and pray anyway; you still don't have something that is taking correct savestates.
End: Here are all of the commits that I ripped out of bizhawk that were related to our coreside fixes for libco savestate problems:
a60be7d2c9818229a0dcff0dbccf15f31015ca2a
a7b6a9af4d4c049dbcd775f05f8539f86456e5e9
57b1df8487e3102b2e81c75fb96640cb1da430a4
9119e4f4ea7661b555125f8d6023efda8f6ed704
b2c0910376657208acb325953fbb2dbd4957d5e1
587270cad2ec96eaeec0ae60e4247c31a0a06a2e
74c26d9b117d3bdc78f5e5247909c9a05dee2a98
5e3d6555b02b1d6a6b61d8aeb3617e256697cd01
451f786660744835be868c7fca91ef3fc33db687
There might be more of them, and I know there are frontend commits as well, and many other issues that we just didn't solve.
libsnes: Cleanup some dead code. Apparently the codebase contained a …
…primitive attempt to implement savestates, but it contained significant bugs and had no use beyond toy projects.
Can anyone please let me know what this is about?
I know it's just common programmer behavior to hyperbolize comments about others' code, but I was genuinely surprised to hear my method disparaged to this extent.
I'm not looking to stir up any trouble, but I am interested in learning about what problems my method has, because I'm still using it.
In the ten years higan/bsnes has supported save states, I've yet to hear of them ever once failing to restore a saved state for anyone. (With the only exception being that until recently, SA-1 games using WAI weren't supported.)
* SNES - bsnes Sync stability without a huge speed hit
* SNES - Snes9x 1.54 ported. Note that bsnes still should be used for serious TASing intended for submission at TASVideos. But snes9x is provided for its performance and decent compatibility for casual gaming, botting, and testing
Does that mean that the "Performance" core and the "Force Determinism" option can be removed?
