|Engine Module Type String||Audio|
|Module Type Usage||Single Type|
Audio Modules enable the Drag[en]gine to output sound and music. Audio modules are Single Type modules since only one can access the audio hardware at the same time. Audio modules are usually not too speed demanding. Choose the audio module resulting in the the best audio quality. What module is usable on your system depends a lot on the operating system in use as well as installed API libraries. Launchers usually do not download Audio modules on their own since games do not request them. Pick from the list of available Audio modules the one which matches best your system the best.
Every computer installation is unique which makes it difficult for game developers to produce an optimal engine. With the Drag[en]gine you can pick what works best on your system. Choosing the right Audio module gives you the best audio experience possible on your system. Each Audio module has different properties worth investigating.
What Operating System am I using?
Each operating system has its own way to output audio. Ontop of those native solutions Audio APIs have emerged like OpenAL or DirectSound. The problem with those APIs is that they are often limited to one operating system or provide not all features ( for example no EAX or other advanced 3D sound architectues ). The first step is to look for an Audio module which matches the your operating system and the installed Audio APIs. The informations of the individual modules state what systems and APIs they are designed for.
What Audio Features are supported?
Often you have only one or two possible APIs at hand so choose the module out of the possible ones which provides the most features. Not all Audio APIs can play all the audio features a game can use. This has various reasons outside of the scope of this text. Try out different Audio Modules to find the one which can produce the most rich audio experience. The individual module pages state which features you can expect. Still though testing is required since there are many compbinations possible so a module does not work for all configurations.
Launchers will provide you with a default choice for an Audio module. Usually this is a reasonable choice but often you have to do manual testing and adjusting to find the optimal module. The good thing is that once you have found your optimal Audio module you do not have to worry anymore getting new games.
Playing audio requires a different knowledge about the world than a Audio or Physics Module requires. To cope with this the Drag[en]gine game engine provides a Peer System with notifiers. Whenever the state of a resource changes you are notified. All resources are first loaded into CPU memory and reside inside the game engine. For each resource the Audio module is queried to create a Peer object which is your personal data object containing data in the amount or form you require. The Drag[en]gine game engine as well as other modules do not know neither do they care what or how you store things inside your Peer objects. You are not entangled by engine data structure formats or other limitations.
Like other modules the Audio module uses deWorld objects as the basic 3D structure for playing audio. A world object composes of a set of deScene objects. A scene can be considered a small cubic piece of space which can be filled with world geometry, objects or other elements. The reason for this system is rather simple. Using floating point arithmetic a boundary of precision is quickly reached which turns large world impossible to do properly. Using scenes this can be remedied. A scene has a local coordinate system relative to the center of the scene. The typical resolution is around 1/10mm depending on the size of the scenes. Inside the world scenes are located using an integer based coordinate vector. Usually one unit corresponds to the size of one sector. As you can imagine this results in incredible huge worlds without falling victim to precision loss and it allows to optimize better than using one huge world.
To deal with audio the engine provides a set of objects. The deMicrophone object are your virtual ears in the world and are added to scenes. More than one microphone can exist in a world but only one microphone is the active one and is used to capture audio from the world it resides in. To change the active microphone use the deAudioSystem object obtained from the game engine. You can set the active microphone to NULL to completely mute all output. Once a microphone is set it has to play all sound sources attached to the world as well as the microphone itself.
As sound sources three objects can be used. The deSpeaker object is used to play a mono sound and is subject to spatial modifications ( like position in space or movement speed ). Each Speaker can be assigned one deSound object which stores a mono sound in PCM format. Only mono sounds are supported through speakers since in a 3D world a stereo or multiple channel sound has no sense. Various parameters modify how the sound is supposed to be played. ( the thid object is the music object which is in the works, more to come soon ).
Playing sounds alone doesn't make a world come alive. Many factors influence how sound sources sound to us. This can be the location in space as well as the geometry in thr world absorbing sound to some degree. Furthermore a sound played in a bathroom sounds different than in a large room. deComponent objects as well as deTerrain objects represent solid or partially solid geometry which can reflect or absorb sound. The audio properties on these objects ( added once aggreed upon which one to use ) determine how they interact with sound.
How many functionality your Audio module provides is up to you. Not every Audio module is required to support all audio features. This is especially the case if the Audio module runs on limited hardware or uses an API which can not cope with all features. To get you started on Audio modules have a look at the deBaseAudioModule module.
Every Audio Module has to provide a compatibility value which indicates how well the module suits the computer it is running on. This value is a percentage value with 100% indicating full support and 0% indicating not running at all. Values above 50% are considered playable. The value has to be determied by examining the possible abilities of the Audio Module compared with the usable ones. If there is some support missing 0% has to be returned.
Games can request certain graphical features to be present. This value indicates how well the Audio Module can handle those features. A value of 100% indicates full support for all requested features whereas 0% indicates no requested feature is supported. If at least one feature is not supported 0% has to be returned. Usually this value is simply the number of supported features divided by the number of requested features. This value is important for the engine to propose a module to the user. Only modules with 100% are proposed. Should there be no matching module the best matching one is proposed with a warning about possible non-playability. Games are required to only request for features which are really a must for the gameplay and not neglectable at all.
Note: The audio system is still work in progress and will change until the first release.