Nearly two years ago, I remember reporting a bug on a certain SNES game (Battletoads in Battlemaniacs) - basically, Deterministic mode breaks the intro part of the game, causing both the video and audio speed to fluctuate. You can't TAS without Deterministic mode, so there's no way around that. The main problem is that this also translates to the dumped .avi file. If it were to play correctly, it'd not be a problem. This isn't the only game with this issue, though. If you pause any of the DKC games, the speed breaks and audio starts playing really fast. If those two games are affected, there are likely many others with similar issues that we just don't know of. It was said that those bugs seem to be caused by "Deterministic Emulation hacks". While those are helpful for some games, they end up breaking others. My question is, why are those hacks even there in first place? Isn't it a dirty way to help some games run "properly"? Other than that, only reason I can think of is to help users with lower end specs to run those games at full speed. While it could prove useful some years ago, it shouldn't be a problem anymore. It's 2017 and I'm sure most people have decent enough hardware to run bsnes at stable 60fps. It runs perfectly on my machine, and it's from 2012. Even higan's accuracy core runs at full speed. Furthermore, bsnes's compatibility core already runs all SNES games perfectly apart from Air Strike Patrol. So, why the need of hacks? I think they only break the purpose of keeping emulation faithful to real hardware. It could also cause other significant problems such as preventing movies of those hacked games from running on a real SNES. Note that those bugs are Bizhawk exclusive. They don't exist on the actual bsnes/higan or even the less accurate snes9x. It's present on all Bizhawk versions except for really early ones where Deterministic mode wasn't a thing. My suggestion is to remove those hacks as they apparently cause more problems than good.
All the determinism hack does is forces a savestate to be taken every frame, even if the frontend did not ask for one. As a result, it makes things slower. It's required because the savestate code in BSNES is worthless junk, and it breaks some things because the savestate code in BSNES is worthless junk. The same bugs do exist on lsnes; you used to be able to desync some movies by taking extra savestates. That may have changed with more recent builds; I think lsnes ignores your savestate request sometimes as a different hack around.
