I discovered that I have an ugly inconsitency in how the sound effects are getting played.
@p
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.
@p
At first I tried combining renderables and soundables. This actually makes a great deal of sense, since the interface is basically identical.
@p
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.
@p
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.
@p
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.
@p
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).
@p
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