Game Development Reference
In-Depth Information
This is the classic reader/writer problem, where you have a fixed memory area with a
writer that needs to stay ahead of the reader. If the reader ever overtakes the writer or
vice versa, the reader reads data that is either too old or too new. When I heard
about this in college, the example presented was always some horribly boring data
being read and written, such as employee records or student class enrollment records.
I would have paid a lot more attention to this class if they had told me the same
solutions could be applied to computer game sound systems.
What makes this problem complicated is there must be a way to synchronize the
reader and writer to make sure the writer process only writes when it knows it is
safely out of the reader
s way. Luckily, the really nasty parts of this problem are han-
dled at a low level in DirectSound, but you should always be aware of it so you don
'
'
t
'
pull the rug out from the sound system
s feet, so to speak. Let me give you an
example.
In your game, let
s a portable stereo sitting on a desk, and it is playing
music. You take your gun and fire an explosive round into the radio and destroy the
radio. Hopefully, the music the radio is playing stops when the radio is destroyed,
and the memory used by the music is returned to the system. You should be able to
see how order-dependent all this is. If you stop the music too early, it looks like the
radio was somehow self-aware and freaked out just before it was sent to radio nir-
vana. If you release all the radio
'
s resources before you notify the sound system, the
sound system might try to play some sound data from a bogus area of memory.
Worse still, because the sound system runs in a different thread, you can
'
s assume there
'
t count on a
synchronous response when you tell the sound system to stop playing a sound.
Granted, the sound system will respond to the request in a few milliseconds, far
shorter than any human can perceive, but far longer than you could count on using
the memory currently allocated to the sound system for something that is still active.
All these complications require a little architecture to keep things simple for pro-
grammers who are attaching sounds to objects or music to a game.
'
Just like a graphics subsystem, audio subsystems can have a few different implemen-
tations. DirectSound, Miles Audio, WWise, and FMod are a few examples. It
s a good
idea to create an implementation-agnostic wrapper for your sound system so that
you are free to choose the implementation right for your game. The audio system
presented in this chapter can use DirectSound or Miles, and the only change you
have to make for your high-level game code is one line of code. Figure 13.4 shows
the class hierarchy for our sound system.
'
