There does not appear to be any reason to use a bit field instead
of a simple boolean for this one flag, since there are no other
flags that need to be set on Object like this.
In SCI3, index-to-selector tables no longer exist in compiled
object data (instead, the SCI3 VM uses selectors directly and
object data contains a bit map of valid selectors). In ScummVM,
the table is generated by Object::initSelectorsSci3 for
compatibility with the design of the ScummVM SCI VM. For
consistency, _baseVars is converted to use a standard container,
which works for all SCI versions.
The table for SCI3 property offsets is also changed to use a
standard container instead of manually managing the memory with
malloc/free.
Sometime during SCI2.1mid, the palette manager was changed to
save and restore the source palette, and to add in-game gamma
correction. Previously, only the vary start and target palettes
were saved, and gamma correction was only configurable in SSCI by
editing RESOURCE.CFG.
Commit 5de2668939 silently changed
behaviour from running this code only when restoring a game, to
running all the time, in an apparent copy-paste error.
Memory references and integers in SSCI are both 16-bit numbers,
so game scripts frequently (incorrectly) use an IntArray instead
of an IDArray for holding references. Since references in ScummVM
are 32-bit reg_ts, IntArray entries must be large enough to hold
reg_ts in order to be compatible with game scripts that store
references in integer arrays.
The alternative solution is to find and patch all incorrect use of
IntArray across all games. This is possible, but a bit risky from
a save game stability perspective, since incorrect IntArray usage
is sometimes not apparent until well after the array is
instantiated (like GK1's global interview array).
This change invalidates existing SCI32 save games.
This avoids a deadlock where the main thread (via reconstructPlayList)
tries to acquire the mixer lock (in soundPlay) while holding the SCI
music lock, and the audio thread is holding the mixer lock and tries to
acquire the SCI music lock (in miditimerCallback). Bug #6691.
Version 38 save games were added to the 1.9 release branch with
only changes to SCI32 cursor support; shortly thereafter, changes
to the general (SCI16+SCI32) save game metadata were committed to
master -- without bumping the save game version number. This
prevented SCI16 save games from loading correctly in 1.10pre, since
the engine expected that version 38 games would have this extra
metadata, but they don't.
This change invalidates earlier SCI32 save games, which separated
arrays and strings in an incompatible manner. Old save games
contain invalid references to a string segment which no longer
exists, and contain incompatible array structures that lack
critical type information.
When objects are added to a SegmentObjTable, it may cause the
internal storage for the table to expand and move to a new
region of memory. When this happens, all pointers to objects held
by a SegmentObjTable of the same type would be invalidated, due
to an implementation detail that should not be exposed. To prevent
this, objects are now allocated separately on the heap, so even if
the table's storage moves due to insertions, the objects owned by
the table will not, so references remain valid for the lifetime of
the object.
When new bitmaps are added and the underlying Common::Array needs
to move to expand, this invalidates all pointers to bitmaps, which
makes it basically impossible to use the bitmap segment since you
never know if a reference is going to be invalidated due to an
array move.
To solve this, BitmapTable is changed to hold pointers to
SciBitmaps that are allocated separately on the heap instead, so
when those bitmaps are looked up, the resulting pointers are valid
for the lifetime of the bitmap, instead of the lifetime of the
Common::Array used internally by BitmapTable.
Remap would crash SCI2.1early games with 19 remap slots, and
did not actually work in most cases in SCI2.1mid+ games.
The SCI16 implementation was moved to its own separate file but
was otherwise touched as little as possible, so may still have
similar problems to the SCI32 code.
1. Split SCI16 and SCI32 code into separate files
2. Use -32 prefixes for SCI32 code and no prefix for SCI16 code,
where possible, to match other existing code
3. Avoid accidental corruption of values from the VM that may be
valid when signed or larger than 8 bits
4. Added documentation
5. Add missing remap CelObj calls
6. Inline where possible in performance-critical code paths
7. Fix bad `matchColor` function, and move it from GfxPalette to
GfxRemap32 since it is only used by GfxRemap32
8. Fix bad capitalisation in getCycleMap
9. Remove unnecessary initialisation of SingleRemaps
10. Update architecture to more closely mirror how SSCI worked
11. Clarify the purpose of each type of remap type (and
associated variable names)
12. Split large `apply` function into smaller units
13. Fix buffer overrun when loading a SCI2.1early game with remap
14. Remove use of `#define` constants
15. Warn instead of crashing with an error on invalid input (to
match SSCI more closely)
16. Change the collision avoidance mechanism between the RemapType
enum and remap kernel functions
17. Add save/load function
The former template hack relied on specialized functions for various types. We
use a hand crafted set of functions for serialization functionality now.
KQ6 CD sets a global depending on lowres/hires state right at the
start and some scripts are using it instead of calling kPlatform.
This causes some graphics to be incorrect (well lowres)
in case the user saves in lowres mode, then switches to hires
mode and restores the previously saved game.
We now set that global directly after restoring saved games,
so that this issue does not happen anymore.
KQ6 CD demo did the same.
Causes issues in at least gk1 (option + inventory plane are shown)
Game::restore is not called, when doing restores from launcher,
so in the original interpreter this script code wasn't called
either.
Fixes option + inventory planes etc. being shown right after
restoring via launcher, when original save/load dialogs were
disabled.
Fixes graphical issues, when restoring saved games.
SCI32 did not clear the screen and also did not even redraw the
screen on restore. It only redraws elements that have changed.
Behavior verified using TSR in DOSBox (see comments).
Also added comment about clearing the screen for SCI16.
- Patch game super object for saving instead of game object
- Remove re-adding planes+screen items, game::replay does that
We would only have to do that for soft-failing on restore
- Change debug levels of kNumLoops/kNumCels to 9
- Add special comment about -info- selector in syncWithScripts()
This should now make ScummVM menu saving work properly at
least in SQ6.
Fixes restoring saved games, when ScummVM dialogs are patched in
Removing clearing planes+screen items as well, because the scripts
actually did that, but did not clear everything.
Fixes "Invalid screen item" message when entering options menu,
after restoring in SQ6.
+ Mother Goose SCI1.1
Fixes graphic issues when restoring from GMM
Also make the fix ups for Mixed Up Mother Goose, Jones + PQ2
get applied all the time (debugger command not included)
This means tick-based times are saved to save games, as in SCI32
engine, instead of seconds, which are not accurate enough. It
also means places in SCI engine that need to access game ticks
should do so through g_sci instead of g_system or g_engine.
Colin Snover
Willem Jan Palenstijn
D G Turner
Johannes Schickel
Martin Kiewitz
Filippos Karapetis