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.
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.
Engines should only have to call one set of functions and not decide between the two. In fact, the 'emulation' API was documented to just call the 'real CD' API.
In the original, a second SetHookScene call can validly occur due to first
placing the cover-switched book in the bookcase, and then by the thief
leaving if his arrival happens immediately.
- added support for MIDPAK.AD timbre files on top
FAT.OPL. FAT.OPL gets copied by installer into MIDPAK.AD for this version
- changed order of timbre file checking
- adjusted and improved comments about discworld 1 versions
eriktorbjorn owns a version of DW1, that only has FAT.OPL and no
SAMPLE.AD/SAMPLE.OPL. We check if SAMPLE.AD/.OPL are available,
if not we try our luck with FAT.OPL
Moved the creation of _midiMusic, _pcmMusic, _sound and _bmv from
the constructor to run(). It was reported on the forum that the
MT-32 emulator didn't work for Discworld, and I'm speculating that
this is because it was being initialized before the "extra path"
had been added to the search path.
It's likely that not all of these objects are needed for every
version of the game. Fixing that is left as an exercise for
someone more familiar with the different game versions than me.
This makes sure that the game path is only ever added once for the PSX version
of DW1. Most noticably this will make the warning about the game path being
present in SearchSet disappear on startup.
This reverts the endianess changes in commit c90d563 which do not work
properly in DW2 on BE systems (as GetSceneStruc()'s behavior is
different in DW2)
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.
