Opened 11 years ago

Last modified 9 years ago

#2693 new defect

SCUMM: Potential savegame incompatibility

Reported by: eriktorbjorn Owned by:
Priority: normal Component: --Unset--
Keywords: Cc:


I've only tested this bug with the latest SVN and the
VGA version of Indy 3, but it should be reproducable in
a couple of other games.

If I run the game using the Adlib music driver, _imuse
is created (even though the game does not really use
iMUSE), and when I save a game, the iMUSE state is
saved in it.

If I run the game using the PCjr music driver, _imuse
is not created (since the PC speaker drivers are not
played through iMUSE). But when I try to load the
previously created savegame, the iMUSE state is not
skipped. So the data is read back to the wrong
variables. Most noticeably (and probably least
seriously), the mouse cursor is corrupted.

Ticket imported from: #1508095. Ticket imported from: bugs/2693.

Change History (4)

comment:1 Changed 11 years ago by Kirben

The original versions of SCUMM 3 - 4 games, would check the
value of VAR_SOUNDCARD when loading a saved game, to make
sure it matched current sound driver. And reject the saved
game, if it didn't match.

We can either add dummy data for imuse to saved games, when
it isn't active in these games. Although there could be
unusal side effects when sound card drivers are changed in
some situations.

Or limit saved games in these games, to the specific sound
card driver used, when game was saved, like original

comment:2 Changed 11 years ago by sev-

Since we have all 'soundcards' in-place, I would consider
another route: give user a warning and force sound driver
change, i.e. something like this:

"This save was written with PC-Speaker sound driver. Current
driver is Adlib. Forcing PC-Speakier driver"

comment:3 Changed 11 years ago by lordhoto

I would prefer to keep the possibilty to switch the sound
driver while playing so you are able to use the same
savegame once with PC-Speaker and another time with AdLib.
It's much nicer than restricting a savegame to a specific
music driver.

comment:4 Changed 9 years ago by fingolfin

See also the (now closed) bug report #1804278 (Monkey) and #1752196 (in FOA).

In both cases, there are problems with missing/garbled cursor data. In the second bug I quote, there are 714 bytes of extra data *after* the iMuse data and before the cursor data, and I have no idea why...

Note: See TracTickets for help on using tickets.