Renderables, Soundables...


I discovered that I have an ugly inconsitency in how the sound effects are getting played.

First of all, there ought to be an analogy for the structure used for drawing things (which I call renderables) and those for sounding things (lets call them soundables). These are differentiated from the graphics and audio engines, in that they operate on a more abstract level. The graphics engine for texas is OpenGL, and the audio engine is Aurex (something I made). The whole infrastructure supporting "renderables" is well worked out, but not so for soundables.

At first I tried combining renderables and soundables. This actually makes a great deal of sense, since the interface is basically identical.

Let's define a RenderPass as a function from a particular range RenderState to OpenGL. RenderState contains certain information like where the camera is positioned, and so forth; in fact we can include whatever we want (e.g., is it raining, should everything be blue, etc.) A Renderable, then, is just a class that has a RenderPass (RenderState) function, and an Update (T) function. Mathematically, maybe this is something like a function (RenderPass, T) |-> RenderPass; I don't know.

A SoundPass should be then a function from SoundState to Aurex. Likewise a Soundable would fit the above description and be a class with an Update (T) and Sound () function, where the sound function puts the sound into Aurex.

In fact, due to the nature of sound (we specify a certain duration of sound, not a static sound for a single frame) we actually need a slightly different model. Only the Update (T) function is neccesary, but it should also have access to SoundState; so it's really an Update (SoundState, T) function.

In the case of Renderables, we really want everything to be in C++. There are just a whole lot of OpenGL calls each frame, and a lot of sorting out to do in terms of what to draw. But in the case of Soundables, we really don't need that; it's sufficient to have it in Lua because on a given frame there will probably not even be one call to Aurex; during the majority of frames there is no sound starting or changing information (and in fact Aurex could not handle this many voices anyhow).

The solution, then, is to build the abstract-level sound infrastructure in Lua and save myself the work that would be building it in C++. Of course, as a caveat, this only handles "gameplay" sounds, interface sound effects are handled in a straightforward way already.

2008-03-17


◀ Back