Every functionality has been implemented (audio options, text options, saving and loading).
The only thing currently missing from the menu is the thumbnail handling.
The mouse cursors get dithered correctly now and due to earlier fixes SAMNMAX seems to be in as good a state as DOTT regarding EGA dithering mode, so I enable it. Also added a post-load fix for the palette and the mouse cursors.
Also include room palette fixes for games that were saved with a different video mode. Unfortunately the scripts make changes to the room palette based on VAR_VIDEOMODE. The original interpreter does not fix that.
(original bug)
In LOOM, the scripts actually read the videomode var and make actor palette adjustments based on that. Which means for games saved in EGA mode, with the wrong videomode var value, there will be glitches.
This concerns not only Bobbin, but the script does things for various actors and costumes in various situations.
We just set the videomode var to the actual config after loading.
For Bobbin in normal costume, I also include a post-load fix for savegames that will not have the actor palettes fixed by the scripts (savegames that we allow in situations where the original would prevent them).
This does not improve anything about these modes for v2 and v3, except:
- brighter CGA colors
- v2 will also get the more accurate Hercules mouse cursor
I will do improve v2/v3 as separate tasks. v3 seems to be mostly fine, anyway, except for the actors (we dither them just like the backgrounds, but that looks different in DOSBox).
Since the saved mouse position uses game coordinates, any rendering mode
that causes the graphics to be rescaled will have to convert them to
screen coordinates before warping the mouse there. (The rendering mode
scalers are separate from the backend scalers.)
Prevent "stuttering" from starting the music multiple times (which may now happen due to the improved savegame loading for v1-3).
Also add some more tweaks to minimize stuttering, like setting volume to 0 during loading.
The result now seems to match what I get when using an emulator.
This fixes an issue in COMI, in which bringing up the recipe book and then pulling it down
left the recipe texts on screen on the new room for several frames.
This applies to the Mac versions of Loom and The Secret of Monkey
Island. There was a regression some years ago that caused the channel
data to be saved twice, and the instrument data never.
Unfortunately, this does nothing to fix the savegames that were broken
by the regression.
Don't try to update the _musicTimer in saveLoadWithSerializer(), because
we haven't yet loaded all of the savegame. Instead, do that in a new
restoreAfterLoad() method.
As an extra bonus, if an audio track was playing when the game was
saved, try to resume it from approximately that point.
Unfortunately, it turns out that _currentCDSound was not properly reset
when the song ended so loading a savegame made with an earlier version
of this feature may cause it to play music that it shouldn't. But that's
the kind of thing you should count on on the bleeding edge. Savegames
made after this change should be fine.
This was a regression that was apparently introduced when the animation
flag was cleared for the Mac cursor. The animation made the cursor show
up when loading older save games, but not new ones. That's why it went
unnoticed until now.
After my recent effort to do this for SCUMM3 I now try to achieve the same thing for v1/2. (Unsurprisingly) the step calculations actually have more in common with SCUMM3 than with the later versions upon which the code was based. However, I find the v1/2 code somewhat more difficult to fix than v3, since it is quite heavily twisted and refactored to fit into our common code. So all testing and bug reporting is welcome...
curRect.left is assigned in the script, and it is not modified. right is
assigned with the screen width - original left.
This results in bad highlighting of the verbs all over the line width,
instead of being limited to the actual string.
Due to that, sometimes the selection range of the up/down arrows overlaps
with some of the verbs, and then these verbs cannot be selected.
Solve by storing the original left value, and using it as initial x
position for the string (the actual right-to-left manipulation is done in
drawString()), and modify the value of curRect.left to match the string
that was actually drawn.
This bug is similar to the one that was fixed in 58e921eb87, but the
solution that was done there for v7 and v8 cannot work here, because the
string logic is much more complicated.
This commit introduces the following changes:
1. Graphics::loadThumbnail()
Now returns a boolean and takes a new argument skipThumbnail which
defaults to false. In case of true, loadThumbnail() reads past the
thumbnail data in the input stream instead of actually loading the
thumbnail. This simplifies savegame handling where, up until now,
many engines always read the whole savegame metadata (including
the thumbnail) and then threw away the thumbnail when not needed
(which is in almost all cases, the most common exception being
MetaEngine::querySaveMetaInfos() which is responsible for loading
savegame metadata for displaying it in the GUI launcher.
2. readSavegameHeader()
Engines which already implement such a method (name varies) now take
a new argument skipThumbnail (default: true) which is passed
through to loadThumbnail(). This means that the default case for
readSavegameHeader() is now _not_ loading the thumbnail from a
savegame and just reading past it. In those cases, e.g.
querySaveMetaInfos(), where we actually are interested in loading
the thumbnail readSavegameHeader() needs to explicitely be called
with skipThumbnail == false.
Engines whose readSavegameHeader() (name varies) already takes an
argument loadThumbnail have been adapted to have a similar
prototype and semantics.
I.e. readSaveHeader(in, loadThumbnail, header) now is
readSaveHeader(in, header, skipThumbnail).
3. Error handling
Engines which previously did not check the return value of
readSavegameHeader() (name varies) now do so ensuring that possibly
broken savegames (be it a broken thumbnail or something else) don't
make it into the GUI launcher list in the first place.
Instead of returning to the launcher, a game may now specify a list
of "chained" games and optional save slots. The first game is popped
from the list and started. Quitting still quits the entire ScummVM.
It seemed like the sensible thing to do.
These are cases where the screen is completely blank, showing text.
In such cases, no room is set, thus no room resources are available.
An example is the screen shown after the credits in the Zak FM-TOWNS
intro ("The next day..."). Thanks to segrax for finding this case.
This commit is based off pull request 522, but completely disallows
saving in such scenes, instead of adding explicit checks for them
A compiler could in principle decide that a ResType enum can
never equal 0xFF or 0xFFFF, and thus incorrectly optimize
the ScummEngine::saveOrLoad code. So check the value
*before* casting it.
