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.
Skipping a search for .CSC scripts when any .SCR files exist does
not work with at least Phant2, because it comes with an INSTALL.SCR
file. Searching unconditionally for .CSC files should not cause any
issues since the game scripts will either be in .SCR format or in
.CSC format, not both in the same game.
SCI3 changes the way that monitored channel works. In SCI2/2.1,
when a channel is monitored, it is the only audible channel. In
SCI3, monitored channels mix normally.
This is very noticeable in LSL7, where music disappears totally
during speech if the monitored channel is the only channel played
back.
This happens e.g. on the About page in LSL7 because of an
interpreter problem where bitmap handles are destroyed and then
reused without a kFrameOut call to remove old screen items from
the visible plane list before a kIsOnMe call that causes the
engine to try to read from reused bitmap handles with different
contents and dimensions.
This replaces bad memory reads on the About page in LSL7 with an
assertion failure, until the problem with the About page can be
properly addressed.
This code branch, existing since at least SQ6 but apparently never
used by any SCI2/2.1 game, is in fact the algorithm used by SCI3.
This fixes (at least) doubled rendering of transparent surfaces
like the background of the inventory window and conversation
choices panel in LSL7.
