Fix magic being zeroed out when using fast file select #3389
+10
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #1187 for good. After spending 2 hours stepping through the application starting up line by line, I determined that since the file select screen rework was done in #1854, there was no point at which play state was valid AND the save context didn't have a file selected when fast file select is turned on, which is what the old fix used to determine when we were exiting the title screen.
The old fix specifically set
gPlayState->gameplayFrames
to 0 when exiting the title screen, which is why it didn't cover when fast file select was used. That frame counter is used in vanilla gameplay for animation timing, which means it's usually masked off/modulused down/used in a trig function for the timing of a specific animation, so its full value was never important. The important exceptions to that appear to be:Because the variable was uninitialized, it was just incrementing starting at the garbage value 0xabababab, which meant the trigger not to autosave during the first few seconds of gameplay wasn't happening, causing the described behavior of magic being zeroed out on first load via autosave triggering while the value is at 0 before the fill-up animation plays.
Given how many checks in vanilla code appear to want a counter value of 0, I suspect this variable was originally zeroed by the hardware. It's possible it even was zeroed on every play initialization like
play->state->frames
is, so if we're still looking for effects that aren't triggering like they should, this is a likely culprit.This fix uses the classic "set a variable to say we've set a variable" to set the frame counter the first time play is initialized, and it also resets the counter when the in-game Reset is triggered. The old fix to reset the counter when leaving the title screen is retained so that title screen time doesn't count towards the counter, meaning the counter can now be used as an accurate counter of play time elapsed since last reset (gameover also counts as a reset).
Build Artifacts