Hi,

[Out of sync]

> This will be a large problem.  Especially for in-game events which wait
> for sound cues.  It's not as if sound->game events get queued up and
> delivered when teh game asks for 'em; the events are desinged to be sent
> to the game *right now*, and multiple events will clobber each other.
> Remember the long-lasting SQ3 pod door bug?  (granted, it was a
> different problem, but it's indicative of the problems that sound events
> can cause)

Still, right now we do queue them, and poll for them in a relatively large
number of places. If we replace this simple poll by some time-based
calculations, the result should be equivalent- provided that the queue is
polled before and after every call to the Sound() kernel function (which
we can guarantee).

Actually, for FreeSCI sound servers, we could even guarantee synchronity
in some way (within the limits imposed by the OS).


llap,
 Christoph


Reply via email to