Hi Ravi,
[Selectors: Flexible?]
> FreeSCI, and I assume the original Sierra interpreter as well, requires
> that the first four selectors in an object or class be species, superclass,
> name, and -info-, all in that order. There's nothing that I can see
> philosophically wrong with having them listed some other way, however,
> since class definitions include the property ID list.
Theoretically, you are correct.
> Going even further,
> there's nothing philosophically wrong with giving these selectors
> nonstandard ID's since VOCAB.997 can be used to lookup selectors with
> special meanings to the interpreter.
Again, you are correct- theoretically. Practically, of course, it's a
waste of resources to look them up all the time if every object and class
needs them anyway.
> I'm not saying that FreeSCI should allow this, but it does make me ask the
> question of what other special selectors are there that don't get located
> through VOCAB.997 and the property ID lists?
Here's the list (from src/include/vm.h):
-----------
init; /* Init function */
play; /* Play function (first function to be called) */
replay; /* Replay function */
x, y, z; /* Coordinates */
priority;
view, loop, cel; /* Description of a specific image */
brLeft, brRight, brTop, brBottom; /* Bounding Rectangle */
xStep, yStep; /* BR adjustments */
nsLeft, nsRight, nsTop, nsBottom; /* View boundaries */
text, font; /* Used by controls */
type, state; /* Used by contols as well */
doit; /* Called by the Animate() system call */
delete; /* Called by Animate() to dispose a view object */
signal; /* Used by Animate() to control a view's behaviour */
underBits; /* Used by the graphics subroutines to store backupped BG pic
data */
/* The following selectors are used by the Bresenham syscalls: */
canBeHere; /* Funcselector: Checks for movement validity */
client; /* The object that wants to be moved */
cycler; /* The cycler of the client */
dx, dy; /* Deltas */
edgeHit;
b_movCnt, b_i1, b_i2, b_di, b_xAxis, b_incr; /* Various Bresenham vars
*/
completed;
illegalBits; /* Used by CanBeHere */
dispose;
prevSignal; /* Used by DoSound */
message, modifiers; /* Used by GetEvent */
owner, handle;
cue;
number;
max, cursor; /* Used by EditControl */
nwordFail, syntaxFail, semanticFail; /* Used by Parse() */
claimed; /* Used generally by the event mechanism */
elements; /* Used by SetSynonyms() */
----------
It's possible that the SetJump() syscall uses some more selectors (the
target object looks vaguely like a Bresenham structure, though), but,
other than that, these shold be all selectors used in SCI0. I think.
> AFAIK, those are the only four
> in FreeSCI.
not... quite :-)
> Back in July, Lars mentioned that the Sierra interpreter has
> hard coded selectors in event handling. Which are those, and what's
> important about them: their property ID's, their offsets in the class
> defition, or both?
Frankly, I don't know. Referring to them by their IDs has worked nicely
until now; referring by their addresses would be faster, but would have to
be done on a per-class base.
Actually, this is an interesting idea... generating selector offset LUTs
for each class should help improve performance for the selector lookup
function.
> Is it fair to make any assumptions about them when
> VOCAB.997 is missing?
No. The selector ID lists are similar, but not identical. I had a look at
this problem back when I tried to get the LSL3 demo up and running, and it
turned out that some of the selectors listed above are in different places
for different SCI0 games.
The most sane approach would be to generate a vocab.997 patch file for the
demo...
llap,
Christoph
