No warning or error is given when playing back a movie with a different firmware than it was recorded with

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.14k stars 380 forks source link

No warning or error is given when playing back a movie with a different firmware than it was recorded with #2498

Open Sanqui opened 3 years ago

Sanqui commented 3 years ago

The movie was made in BizHawk version 2.5.2 and with the Sameboy bootrom (free to distribute). I'm attaching both as a zip as GitHub doesn't allow other file extensions:

bizhawk_sml_movie.zip

When loading this movie into BizHawk with a different bootrom loaded, BizHawk will just attempt to replay it and it will desync. It should give some sort of warning.

This is happening on Fedora but I believe @CasualPokePlayer reproduced it on Windows.

nattthebear commented 3 years ago

Ideally, the firmware system should temporarily service firmware requests with the hash specified in the movie when loading movies.

alyosha-tas commented 3 years ago

@Sanqui How did you make this movie? GBHawk should only load with the official BIOS files. I can't play the movie in 2.5.2. with only the Sameboy BIOS in the Firmware folder.

Sanqui commented 3 years ago

@JL2210 made this movie, but I can sync it with this setting:

I presume he reacted to this prompt to choose a firmware file, and just picked a (free) firmware he had on hand.

alyosha-tas commented 3 years ago

Ok, so you can right click on a firmware and set customization, I didn't even know you could do that.

Anyway, the movie firmware hash doesn't get sent to the core constructor, so this case will always be missed.

I guess it could get sent in with GameInfo.FirmwareHash, but the rom loader which creates the core doesn't know about it either.

Currently, the queued movie information which contains the hash is not accessible from where we need to get it in MainForm.

So, fixing this would be a pretty significant refactor.

YoshiRulz commented 2 years ago

Remaining work:

[ ] Expand check to cores using FirmwareSHA1 (seems to be old+new BSNES, CPCHawk, PCEHawk, and ZXHawk)
[ ] Make FirmwareManager scan for and remember all options, not just the final customisations (and use these when calling from CanProvideFirmware)
[ ] Set a temporary override dict on the CoreFileProvider when loading a movie (not sure when/where to clear)
[ ] Allow FirmwareManager to apply patches when calling from CanProvideFirmware