Re: [freesci-develop] LSL3 demo support

[Christoph Reichenbach]

Matt,

> Is there a trick to get the LSL3 demo to work with freesci (either 
> Glutton or the stable branch)?
> Here is the error I got (error was the same with Glutton and 3.4):
> Detected game id: 0x00798ae3 (LSL3) interpreter 0.000.530
> Loading resources...
> Resmgr: Detected SCI0
> Mapping instruments to General Midi
> MIDI mapping magic: 96 MT-32 Patches detected
> MIDI mapping magic: 40 MT-32 Memory Timbres
> FreeSCI, version 0.3.4c
> Warning: Kernel function InspectObj[58] unmapped
> Warning: Kernel function ShowSends[59] unmapped
> Warning: Kernel function ShowObjs[5a] unmapped
> Warning: Kernel function ShowFree[5b] unmapped
> Warning: Kernel function StackUsage[5d] unmapped
> Warning: Kernel function Profiler[5e] unmapped
> Mapped 107 of 113 kernel functions.
> Initializing vocabulary
> _init_vocabulary(): Could not retreive selector names (vocab.997)

As the error indicates, the demo does not include the vocabulary table
(vocab.997). Let me briefly summarise what vocab.997 is good for,
which will make it clear why we need it in order to run.
  SCI uses a notion of message passing to invoke methods/member
functions of the objects it keeps in its heap. The implementation of
this mechanism is a bit "old-fashioned" in that it emphasises
flexibility over raw performance (compiled OO languages typically take
a different approach nowadays). The basic idea is that, during message
passing, any message sent to an object is prefixed by a special ID--
the so-called "selector". Whenever a message reaches an object, this
object and its superclasses are searched for something able to deal
with the message. This is done by checking whether the selector
matches anything that the object knows about.
  For example, the game object has support for a selector called
"play"; the method dealing with "play" is magically invoked by the
virtual machine during startup-- it's like the "main" function in
C programs. Selector handlers needn't be methods, though, they can
also be variables. Objects that represent things visible on the game
screen, for example, typically have selectors "x" and "y",
representing their game world coordinates.
  By the structure of SCI, the special-purpose kernel functions depend
a lot on the internal structure of objects. For example, several
kernel functions associated with graphics have to access the "x" and
"y" selectors of objects they are supposed to draw (or to deal with in
other ways).
  Now, for reasons of efficiency, Sierra didn't actually use strings
to name the selectors; instead, numerical 16 bit IDs are used. "x" and
"y" might be 214 and 215, for example. Becase FreeSCI implements these
aforementioned kernel functions, though, it needs to know what the
numerical IDs of the "x" and "y" selectors are, so that it can access
the correct variables. This information, however, is stored in a
resource called "vocab.997", which Sierra only used for debugging
purposes. Each version of Sierra's SCI interpreter could potentially
use different numerical IDs and work without vocab.997, because
Sierra's SCI interpreters were compiled specifically for each game
(unlike FreeSCI).


There is no "trick" to work around this dependency. If we knew the
mappings, some trick could be implemented, but the mappings are
unknown, so far. Using vocab.997 of some other game might work, but
doing that would require the resource (or information directly
obtained from it) to be shipped alongside the demo, which would
violate Sierra's Copyright (unless the vocab.997 also came from some
public domain demo).


-- Christoph