Unfortunately, this will only apply to new engines that
use the Engine::loadGameState method. Other existing engines call
loadGameState directly and provide their own implementations,
so there's nowhere convenient to add the call that'd work for
all of them
This is primarily future-proofing. Many games either show a message
or do some other UI action like closing an open game menu, and
obviously that should only be done when a savegame created by the
user is done, rather than for regular autosaves. By making this a
flag, when engines override saveGameStream, they'll be able to
tell if it's an autosave, and only do UI changes if not
This is a regression from b86840087. The side effect of it that on Mac the
splash screen in not visible at all. I hope that this does not trigger same crash,
as it happens now only once.
The engine ID identifies which engine should be used to launch the target.
Also remove the 'single ID' system. Different games from engines that used
that system now have different game IDs.
Also-By: Matthew Hoops <clone2727@gmail.com>
It was already possible to override the stretch mode per game
in the options dialog, but this was ignored when starting the
game from the launcher due to this bug.
Almost the entire file does not use the aliased PixelFormat except
for a single function, so just make that function work like
everything else already in the TU.
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.
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
