Added it into hasFeature() of all engines which returned `true` in
simpleSaveNames() before.
As mentioned in #788, SCI is not always using simple names, so it
doesn't have such feature now.
Engines with "simple" savenames would support "Run in background" in
save/load dialog and gradual save slots unlocking. Other engines
save/load feature would be locked until save sync is over.
Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
Have simplified the parsing of the COMPUTAN.TXT file prior to looking at
supporting the Polish file format variant.
These change should have no functional difference, but improve the code
by removing a set-but-unused bool in the MenuItem structure, fixing a
number of repeated "magic" values to be explicit as various buffer sizes
and replacing usage of strcpy with the safer version from our Common
code etc.
This previously crashed on the Polish version due to a variant file
format causing the parsing to make several invalid memory accesses.
This prevents this crash and any other in future, though it does not
fix the parsing of the variant file format.
This shouldn't be a problem, as current client code either must find a
terminator when parsing the byte buffer or have preknowledge of the
buffer size from a file size or fixed call, so the appended null
termination will not cause issues. This change thus allows client code
to add sanity checks to prevent reading off the end of the buffer.
The SoundManager filled the sound handles with zeroes, which made
the mixer confuse them with active sound handle zero. In my case,
this happened to be the intro music, and the music was stopped when
playWavSample() wrongly thought its sound handle was in use.
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.
