BizHawk
BizHawk copied to clipboard
TASEmulators
Loading savestates break Super Mario 64 ROM Hacks
Summary
After loading a savestate while playing a Super Mario 64 ROM Hack, it can cause major issues with the game, from dying automatically, to the game freezing, to BizHawk itself crashing and closing. It mostly happens when I save a state in one area, and load it while I'm in a different area. For example, saving a state from the Castle Grounds and loading it from the inside of the Castle Lobby or the first level of the game. I've used the Rice Video Plugin for the most part as that is the only plugin I can use in my computer. I can't use GLideN64, for example. The Jabo plugin in earlier versions of BizHawk causes the same results as Rice. It doesn't matter which of the 2 plugins I use. I also used the Angrylion plugin and the same results happened to me.
I've tried various SM64 ROM Hacks with various degrees of results:
- Super Mario Star Road: Deluxe Edition (Game freezes)
- SM64: Last Impact (Game freezes)
- Super Mario 74 Extreme Edition (Game freezes)
- Super Mario Bros. Super Show 64 (Game freezes)
- Chao Bandstand (Game freezes)
- SM64 The Green Stars (Game freezes + Instant Death)
- Melee Adventure 64 (Instant Death)
- Arcade Fighter 64 (Instant Death)
- Super Mario 64 Land (Instant Death + Graphical Glitches)
- B3313: Internal Plexus (Instant Death + Graphical Glitches)
- Star Revenge Redone (BizHawk crashes and closes)
- Waluigi's Taco Stand (BizHawk crashes and closes)
- Danganronpa 64 (Collission + Graphical Issues)
- Wheelchair Mario (Audio Stops Playing + Game freezes)
When I use Mupen-rr or even Project 64, savestates work just fine for me, so I don't know what's going on here.
It seems that this issue is not present in BizHawk 1.6.1, a very old version of the emulator.
Repro
- Open BizHawk and Open ROM.
- Choose a SM64 Hack ROM (any from the list above). For this example I will load B3313.
- Load the ROM and choose a save.
- Save a state in the Castle Grounds.
- Enter the Castle through the main door.
- Load the savestate you just made.
Output
Host env.
- BizHawk 1.6.1; Win10; Intel
- BizHawk 1.13.2; Win10; Intel
- BizHawk 2.7; Win10; Intel
- BizHawk 2.8; Win10; Intel
- BizHawk dev build at 5e3e65a2a; Win10; Intel
- BizHawk dev build at ad82f4f21; Win10; Intel
- BizHawk dev build at 02e9fea0; Win10; Intel
- BizHawk dev build at aa099e0; Win10; Intel
Yeah, savestates here interferes with almost any game at all. This should have made it impossible to TAS them at all (maybe we should waterbox the core?). Other games affected:
SM64 all levels in one by Kaze (playable, but FB emulation must be disabled, otherwise everything will be rendered upside down and every audio will glitch)
Issue still persists in 2.8. However in B3313's example, the graphics are messed up and I warp below the stage, but it doesn't result in an instant death anymore. I can't test both Ares cores at this point in time.
This will need further testing.
I can't test both Ares cores at this point in time. This will need further testing.
Please do. The "accuracy" core is probably immune from this thanks to Waterbox.
If this is confirmed to be not an issue in Ares, we should just close it, as no one cares enough to fix whatever is needed in Mupen.
Tried B3313 and Last Impact, the latter didn't make it past the title screen, the former loaded but had terrible rendering issues. But I didn't fall through the floor when loadstating.
Also I repro'd the issues with those 2 roms in Mupen64Plus. Leaving this open.
Just tested Super Mario 64 Land with the Angrylion plugin, and it's still happening.
THERE IS A WORKAROUND I DISCOVERED ON MUPEN64PLUS. Enabling "Use Expansion Slot" COMPLETELY changes the savestate format, allowing you to get around savestate issues. (trying to load a savestate that does not have this option crashes BizHawk).
Confirmed, when the Expansion Pak is enabled for Mupen64Plus, the bugs and crashes in B3313, Last Impact, and Super Mario 64 Land no longer happen on loadstate. Maybe we should change the default to enabled, at least for games not present in the gamedb.
So a savestate made without the expansion pack and loading that state with the expansion pack still enabled causes the game to crash, yet if it's enabled at all times it doesn't? That sounds like some issue with disabling the expansion pack outright.
I didn't try that because I assumed loading a state with different sync settings would fail, and from https://github.com/TASEmulators/BizHawk/issues/3092#issuecomment-1240843456 it sounds like that is the case.
With different sync settings the savestate would just be rejected (and if it were accepted somehow, it'd probably crash the emulator entirely). I only asked what occured when the sync settings matched. It sounds like from this issue if the expansion pack is disabled, then savestates are broken, yet if it was enabled, savestates aren't. This is assuming the savestate save and load have the same sync settings. So this would indicate an issue with disabling the expansion pack.
A look at the disable expansion pack code seems to indicate why this occurs: all "disabling the expansion pack" actually does is set some memory that tells the game the expansion pack is not present, and most games will abide by this and not try to access past the first 4MB. However the core still actually has the expansion pack present and makes no attempt to block writes by naughty games that ignore being told the expansion pack not present (no surprise hacks are affected by this). And savestate code will just ignore the latter 4MB of RDRAM, so this leads to an obvious desync here.
BUT, in case of B3313, loading a savestate just after a few frames on startup (about at frame 7), major graphical glitches appear no matter if expansion slot is enabled or not.
Mupen's savestates might not be correct, but I would still consider this a gamedb issue, because if the savestates worked properly you'd still need to figure out that the Expansion Pak is required and manually enable it. Adding gamedb entries for these romhacks with expansionpak=1 would actually fix the problem, and I believe the current policy is to leave that to the user (or community) for romhacks.
The Patch Pending label and Won't fix label isn't normally used at the same time. (Unless you mean something I don't understand)