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.
The target is not just a bare "queen", but is postfixed by language
variant (and CD if used).
Using this for the savegame naming would be good as it allows several
language variants to have different co-existing savegame sets without
causing conflicts. However, if the savegame format is the same across
all language variants, then using the same naming allows easier
switching between languages if testing.
Currently the queen engine uses a single set of savegames named in the
format "queen.sXX" which are used for all languages, as the format
appears to be compatible across language variants. This may require
changing in future, if a variant with incompatible savegame format
is discovered.
This forces detection of the entries with missing MD5sums via the
fallback detector. This triggers will then trigger a warning
with the associated md5sum for the user to report to the team.
This tells the advanced detector to skip MD5 validation for this
detection entry, so only filename and size are used as per the
original detection code.
Each engine now only has to provide a single configure.engine file
adding the engine into the configure script, which then produces the
required other files automatically.
This is the third and final commit enabling fully pluggable engines.
Now providing an engine folder contains a configure.engine, engine.mk
and engine-plugin.h file, it will be picked up automatically by the
configure script.
This is the second part of allowing engines to be added dynamically.
Each folder in engines/ which must contain a file named "engine.mk"
containing the make definitions for that engine.
This is the first part of allowing engines to be added dynamically.
They are placed into a folder in engines/ which must contain a file
named "configure.engine" to add the engine, which is pulled into the
top level configure script automatically.
This allows to keep the engines to specfiy the files for translation close to
the engine sources itself.
Thanks to criezy for his suggestion on this approach.
