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.
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.
The final palette wasn't set so, for instance, at the beginning of
the RTZ intro the Infocom logo wouldn't completely fade to back. I
think this is the correcet fix for that.
The interpolation code for deltaType > 0 read past the end of the
workChunkSize-sized filled area of the buffer (which matches what MADE
did, as far as I can tell). Avoid this by repeating the last value.
The sound buffer used in decompressSound() is now stored so that
it can be re-used in the next call of decompressSound, specifically
in chunk type 1.
This caused some clicking/static in the intro of Return to Zork.
Thanks to eriktorbjorn for noticing the glitch and writing most of the patch.
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 fixes MT-32 emulator initialization. When the constructor is run the
paths like extrapath etc. are not yet set up. Thus, the MT-32 emulator would
not be able to find the necessary roms in case they are in the extrapath.
