Depending on other game option checkboxes. This is used to
enable/disable the semi-smooth scrolling checkboxes for FM Towns Loom,
since it's only used when smooth scrolling is enabled.
The autosave refactoring that was done in
7adad5aaf5 used g_engine for identifying the
autosave slot. This worked for in-game save/load, but doesn't fit when
called from the launcher.
Fix by passing MetaEngine to SaveStateDescriptor ctor and using it for this
query.
Amends 7adad5aaf5.
This employs a "lazy" approach: the "format" for the credits stays
exactly as it was, i.e., perl code. Of course one may want to change
this to another format (e.g. YAML, JSON, XML; or also shell script or
AWK, like `configure.engine` uses). But I deliberately kept it simple,
to get a minimal change that is easy to verify. Any further changes to
e.g. the format can be layered atop this.
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.
Loading a savegame from the Launcher for FOTAQ was broken by
commit de879dd (QUEEN: Disable load/save until game is properly
initialized). The patch comes from libretro to fix an issue
described as "ScummVM allows you to load a previous save before
the game is properly initialised. At best, this leads to
undefined behaviour. Most of the time it causes a segfault."
This commit allows loading save game earlier than the original
patch so that loading savegames from the launcher works again.
I don't know the details of the issue that was seen in libretro,
but I tested this change with both address-sanitizer and valgrind
on both Linux and macOS, and neither tool report any issue when
loading a savegame from the launcher.
This fixes bug #11327 (FOTAQ: Loading save game from the launcher
doesn't work).
The _lastUpdateTime variable was not initialized before its first
use, which resulted in the first call to update() having a random,
possibly very long, delay.
This was a regression from commit 1c5cbbb (QUEEN: Remove autosave
code). So fortunately the bug is not present in the last release!
If the autosave slot doesn't yet have any file in it, when the
GMM save dialog is open, the autosave slot will show a default
'Autosave' entry which is write-only, to prevent users
accidentally making a savegame in that slot