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
- [freesci-develop] Re: Event-driven sound server Stuffed Crust
- [freesci-develop] Re: Event-driven sound server Alexander R Angas
- [freesci-develop] Re: Event-driven sound server Matt
- [freesci-develop] Re: Event-driven sound server Matt
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
- [freesci-develop] Re: Event-driven sound server Stuffed Crust
- [freesci-develop] Re: Event-driven sound server Stuffed Crust
- [freesci-develop] Re: Event-driven sound server Stuffed Crust
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
- [freesci-develop] Re: Event-driven sound server Matt
- [freesci-develop] Re: Event-driven sound server Alexander R Angas
- [freesci-develop] Re: Event-driven sound server Christoph Reichenbach
