Beginning Game Audio Programming [Electronic resources] نسخه متنی

Chapter 11, you should stop reading this and go back and learn those concepts. OpenAL shares 90 percent of the concepts used by DirectX Audio's 3D sound implementation.

Sources, Buffers, and Listeners

The OpenAL functionality revolves around three main kinds of objects: sources, buffers, and listeners. Listeners in OpenAL and DirectX Audio are conceptually the same thing; in OpenAL audio, there's still only one listener, which represents the ears of the in-game player.

However, OpenAL has a new object—a source—as well as a different meaning for the term "buffer." An OpenAL buffer is the PCM sampled data itself, whereas a source describes an instance of a buffer, a position from which a certain buffer emanates (see Figure 14.1).

Figure 14.1: Multiple sources can reference the same buffer.

OpenAL uses these constructs so that if, for example, your game has three different helicopters, you don't need to load three copies of the helicopter WAV file into memory. You load the WAV into a buffer, and then create three sources that reference that same buffer.

From a different angle, both APIs have this capability. In OpenAL, you have multiple sources referencing a single buffer, which contains the actual sound data. In DirectX Audio, you have audiopaths; you could say that an OpenAL buffer is equivalent to a DirectMusic segment, and that an OpenAL source is equivalent to an audiopath off that segment.

It Isn't COM Anymore

The DirectMusic API is driven by COM, which means by now you're used to dealing with acquiring and releasing interfaces. OpenAL is not COM. Since it's cross platform, it relies on the triedand-true method of API interfaces—a big list of functions, enums, and structures.

OpenAL (and OpenGL too, for that matter) adheres to a strict naming convention for its functions. If you look in the API reference, you'll see several functions whose names are almost identical—except one will end in f, another will end in fv, and a third might end in i. These correspond to the type of data the function takes as arguments.

For example, there are four functions with names alListenerf, alListener3f, alListenerfv, and alListeneri (by the way, all OpenAL functions start with al). All four of these functions do the same thing—they set the properties of a listener. However, alListenerf takes one floating-point argument, alListener3f takes 3 floats as arguments (a vector), alListenerfv takes an array of floats (a vector in the C++ sense of the word), and alListeneri takes an integer. This seems weird, but it becomes second nature once you get the hang of it, and makes it more difficult to accidentally get your data types mucked up.

Buffer Properties

The available properties for a buffer are summarized in Table 14.1. As you can see, they all relate to the properties of the wave file originally loaded into the buffer.

All of these values are read-only, set when you call alBufferData to pump a buffer full of sample data. Since all of these properties are integers, you can read them by calling the OpenAL function alGetBufferi.

Source Properties

OpenAL sports several properties for its sources (see Table 14.2). Most of these you're already familiar with from the last chapter, but there are some new ones, too.

You can set these source properties by using the OpenAL functions alSourcef, alSourcefv, alSource3f, and alSourcei. Retrieve them by calling alGetSourcef, alGetSourcefv, alGetSource3f, or alGetSourcei, depending on the data type of the property.

Listener Properties

The OpenAL listener also has a handful of properties, summarized in Table 14.3. You can set these properties by calling the alListener family of functions (alListenerf, alListener3f, alListenerfv, and alListeneri). Retrieve their values by calling alGetListenerf, alGetListener3f, alGetListenerfv, or alGetListeneri.