Boktai 2: Solar Sensor emulation breaks on rewind

[Drakodan]

Good evening. I'm currently working on a TAS of Boktai 2: Solar Boy Django on Windows 11, in Bizhawk 2.9.2 which according to the program is using mGBA 0.11 as the GBA core (Though I see 0.10.3 is the newest version?)

I took two clips from a stream I did tonight to show persistent issues with the solar sensor:
https://www.twitch.tv/drakodan/clip/TameEvilIcecreamMVGame-nRRHnu2D8jGAROlQ
https://www.twitch.tv/drakodan/clip/SmellyBlushingMartenLitFam-OH3JMZGspfwKQz7Q

The first clip shows how on rewinding per-frame, the entire displayed gamestate can change. My understanding of why this happens is because Boktai's displayed sun level occurs at fixed intervals, and I think that rewinding/frame-advancing during these intervals messes with cached stuff? That's my best guess.

The second clip shows that the above behaviour can cause phantom lag frames to occur that otherwise should not be occurring.

I can try to provide more examples/information if this is an issue worth addressing, but this is the common scenario/cause of the bugs (Rewinding a movie manually)

[RetroEdit]

Sounds like there's likely a problem with solar sensor savestates, since BizHawk relies on mGBA for the savestate implementation. That doesn't guarantee the issue lies with mGBA, but it's worth looking into.

[endrift]

The solar sensor afaicr doesn't store anything in savestates. The sensor has two callbacks: sample, which tells it to update the cached value, and read, which gets the cached value out. It's possible that BizHawk doesn't restore the cached value upon loading a state if it happens between a sample and a read, or something similar. @YoshiRulz any idea?

[CasualPokePlayer]

To be clear, the amount of state actually specific to the solar sensor is very very low (I can count all the variables directly related with 1 hand). A cursory look at the savestate function seems to indicate all state is accounted for for the solar sensor.

There also should not be any sort of issue with what BizHawk itself reports, as the solar value is set per FrameAdvance(), taken from current input (if this was going wrong, it would affect practically every system in BizHawk).

It's more likely just a generic savestate issue, with the solar sensor possibly exacerbating the issue (since the way the game queries the solar sensor is somewhat timing related, it could very well be from seemingly unrelated issues), but not being the fault of the issue.

[RetroEdit]

Note: there's still some savestate non-determinacy with solar sensor apparently: TASEmulators/BizHawk#4094. Could open a new issue, but this issue as written still basically applies (unless it turns out to be a BizHawk-specific problem).

[CasualPokePlayer]

Note: there's still some savestate non-determinacy with solar sensor apparently: TASEmulators/BizHawk#4094. Could open a new issue, but this issue as written still basically applies (unless it turns out to be a BizHawk-specific problem).

Using the movie from here, I've created a few savestates which can reproduce the issue within mGBA (using 2a0ed00, and with a real BIOS file and a 1.0 Japanese Boktai ROM). desync.zip

The behavior appears to be a case of the act of loading a savestate (even within the same frame it was created on, i.e. save/load a state without advancing any frames in-between) causing some state to be mangled and resulting in a desync later on.

For these peek at 0x46B8 (4 bytes) in IWRAM to confirm behavior (stops incrementing at 906 in "expected" case, in desync case it keeps incrementing longer, stopping at 934 instead, assuming default solar sensor sample state)
mGBA_0 has the "expected" case.
mGBA_1_preload and mGBA_1_load both would be the desync case. Preload is the initial state, and load is the state that results after loading preload. Note that the two states differ.
mGBA_1_* of course is 1 frame after 0. Creating/loading states at frame 0 here doesn't have issues, it's when it's done at frame 1 it has issues (and possibly later frames, but I didn't test much further).