| Age | Commit message (Collapse) | Author |
|---|
|
These objects should have been initialized only during the first
pass. Double-initialization does not cause any visible problem
problem during normal operation (mostly it just causes memory
waste by making Object::_baseVars/_baseMethod double up their
data), but could have silently allowed games to receive bogus data
for an out-of-bounds property or method index, instead of raising
an error.
|
|
Upon investigation of Sound code across SCI32 games, it was
determined that there are actually (at least) 3 different
revisions, not just a single SCI2.1 version. This patch only
changes the parts of Sound code that are relevant to the correct
use of Audio32.
Fixes Trac#9736, Trac#9756, Trac#9767, Trac#9791.
|
|
1. Unlocking all resources of a type using a resource ID of -1 is
gone in SCI32;
2. Audio locks need to be serialized starting in GK2 for the game's
modified kDoAudio(1) call;
3. Audio locks in SCI3 must work more like SSCI, since at least
Lighthouse's `BackMusic::fade` method will attempt to unlock
audio that was never locked by a script. In SSCI (and now in
ScummVM too) this is a no-op; previously in ScummVM, it would
remove Audio32's own lock on the audio resource, resulting in a
use-after-free;
4. kDoAudio(1) starting in GK2 returns the number of active
*not-in-memory* channels being played, not the total number of
active channels.
Fixes Trac#9675.
|
|
|
|
|
|
|
|
This situation occurs rarely, but normally, when unreachable but
not yet GC'd objects use a superclass which has already been GC'd.
Thanks to @wjp for looking at this with me and clarifying what
was going on.
|
|
|
|
ObjMap owns Objects, so every time this map gets copied instead of
referenced, it creates a copy of every single object in the
associated script. This is expensive, and it breaks things like
the `Object::syncBaseObject` call in savegame.cpp, which hasn't
actually been doing anything since
58190c36b4cc84b3200239211d91b0291301db56 because it has been
operating on copies.
|
|
Save game metadata validity checks in SCI32 should all exist within
kCheckSaveGame32 since this allows most games to recover
successfully from an attempt to load an invalid save game. If
gamestate_restore fails, the game will usually crash because the
engine is left in an inconsistent state (game scripts have cleaned
up objects in preparation for a game load that is no longer
happening).
|
|
|
|
|
|
Script buffer data is modified after a script is loaded by
savegame operations, and, in SCI16, by string operations. Casting
away const to allow these mutations to happen is not a very good
design, so this patch just changes the privately held reference
to data to be mutable. (Public accessors still return immutable
data.)
|
|
This information comes directly from script data and is not
modified at runtime, so it does not need to be persisted in save
games, but does need to be set when reconstructing clones.
|
|
This is necessary for at least Lighthouse, which maintains the
state of Robots across save games.
|
|
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 5de2668939a6735da2b3438b7c586fc185791ef8 silently changed
behaviour from running this code only when restoring a game, to
running all the time, in an apparent copy-paste error.
|
|
GuestAdditions
|
|
integration
|
|
_delayedRestoreGame is always set and cleared at the same time as
_delayedRestoreGameId, and _delayedRestoreFromLauncher is written
but never read.
|
|
|
|
|
|
Since blockSize is asserted to be positive, buf can never be equal to _buf.
|
|
|
|
Additionally, add workaround to fix up old QfG3 saves with broken
_palVaryPaused state. Fixes bug #9674.
|
|
Fixes Trac#9581.
|
|
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.
|
|
|
