Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GBA 2.3.1 savegame-anchored movie will "forget" its savegame when loadstating #1593

Closed
mugg91 opened this issue Jun 16, 2019 · 10 comments
Closed
Labels
Core: mGBA Game Boy Advance (GBA) core Repro: Affects 2.3/2.3.1/2.3.2 (2.3.3 has its own label) Repro: Fixed/added in 2.5

Comments

@mugg91
Copy link

mugg91 commented Jun 16, 2019

I'm playing Super Mario Ball (J).gba on Bizhawk 2.3.1, mGBA-core. EDIT: It seems to be a different behavior for VBA-Next. Will update here with information soon.

If the game is started anew, then pressing on the title screen will start the game immediately. But if you unlocked Time Attack mode (by obtaining 2 star keys), pressing on the title screen will bring up a selection between "new game" and "time attack".

I wanted to TAS Time Attack mode and started a new movie, starting from SaveRAM.
When letting it run through to the title screen, I can select the mode and everything will work normally from then on.

But if I save and load a state at any point before the cutscene before the titlescreen (BIOS screen to "Fuse Games" screen), then the Time Attack mode will be gone, and the game acts as if it had no savegame.

@vadosnaprimer
Copy link
Contributor

What about previous releases?

@mugg91
Copy link
Author

mugg91 commented Jun 16, 2019

I'm testing, but it's a bit weird. The results vary after I wipe all savegames and redo the testing...

  1. I wiped all Super Mario Ball (J) SaveRAM files from the GBA/SaveRAM folder.
  2. I select the respective core (mGBA or VBA-Next)
  3. I advance into the game, save & quit, then start recording (from SaveRAM)
  • Bizhawk 2.1.1 - 2.3.1 (Also 1.12.0)
    -- In mGBA, if I let it play until the title screen without loadstating, it will show the saved game. But if I loadstate before the intro cutscene, the problem occurs.
    -- In VBA-Next, it will "forget" the saved game even when I don't loadstate.

@YoshiRulz YoshiRulz added App: EmuHawk Relating to EmuHawk frontend Core: mGBA Game Boy Advance (GBA) core Core: VBA-Next (Deprecated) Game Boy Advance (GBA) core Repro: Affects 2.3/2.3.1/2.3.2 (2.3.3 has its own label) labels Jun 16, 2019
@RetroEdit
Copy link
Contributor

RetroEdit commented Apr 7, 2020

Last tested build: 2.4.2. This probably won't be fixed until it's explicitly targeted; it's unlikely to be fixed by accident, but I will continue testing new versions anyway.


This issue persists into BizHawk 2.4 and the latest developer build at time of writing (2020-04-07-134352-#ce17df2b6abcd6784d15c8f45889fb4e6d9b678d). It appears to be GBA-specific; I did not have this issue when I created a bsnes movie.

To begin with, a .bk2 movie will still load properly with the SaveRAM as expected. The issue occurs when loading a savestate while a SaveRAM-anchored movie is being played back. If a savestate is loaded before the SaveRAM would be used (e.g. before the file select screen in most games), then BizHawk will act as if the SaveRAM in question does not exist and the game will play as if there is no existing save file. The movie remains unmodified (containing the proper original SaveRAM). Thus even if the saved movie is overwritten by modified inputs after loading a savestate, the saved movie will act as if starting from the original SaveRAM when newly loaded from the beginning.

But the issue isn't specific to SaveRAM-anchored movies. Even when running BizHawk without a movie, the game will not play with the expected SaveRAM when loading from a savestate.

The way I originally discovered this issue is documented here. I originally discovered it using TAStudio, but the issue is more fundamental than that.


Further testing: The same issue is present in 1.11.6, 1.11.8, 2.0, and 2.3. SaveRAM just plain doesn't save with VBA-Next. mGBA core still has the same issue of not properly loading SaveRAM with the savestate in these versions.

For reference, my testing methodology for these versions was to load Shrek 2 (SHA1:D3C3201F4A401B337009E667F5B001D5E12ECE83, MD5:9EF8E30824DB751F3D42E048514A3624), create a save slot in-game, reload the game and save a state somewhere around the opening screens (the first screen after the bios), continue playing and verify the previously created save slot exists, and then load the save state and watch it fail to load the previously-created save slot. One trick is that pressing 'Start' skips the long intro sequence in Shrek 2.

I used a modified testing methodology because the movie wasn't required and I didn't want to worry about movie incompatibility problems with old versions of BizHawk.


Some interesting mentions of mGBA and savestates from the release notes: From 1.11.8.1: ( https://github.com/TASVideos/BizHawk/releases/tag/1.11.8.1 ) "This is a patch fix to 1.11.8 that fixes mGBA savestates". From 1.11.6 ( http://tasvideos.org/Bizhawk/PreviousReleaseHistory.html#Bizhawk1116 ): "mGBA: Capture SRAM in savestates, ALL PREVIOUS SAVESTATES are now incompatible".

@adelikat adelikat changed the title Bizhawk 2.3.1 savegame-anchored movie will "forget" its savegame when loadstating GBA 2.3.1 savegame-anchored movie will "forget" its savegame when loadstating Apr 7, 2020
@zeromus
Copy link
Contributor

zeromus commented Jun 18, 2020

Here's my thoughts on this (testing shrek 2). mgba can't save the save ram right at startup because it's still autodetecting. I think the way mgba works is once the autodetection is complete, it kind of "resolves" things using the save data that's provided. But until that happens, the save data is in a messed up state where it can't be savestated. I solved this problem in desmume long ago by saving the state of the autodetection in the DSV (battery) file format. I don't see how MGBA can possibly work without that. So I think it must be broken, even in official frontend.

I would prefer for endrift to figure this out, but first we need to prove that official mgba frontend or other frontends have a similar problem. If not, then we need to figure out how theyre using the core->api functions so theyre not vulnerable to this problem.

@endrift
Copy link

endrift commented Jun 18, 2020

The savestates store what the configured save type is, so loading a savestate should fix that.

zeromus added a commit that referenced this issue Jun 18, 2020
…42ad9b78939b85a5 and 8f1148498e12197745f62e477d9b8e07382cc72e to address #1593 (at least, it fixes the shrek 2 non-tas scenario)
@zeromus
Copy link
Contributor

zeromus commented Jun 18, 2020

Shrek 2 is fixed due to endrift's work (thanks!)
You guys need to verify the tas scenarios. There could be still more bugs in our end (due to the vba-next involvement? I didn't even look at that)

@YoshiRulz YoshiRulz added the Repro: Patch pending Potentially fixed in dev build, see readme for download label Jun 18, 2020
@endrift
Copy link

endrift commented Jun 21, 2020

This is pending @mugg91 testing an interim build, correct?

@RetroEdit
Copy link
Contributor

Or I can test, as I'm the one who actually brought it to developer's attention; before I commented and talked about it in IRC, it was sadly forgotten.

And done: Shrek 2, tested with my general procedure.

Of course, if devs want mugg for double-confirmation, they're more than free to. Also, I know issues are sometimes kept open until the release that fixes them.

And @adelikat this is definitely an issue I would bring up in the next release notes, as I consider it a significant if low-profile because apparently no one has noticed it in all these years (anyone doing SaveRAM-anchored movies has a potential to notice it).


As for VBA-Next, that's being removed anyway. So... I can see your point about there being something else potentially off with BizHawk, but it seems just as likely to me that VBA-Next had similar holes in its savestate implementation. And I have no desire to wade through VBA-Next problems just because it potentially relates to BizHawk; others are free to do so if they feel it's important.

@YoshiRulz YoshiRulz added Repro: Fixed/added in 2.5 and removed Repro: Affects 2.4 Repro: Affects 2.4.1 Repro: Patch pending Potentially fixed in dev build, see readme for download App: EmuHawk Relating to EmuHawk frontend labels Jun 21, 2020
@endrift
Copy link

endrift commented Jun 21, 2020

Erm, we'd already confirmed that Shrek 2 was fixed. We wanted to make sure the bug in Super Monkey Ball was also fixed by this before we closed it.

@RetroEdit
Copy link
Contributor

Sorry about that. Now I've tested Super Mario Ball and had no issues with newest BizHawk (not to be confused with Super Monkey Ball, which apparently wasn't a GBA game, only Super Monkey Ball Jr. was). I also confirmed that it previously had an issue as late as 2.4.2, exactly as expected.

@YoshiRulz YoshiRulz removed the Core: VBA-Next (Deprecated) Game Boy Advance (GBA) core label Aug 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core: mGBA Game Boy Advance (GBA) core Repro: Affects 2.3/2.3.1/2.3.2 (2.3.3 has its own label) Repro: Fixed/added in 2.5
Projects
None yet
Development

No branches or pull requests

6 participants