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
These are further warnings of the use of memset to clear a non-trivial
structure / class. Since it is trivial to add a default constructor to
these to initialise them instead, the memset calls can be removed.
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.
Use snprintf() instead of sprintf() to limit how much is written
to the buffer. Note that there are other places where it looks
like it could overflow, but they did not trigger warnings and I'm
guessing that it doesn't overflow in reality.
Recently we started to use this as new semantics, although in the past
we used simly <engine>_H. Now these guard defines are consistent with
rest of the files which are used in the engines.
