Future Wars PC disassembly does not save disableSysteMenu variable.
After adding versioning to Future Wars saves this value was also
saved and loaded but using it on load seems to have caused the
action menu (EXAMINE, TAKE, INVENTORY, ...) to be disabled sometimes
when it is not supposed to be disabled. Thus, now skipping the loading
of disableSystemMenu variable for versioned Future Wars saves.
Fix bug #11547 ("CINE: FW: Game crashes during intro with MT-32 music").
Future Wars PC disassembly passes 256 to writeInstrument and
writeInstrument overwrites it with value 246 here. So the value
becomes 246 in the end.
Change structure initialization from C++11 style to older style to fix
clang compilation. Add null check to fix DeepCode warning about
possible undefined behaviour.
Add support for Operation Stealth PC 16 and 256 color versions with
AdLib and Roland MT-32 sound. Add support for 20 extended savegames
(Thumbnails, playtime etc) for both Future Wars and Operation Stealth
(20 because it fits on screen using the original save/load interface).
Details:
- Add versioning to Future Wars and Operation Stealth savegames.
- Add fade in effect to both Future Wars and Operation Stealth.
- Add mouse wheel support and keyboard support to moving in menus.
- Map middle mouse button to pressing both left and right buttons.
- Make interface more responsive (See manageEvents() and drawFrame()).
- Amiga versions should be completable but sound may or may not work.
- Atari ST versions completely untested.
Game options currently supported:
- Using original save/load interface
- Using transparent dialog boxes in 16 color scenes (Also for PC)
Console commands currently supported:
- labyrinthCheat (For cheating in Operation Stealth's labyrinths)
- disableLabyrinthCheat (Disabling labyrinth cheat)
- disableHacks (Disabling hacks, useful for testing)
- enableHacks (Enabling hacks, useful for testing. On by default)
This removes filename methods when it matched the Engine method.
Secondly, ensuring there was an overriden getSaveStateName method
for engines that didn't do the standard target.00x save filenames
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.
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.
