search

TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.2k stars 385 forks source link

Loading savestates break Super Mario 64 ROM Hacks #3092

Closed noddy360 closed 2 years ago

noddy360 commented 2 years ago

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:

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

  1. Open BizHawk and Open ROM.
  2. Choose a SM64 Hack ROM (any from the list above). For this example I will load B3313.
  3. Load the ROM and choose a save.
  4. Save a state in the Castle Grounds.
  5. Enter the Castle through the main door.
  6. Load the savestate you just made.

Output

B3313 v0 7 2022-01-17 23 19 25

Host env.

getCursorsExe commented 2 years ago

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)

noddy360 commented 2 years ago

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. B3313 v0 7 2022-02-19 23 50 57 This will need further testing.

YoshiRulz commented 2 years ago

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.

nattthebear commented 2 years ago

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.

YoshiRulz commented 2 years ago

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.

noddy360 commented 2 years ago

Just tested Super Mario 64 Land with the Angrylion plugin, and it's still happening. Super Mario 64 Land 2022-06-16 20 54 44

getCursorsExe commented 2 years ago

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).

YoshiRulz commented 2 years ago

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.

CasualPokePlayer commented 2 years ago

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.

YoshiRulz commented 2 years ago

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.

CasualPokePlayer commented 2 years ago

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.

CasualPokePlayer commented 2 years ago

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.

getCursorsExe commented 2 years ago

Should we reopen this until the RDRAM expansion bug is fixed?

YoshiRulz commented 2 years ago

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.

getCursorsExe commented 2 years ago

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)