The new option only works as intended if the engine that have TTS support apply their own settings. It cannot be globally implemented before and after runGame(), since the engines don't all use the same config manager variables (sometimes "tts_enabled_speech", "tts_enabled" or "tts_narrator, sometimes more than one of these).
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.
The vsync delay is 14 ms (1000 / 70), and using a loop with
a sleep of 10ms until we had passed that delay meant we were
actually waiting anytime between 14 and 23 milliseconds, which
made the game slower than it should be. This was partially
corrected by using a delay of 11 ms (800 / 70), but this was
still inacurate and too slow in average.
In addition, since the change in commit 87c8b60, it was ignoring
the time spent in the game loop, which on slow devices is not
negligeable, and this has been fixed as well.
Finally also change the fast speed from 20 to 4. In commit
87c8b60 the delay was changed from macroseconds to milliseconds,
and any speed above 14 would then result in a delay of 0 due to
the integer division. We have the turbo mode for that, so it
seems to make sense to make the fast mode a bit slower rather
than having two modes that do the same thing.