TASEmulators
Greenzone Validation Fails
Summary
It looks like waterbox (?) is not properly handling loading the initial save state from frame 0. At least two games for NDS (Mario Kart DS, New Super Mario Bros.), as well as at least one game (DK Country 3) in all SNES waterbox cores fail greenzone integrity check in TAStudio within the first few frames. All except Faust reliably fail at frame 1.
I'm not certain it is a waterbox issue, but my understanding is that waterbox is supposed to make this impossible. I also do not know if this issue can cause movie desyncs.
I have found this issue exists on the 2.10 release tag as well.
Repro
- Using default config
- Open Mario Kart DS (US)
- Open TAStudio
- Advance one frame
- Edit -> Savestate History Integrity Check
Host env.
- Current master branch, Windows 11
- BizHawk 2.10
I think that's intended? Greenzone integrity checks in waterbox fail all the time, for every frame. I don't think this is an issue, just a side-effect of how waterbox states work. I do not know the exact reason for it though.
What exactly does the greenzone integrity check do?
It compares the saved state with a new one when replaying from frame 0 and errors if any byte isn't equal.
I think that's intended? Greenzone integrity checks in waterbox fail all the time, for every frame. I don't think this is an issue, just a side-effect of how waterbox states work. I do not know the exact reason for it though.
Faust did not fail at frame 1 so it's not quite every time. It being intended seems strange, but if that is the case shouldn't the option be removed when the current core is waterbox?
replaying from frame 0 and errors if any byte isn't equal.
I've never looked into tastudio specifically, but a long long long time ago I did some similar ad-hoc tests just for Waterbox. It passed at one point, but then it started failing for reasons that didn't seem impactful. I think it had something to do with on-stack entropy; if a core starts reading raw stack data outside of that which it has legally initialized subject to the rules of the calling convention and the C language, it might be able to get into non-deterministic situations. Cores generally didn't do that, so they generally worked fine.
This is all from memory 10 years ago though 🤷.
I assigned zeromus because I recall him complaining about this being necessary:
https://github.com/TASEmulators/BizHawk/blob/61801f253baaab8de1722c9262853882d7a9f367/src/BizHawk.Emulation.Cores/Consoles/Nintendo/BSNES/BsnesApi.cs#L172-L173
...but that's enabled by default (skip = false), so it can't be the cause.
