Christoph Reichenbach wrote:
>
> Hi Lars,
>
> > The most important thing missing here is that the selectors in these
> > early games are twice the value they would be in newer versions of SCI.
> > It has already been partly implemented in the source tree, but will
> > probably have to be rewritten, taking a more general approach.
>
> OK. Unless someone really wants to do this, it'll have to wait until 0.3.
>
> > Another thing is that several kernel functions are implemented, but not
> > mentioned in the kcall table file. So either we need to revert to the
> > default mappings on-the-fly, or else be able to specify the names of
> > those kernel functions (using the config file, for instance).
>
> AFAIK, the kernel functions are identical among different SCI versions,
> with the exception of two arithmetical functions. Providing default
> mappings should take care of the problem; since only the christmas
> greeting card is affected, this shouldn't be problematic.
>
> > Christoph: Regarding the use of <game>::play instead of <game>::replay
> > for the RestartGame kernel call, I don't think it's a good idea. After
> > all, some games rely on it to start the game.
>
> I agree. Do you happen to know what exactly happens when the game is
> restarting? Calling <game>::replay generally appears to cause the game
My earlier "execution loop" document outlines the initialization steps
performed by the interpreter. One step says "Save the interpreter state"
- this is where execution picks up when calling RestartGame(). However,
RestartGame() performa a few preliminaries as well:
* Set the Restarting flag
* Kill the menu bar structures
* Stop all sounds
* Dispose all scripts so we won't have any stale pointers in our class
table.
* Reset the heap (but only the free list, the blocks themselves need to
remain in place, see below)
* longjmp to the place indicated in the "execution loop" doc.
the main of the interpreter finds out that Restarting is set, and calls
replay() instead. The contents of replay() is quite interesting, and may
be the thing we've missed: It's actually _longer_ than the play() method
because it starts by disposing some lists and their contents. The key
thing here is that although the interpreter has reset the heap,
execution continues in it and its objects are disposed of first thing
after the restart. We need to keep the heap valid somehow, so these
operations won't screw up. No new allocations are done until the object
killing ends.
Everything in the heap is required to remain valid, and allocations
(which overwrite the old blocks) will start only when all possible uses
of the old blocks have been used, so to speak.
Lars
