On Wed, Sep 18, 2002 at 02:09:35PM -0400, Stuffed Crust wrote:

> On Wed, Sep 18, 2002 at 05:13:43PM +0200, Lars Skovlund wrote:
> > This might lead to a race condition of its own; suppose there are two
> > closely spaced cues in a song and the script checks for those cues
> > explicitly? At least, there would have to be a way to hold the changes
> > back, as far as I can see.
> 
> Again, how would this be any different in SSCI?  If there are cues that
> happen so close together for the VM to miss them, this would mean that
> the VM is running much too slowly.

This has changed in SCI01. Actually, I wasn't aware that things were
different in SCI0 until I had a look at ksound.c. In SCI01 (and later,
presumably), there is a special subfunction of DoSound() which updates
the cue value (and possibly other attributes) in the sound
objects. DoSound() is currently stubbed out for SCI01 games -
otherwise, QfG2 would not run at all. In fact, manually setting the
result of that kernel call (in Sound::check) allows the QfG2 intro to
play nearly to its completion - the plaza scene causes the usual
memory shortage, though.

>  
> > Yes. I have tried (and failed) to reconstruct a change log for
> > SSCI. One of the changes that I happened to find was a bug related to
> > restarting, probably a race. It is quite likely that more such bugs
> > existed, and it is obvious that the sound server was a pain to
> > them. They rewrote it completely for SCI01.
> 
> Now I still know very little about SCI01+'s sound system, but aren't
> many of these same classes of races still present? Or did they add some
> kind of synchronization mechanism?

There is one fundamental change in the driver architecture: Whereas
SCI0 gets by with two layers (kernel and driver), SCI01 uses three
(kernel, voice manager and driver). The integration of the voice
manager with the interpreter reduces the complexity of the driver and
possibly eliminates some sources of race conditions and timing
problems (though new ones are introduced, such as the MIDI event
injector).

Lars

Reply via email to