Thanks to benoit-pierre for finding this.
(see PR #3448, https://github.com/scummvm/scummvm/pull/3448)
I chose a different approach for the fix, since I wanted an easy way of detecting/preventing this for similiar cases and I also didn't want to have so much extra code in that particular script function.
Bump save version. New games will be UTF-8, the old ones will still be correctly decoded from kISO8859_1. Tested and adapted all targets (not the fan translations).
For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
The ingame graphics use up 208 pixels out of 224. The top and bottom 8x8 pixel tile rows are left blank.
This commit emulates that. But actually it looks ugly, especially in windowed mode. On a TV screen of that era it was probably unnoticeable.
TODO: GET RID OF THIS COMMIT AND FIND ANOTHER SOLUTION
This reverts the change from 1d5fd780 which was clearly wrong and caused this new bug (no idea what I was thinking there). To prevent the revival of bug #3721 I now added the proper code for a fix after tracking the whole bug with the DOSBox debugger.
- added a missing function that causes keyboard key presses to trigger certain sound effects
- improve keyboard responsiveness during idle animations (HOF only)
Reorganize all files in sub directories. The file placement isn't as intuitive as it might be for other engines, which is probably the reason why this hasn't been done before.
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.
