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.