Wednesday, March 30, 2011

Thoughts about Sound

While my stated intention with DirectQ's sound code has been to port from Quake II, there are a few other options available, and lately - following on from a query on an earlier post - I've been thinking them through.

Some options - such as OpenAL - might look attractive on the surface, and might even be technically superior. But the big problem with these is that they would require a good chunk (I'd expect a sizable majority) of DirectQ's user base to install additional libraries on their machines. That defeats one of the objectives of DirectQ which is that you don't actually need to do this. Just install Quake, download DirectQ, make sure that you're on a reasonably up to date version of DirectX and you're off.

You'll note the precedent in my web download code, my PK3 support, my external texture loaders, and other examples all over the place. None of them need additional libraries on your machine. All the code is either contained in the executable or uses native OS components. So it's not a case of "you need libweenie 1.3.12 and it's your tough shit amigo if that conflicts with anything else you might have that needs a different version".

A reasonable argument could be made that such libraries do support portability, but since DirectQ is a Direct3D program anyway, portability is not even on the radar. I have the luxury of being able to say "I'm using the Windows API for this, GDI+ for that, etc" without having to worry about consequences, so the argument becomes irrelevant.

So these options are Just Not Going To Happen.

Porting Quake II's code was the leading option for a number of reasons, with the strongest being that it has the most similarity to Quake's (but with some essential extra features added), but there was a third option lurking in the back of my head which was to rewrite the entire thing from scratch.

Am I mad? Well I've already done it for the renderer, so why not the sound code too?

One school of thought says "it's working code, it's fine, don't mess with it". That's a very valid argument from one perspective, but it doesn't take in the whole story.

Quake's sound code is The Way It Is because it had to run on machines of the time. 1996, MS-DOS, Pentium 60, 8 MB of RAM, etc. DirectSound was grafted on for WinQuake, but the core sound code remains an abstraction layer that just calls down to whatever lower level API it happens to be using, but is otherwise much the same.

Besides, it's not really the way you write DirectSound code. Real DirectSound code looks something like the structure described in the First Steps in DirectSound Programming article in the DirectX SDK. Lots and lots of Secondary Buffer objects all of which are mixed together automatically by the runtime. No locking overhead, no mixing in software, no requirement to do extra updates if running slowly, everything nice and clean.

So I'm coming around to thinking that this is a viable approach. Aside from anything else, it will also allow for more advanced sound FX than Quake originally supported should I ever decide to go down that route in the future. I'm thinking stuff like room ambience, echo, underwater gargle, and so on.

5 comments:

David A. said...

Why Q2 and not Q3? Is Q3's code totally different or something?

gnounc said...

Porting Quake II's code was the leading option for a number of reasons, with the strongest being that it has the most similarity to Quake's

mhquake said...

Yeah, sometimes you have to go for which might be a technically inferior option for purely pragmatic reasons.

Ron said...

What Quake could really use is a wave tracing-based audio renderer, similar to the way Aureal's A3D technology worked (before they were bought up by Creative and the technology was axed in favor of Creative's EAX).

The obvious catch here is that, near as I can find, there's very little information about how such a system could be implemented in a real-time environment. Guerrilla Games implemented a wave tracing system in Killzone 2, but naturally they didn't publish much information about how their implementation works. Seems like there'd be a lot of discovery and dabbling in 'tricky maths' to pull it off.

mhquake said...

What I'd hope to be able to do is use DirectSound's 3D sound interfaces. They look to be quite simple and will give you attenuation, panning and doppler for free.

Of course there are going to be a LOT of subtleties to be worked out with this, and 3D sound is obviously somewhat more processor-intensive than 2D sound, but if it works out it should work out well.

I think implementing it on another engine as a first step is going to be a definite requirement here.

Another neat advantage of going down the "write my own in DirectSound" route that I didn't mention before is that it can peacefully coexist with the current sound system during any transition period. I think that's quite cool.