When a game deletes a script and then loads the same script again
before it has been fully deallocated,
SegManager::instantiateScript tries to reuse the same script
& locals segments, but it was failing to reuse the old locals
segment because Script::freeScript would unconditionally clear
the old locals SegmentId, which meant the old locals segment would
just leak.
This patch does not fix old save games which may contain orphaned
locals segments, but should prevent the problem from occurring
going forward. (It is possible to clean up these old save games,
but this is not a big leak so it doesn't seem worth the extra
effort to do so.)
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.
This groundwork enables an object to look up its static name
separately from the normal process that is used to populate
Object::_variables when an object is first constructed.
(The static name property needs to be able to be retrieved from
objects inside of earlier save games whose name properties may
have already been modified at runtime, so the code cannot simply
pluck the value out of Object::_variables when they are first
initialised and then persisted into the save game, as nice and
easy as that would have been.)
This commit also helps to clarify the situation with relocation
tables in SCI1 games that start with a zero entry.
Refs Trac#9780.
While extremely rare (only Rama script 64948 seems to have this
profile), it *is* possible for an object to have zero properties
(and thus, zero property offsets).
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
58190c36b4 because it has been
operating on copies.
Basically just grepped for getOffset calls being assigned to
uint16s and expanded those to uint32 when they looked trivial.
While some of these changes seem superfluous, at least for the
US/English SCI3 games where potentially impacted game scripts are
not large enough to have a problem with 16-bit offsets (e.g. when
feature detecting the sound type), at least some of these changes
are necessary for correct operation of the find_callk debugger
command in SCI3 games. There should not be a reason why any of
these variables need to be kept as uint16, in any case.
Audio played was "Tickets, only", subtitle shows "Tickets, please".
Also remove forcing myDialog for KQ6Print::say (which was added,
while fixing this script patch).
see a46f3c1625
Forcing myDialog causes issues during game over screen (bug #9771).
Bug is solved by this, but script patch isn't perfect right now.
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).
This "fix" is more of a hack, in the interest of making the game
completable. The root cause is a combination of two problems in
the game scripts:
1. Blink::init expects to receive either 0 or 2 arguments, but
it assumes that if it received *any* arguments, it must have
received 2 arguments. This assumption is wrong, though,
because--
2. soTorinWhoAreYou::changeState(0) calls
poPecandEyes::setCycle(Blink) without including a second
argument (the blink speed).
This ends up with the second parameter being some garbage, and
that garbage gets sent to kRandom which then complains about
receiving garbage.
The correct fix for this would be to fix soTorinWhoAreYou (in
script 51400) to pass a second argument to setCycle, but there are
not enough obvious spare bytes for a quick and easy patch, so this
workaround will have to do for now.
Fixes Trac#9779.
In SSCI, mouse events are received through a hardware interrupt
and the cursor is drawn directly to the graphics card by the
interrupt handler. This allows game scripts to omit calls to
kFrameOut without stopping the mouse cursor from being redrawn
in response to mouse movement.
ScummVM, in contrast, needs to poll for events and submit screen
updates explicitly from the main thread. Submitting screen updates
may block on vsync, which means that this call should really only
be made once per frame, just after the game has finished updating
its back buffer. The closest signal in SCI32 for having completed
drawing a frame is the kFrameOut call, so this is where the
update is submitted (by calling OSystem::updateScreen).
The problem with the approach in ScummVM is that, even though the
mouse position is being updated (by calls to kGetEvent) and drawn
to the backend's back buffer (by GfxCursor32::drawToHardware),
OSystem::updateScreen is never called during game loops that omit
calls to kFrameOut.
This commit introduces a workaround that looks at the number of
times kGetEvent is called between calls to kFrameOut. If the
number of kGetEvent calls is higher than usual (where "usual"
seems to be 0 or 1), we assume that the game is running one of
these tight event loops, and kGetEvent starts calling
OSystem::updateScreen until the next kFrameOut call. We also
then start throttling the calls to kGetEvent to keep CPU usage
down. This fixes at least two such known loops:
1. When interacting with the menu bar at the top of the screen
in LSL6hires;
2. When restoring a game in Phant2 and sitting on the "click mouse"
screen.
A similar workaround may also be needed for kGetTime, though loops
around kGetTime should preferably be replaced using a script patch
to call kWait instead.
The approach to video benchmarking used by SCI engine does not
translate very well to modern video devices -- it will either be
so slow that the games think the system is not capable of showing
normal visual effects, or so fast that the benchmarks overflow
their counters. So, game scripts that perform video benchmarking
are now patched to unconditionally return the highest speed value.
A pleasant but subtle side-effect of this change is that the extra
time sitting at a blank screen before the start of a game (while
benchmarks ran) is now gone.
Fixes Trac#9741.
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.)
At least some versions of Island of Dr Brain have a bMessager
instance in script 0 with a var count greater than that of its
class. This probably should never happen since it means the
object has a variable with no corresponding selector.
The next commit adds some extra sanity checking code to object
initialization, to warn on any other games where this happens.
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.
Since SCI3 scripts use selectors instead of offsets as operands
to property-related opcodes, the disassembler can look up and
display property names everywhere (unlike SCI2.1 and earlier,
which need to know the object being operated on to look up the
correct selector for a given offset).
In SCI2/2.1, variable indexes are used along with a range encoded
in the interpreter executable to determine whether an object
variable is a view-related variable. Operands to aTop, sTop, ipToa,
dpToa, ipTos, and dpTos are byte offsets into an object, which
are divided by two to get the varindex to check against the
interpreter range.
In SCI3, objects in game scripts contain groups of 32 selectors,
and each group has a flag that says whether or not the selectors
in that group are view-related. Operands to aTop, sTop, ipToa,
dpToa, ipTos, and dpTos are selectors.
Export functions may be relocated above 64k in SCI3, but exports
that do not have an entry in the relocation table must be handled
the same as SCI1.1-2.1.
The variable count returned by Object::getVarCount is populated
by variable 1 in SCI1.1, so specially reading the variable
explicitly for that engine version is not necessary.
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.
Colin Snover
Willem Jan Palenstijn
Martin Kiewitz
Tarek Soliman