The high-resolution videos play back at much lower volume than the
original ones. This adds hard-coded values for how much to amplify
each cutscene. It's all done by ear, and it does introduce some
clipping, but I think it should be acceptable.
Of course, it could also be a problem with the audio decoder, so
this may be the wrong approach entirely.
It was possible to render the game unplayable simply by looking at
Jack's cigar box while waiting for him to return to examine the
lamp. Note that this bug is only present in the DVD version. For
whatever reason, it adds a dummy location for playing the cutscene.
Applying the bugfix in the CD version actually breaks the game.
Commit 00e59a3122 introduced a change to savegame handling which
results in savegame thumbnails only being loaded when necessary.
ZVISION's readSaveGameHeader() doesn't under all circumstances
initialize the thumbnail pointer and 00e59a3122 failed to remove an
otherwise unnecessary delete which resulted in the uninitialized
thumbnail pointer being passed to delete (UB).
Thanks to eriktorbjorn for noticing.
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.
I should have done this before it was merged, but I completely
forgot that dafioram had verified that the bug *does* in fact
happen in the original game as well.
Explicitly check if the time tunnel is open (and therefore shown in
close-up) before executing the scripts that draw the lever that is
shown in the normal view. This apparently doesn't happen in the
original engine, which suggests there may be a ScummVM bug. But it
still doesn't seem like the *wrong* thing to do here.
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
Added it into hasFeature() of all engines which returned `true` in
simpleSaveNames() before.
As mentioned in #788, SCI is not always using simple names, so it
doesn't have such feature now.
Engines with "simple" savenames would support "Run in background" in
save/load dialog and gradual save slots unlocking. Other engines
save/load feature would be locked until save sync is over.
Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
