DirectX. . . you do know it's more than just Direct3D? Audio plays as big a part in nurturing virtual reality as graphics, a sentiment that sounds exactly right to Logan Booker. He's been off investigating WDM, DirectSound, EAX and the long forgotten A3D.
Don't blame yourself -- it's hard to suppress the smile that creeps to the mouth in this age of six-month product cycles and recycled genres; a sly smirk when you realise there's still a subconscious prioritising of crucial elements in the games industry. Graphics first, sound second. So, while programmers worry about optimising 96-bit colour paths and making sure the AI doesn't leap off cliffs to attack fearsome package crates, a small group of engineers, versed in the ways of DirectSound and various doomed positional audio APIs, skulk beside the 3D engine and throw in the odd trigger and sound routine.
And a few moments before the product is sent out the door, someone idly play-testing the final debug realises the .38 Special sounds like a buzzard sucking down Vaseline. Mad fumble over upturned chairs and empty soda cans, and the publisher is beating the living snafu out of the audio programmer. Okay, maybe not the living snafu -- but it is about time we had a look at game audio.
Wavelets in the ocean'Typically, audio coding gets left to the last minute and is often done by someone other than a dedicated audio programmer,' says Peter Clare, Technical Director at Sensaura in the UK. It's hard not to agree; we've all seen games with sub-standard sound. Battlefield: 1942 blossoms instantly in mind, and it's only now, after four or so patches, that the engine can handle EAX and more than 16 voices. Still debatable though.
Why the sudden rush to get it done towards the end of development? '[It] reflects the (historical) lack of importance given to game audio. Happily things are changing and developers and their publishers are waking up to the benefits that good game audio can bring.' Peter says.
Audio engine development tends to run parallel to the actual game, as more developers realise the importance of a good audio engine. Like hazy flame or shimmering water effects, sound and music have the potential to heighten a scene beyond its simple three dimensions, rather than just complement it.
According to Creative's Liam Byrne, Developer Relations Manager for Gaming Applications, and Daniel Peacock and Carlo Vogelsang, Creative software engineers, 'The toughest part is to make sure a sound engine works everywhere . . . [a] low level sound engine [is used] . . . [it] talks directly to the APIs (DirectSound, OpenAL etc) and just abstracts away the low level API, so that it's easy to swap with whatever is decided for later on in the development cycle.' What this means is that a very basic audio engine is created early so programmers don't have to worry about sending audio calls to the engine. They also mention OpenAL, an open source and cross-platform alternative to DirectSound that has similar functionality. It's seen use in a number of recent titles, including Return to Castle Wolfenstein.
Way back in the day of Windows 95, budding developers and gamers alike got their first taste of DirectX. While it's doubtful people lined up at stores to purchase the OS specifically for its multimedia libraries, DirectX was none the less tantilising. No more programming archaic functions for Sound Blasters and Gravis Ultrasounds, or working with third-party audio solutions (such as Miles Sound System, seen in titles such as GTA3 and Warcraft 3; or LucasArts' iMUSE, used in all of the company's SCUMM-based games). True, the ISA bus would continue to plague developers for a few years yet until the mass uptake of PCI sound cards and the banishment of onboard memory to store samples, but things were looking sparkly.
DirectX 3.0 was the first notable version of Microsoft's 'solution' and to be fair DirectX is a solid idea. It consists of two interesting components: the Hardware Abstraction Layer (HAL), and the Hardware Emulation Layer (HEL).
The HAL stands between DirectX, your OS, and your hardware. When your system wants to manifest itself in multimedia form, and such a form could be generated by hardware, the HAL queries your system using the 'GetCaps' function in code (GetCaps has been known to lie from time to time, so some developers use a trial and error approach to determine the supported modes of hardware. This means gradually upping capabilities until the hardware crashes). If it's rendering, it'll talk to your video card. For positional audio the function will query your sound card. (On a side note, Windows NT, 2000 and XP all use HAL for standard hardware calls, and it's a significant part of the OS/kernel/hardware relationship.)
If HAL returns a negative on the functionality, the HEL kicks in to emulate. In our case, DirectSound would step in to do 3D audio -- and like any sort of software rendering, it's a poor substitute for hardware.
Along with this new way of doing things, DX 3.0 introduced 3D sound buffers, allowing developers to introduce basic positional audio without hardware support. However, DirectSound was very much an infant. The positional audio implementation in 3.0 was incredibly poor, fraught with problems including distortion and speed problems. On a 100MHz Pentium (a beefy system back then), the 3D buffers would consume 5.5% of the CPUs cycles. Per channel. That's [i]a lot[/i] of resources to burn for a single channel.
Even today, DirectSound is inferior to hardware sound provided by sound cards. It was nothing more than a novelty (and some may argue that it still is), and developers would likely been happier with a simple positional algorithm using basic stereo pan and roll-off.
MIDI groundMicrosoft must have been hard at work, because when it came back with DirectX 5.0, things had improved considerably -- 3D sound buffers could now be accelerated in hardware.
On show were DirectSound and DirectMusic, both multimedia-heavy subsystems dedicated to producing audio. While DirectMusic was a full-featured and provided greater control, DirectSound was a light-weight and flexible sound API -- perfect for games, where CPU time was better spent rendering frames than decoding WAVs or synthesising MIDIs. With this new DirectSound came a property set called 'Voice Manager' that allowed the creation of sound buffers without the need for hardware or software resources to be assigned to them until they were played. This meant sound buffers could be created without the fear of using up system resources as the OS would automatically distribute resources as needed: when the sound card queried the system to play the sound, all it needed to do was point the card to the memory address. Voice Manager made playing audio much more efficient over a PCI bus, as system memory has always been quick. On the slower ISA bus it wasn't something you'd do if you wanted sounds to play when they were called in code -- the latency was too prohibitive. DMA transfers over an ISA bus were also resource consuming -- 30% total cycles for a Pentium 90MHz. Ouch.
By this point in DirectX's history, VxD sound drivers had matured well, however the burden remained on sound card manufacturers to code them -- WDM (Windows Driver Management) drivers weren't too far down audio lane.
Crash! Bang! Crash!With the release of Windows 98SE, the audio situation degraded once again. Voice Manager was broken with DirectX 6.0, causing problems with games that used the feature. So what happened?
DirectSound had been recode
Issue: 137 | June, 2012