On Tue, Sep 11, 2001 at 11:48:48AM +0930, Alexander R Angas wrote:
> Pros:
> * song decoding done apart from event control so this aspect does not take up
> CPU usage in-game
One problem. Sound/Music and events are completely intertwined.
> * may get out of sync with animation, particularly looking towards the future
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)
> * may not get much of a performance improvement
I see very little overall performance improvement, if any. Because
you're still going to have to decode the music and synchronize events
with the gain game loop. There's the same amount (perhaps more!) of
overall work.
The underlying problem with the existing soundserver arrangement is
communication/synchronization between the soundserver and the game loop.
It was easy to pull off in DOS because you could set hardware timers and
have the soundserver interrupt the game whenever things needed to get
done. Things are actually much more difficult in a modern pre-emptive
multitasking OS where we don't have direct access to hardware
timers, are not guaranted response times for events, and have to
deal with high-cost context switching.
The unix soundserver is actually far efficient than the SDL soundserver,
mainly because the select() system call is quite efficient. Instead of
re-inventing the whole sound system, perhaps replacing the shared memory
event queues of the SDL soundserver with some win32-specific event queue
implementation would be a wiser alternative. (Part of the problem is
that SDL doesn't provide accurate enough timers for our purposes)
When it comes down to it, the differences between the various
soundservers are as follows:
1) how it's started (ie fork(), new thread, etc)
2) how the game loop signals the sound server
3) how the soundserver passes cues back to the game
4) the mechanism we use to sleep until the next note is fired.
if we're using fork(), then 2&3 are pipes. If we're using SDL threads,
then 2&3 are shared memory queues. The actual amount of OS-specific
code is rather small, as the main soundserver loop is completely
abstracted away from the communication mechanism. The worst part in the
SDL soundserver is (4) -- the sleeps take too long if we sleep teh full
amount of time, so we have to compensate by sleeping multiple,
shorter times.
> * may need to split up songs at cue points as well
This fills me with hate.
- Pizza
--
Solomon Peachy pizzaATfucktheusers.org
I ain't broke, but I'm badly bent. ICQ# 1318344
Patience comes to those who wait.
...It's not "Beanbag Love", it's a "Transanimate Relationship"...
