PaulModz
05-26-2006, 02:24 PM
It seems kinda rude to drop a new acronym and split, so here’s a quick view of XAct from 10,000 feet that took me a while to wrestle out of the docs. The whole project seems kinda stealthy for an MS release, and I even heard that the first game to use XAct was almost released without MS even knowing about it.
High concept, XAct provides a much higher level of abstraction than DirectSound, making it both easier to use and more powerful. Rather than dealing with sounds as individual streams of bits to be shuffled back and forth between buffers, XAct presents you with 3 major, high level components; WaveBanks, SoundBanks, and Cues (there are more, but these 3 are the only ones germane to grokking XAct.)
Sounds are defined in two different files, separating the raw audio data from the configurable parameters that determine how that audio is rendered (Pitch, Volume, Looping, etc). The configurable parameters are data driven, so you can open a project in the XAct GUI tool, change its pitch, and hear the new sound without having to recompile. WaveBanks and SoundBanks are both classes in the XAct object model and data files produced by the functional (if slightly obtuse) XAct GUI tool, and there's a command line version as well.
WaveBanks (xwb files) are collections of individual wavs that are bundled into a single file. WaveBanks support ADPCM compression, but not mp3. ADPCM creates files roughly 25% of the original wav size, while mp3’s are closer to 10%.
SoundBanks (xsb files) contain both individual Sounds which are pointers to a Wave in a WaveBank, and Cues which are pointers to Sounds in the same SoundBank. Cues are your main interface with XAct, since playing sounds is done by triggering a Cue. Individual Sounds and Cues can point to multiple objects, and some of their properties determine how the sounds are played when a Cue is triggered. Some of the properties you can set for sounds and/or cues are volume, pitch, reverb, priority and a bunch of other stuff that I haven’t come to terms with yet.
Some of the more useful features I’ve found so far are:
A Cue can randomly vary the pitch and volume of a sound within a given range each time a sound is played. This is great for making small, frequently used sounds seem less repetitive.
The maximum number of concurrent instances of a Cue can be limited, and how the engine handles running into that limit is also configurable.
A Sound can be configured to loop a set or infinite number of times each time its Cue is triggered, and when stopping a looping sound you can choose to stop it immediately or have it play to the end of the current iteration.
When a Cue containing multiple sounds is triggered there are a few ways things can go down:
All the sounds are played at once
All the sounds are played, but each sound can be offset by a fixed or variable amount from when the Cue is triggered.
Only one sound is played, and each sound is given a weighting that determines the probability of its being chosen
Only one sound is played in random or sequential order regardless of weighting.
You can create your own named variables that are mapped to various aspects of playback, either per Cue instance or globally. You can then get/set those variables at runtime, linking audio rendering to any program specific variable in your app.
Waves, Sounds, and Cues are accessed by their index values, and the tools create a C++ header file each time the XAct project is built. The header contains enums that map each item’s index value to an enum entry with the name you gave the item in the GUI.
There’s lots of other stuff I either don’t understand yet or don’t have bandwidth to get into. If anyone is trying to use the Managed interface, I’d be happy to share my working C# code. The docs for the managed interface are almost non-existent, and I don’t think I could have gotten it to work without Reflector. (I think the Managed interface is actually still in Beta)
High concept, XAct provides a much higher level of abstraction than DirectSound, making it both easier to use and more powerful. Rather than dealing with sounds as individual streams of bits to be shuffled back and forth between buffers, XAct presents you with 3 major, high level components; WaveBanks, SoundBanks, and Cues (there are more, but these 3 are the only ones germane to grokking XAct.)
Sounds are defined in two different files, separating the raw audio data from the configurable parameters that determine how that audio is rendered (Pitch, Volume, Looping, etc). The configurable parameters are data driven, so you can open a project in the XAct GUI tool, change its pitch, and hear the new sound without having to recompile. WaveBanks and SoundBanks are both classes in the XAct object model and data files produced by the functional (if slightly obtuse) XAct GUI tool, and there's a command line version as well.
WaveBanks (xwb files) are collections of individual wavs that are bundled into a single file. WaveBanks support ADPCM compression, but not mp3. ADPCM creates files roughly 25% of the original wav size, while mp3’s are closer to 10%.
SoundBanks (xsb files) contain both individual Sounds which are pointers to a Wave in a WaveBank, and Cues which are pointers to Sounds in the same SoundBank. Cues are your main interface with XAct, since playing sounds is done by triggering a Cue. Individual Sounds and Cues can point to multiple objects, and some of their properties determine how the sounds are played when a Cue is triggered. Some of the properties you can set for sounds and/or cues are volume, pitch, reverb, priority and a bunch of other stuff that I haven’t come to terms with yet.
Some of the more useful features I’ve found so far are:
A Cue can randomly vary the pitch and volume of a sound within a given range each time a sound is played. This is great for making small, frequently used sounds seem less repetitive.
The maximum number of concurrent instances of a Cue can be limited, and how the engine handles running into that limit is also configurable.
A Sound can be configured to loop a set or infinite number of times each time its Cue is triggered, and when stopping a looping sound you can choose to stop it immediately or have it play to the end of the current iteration.
When a Cue containing multiple sounds is triggered there are a few ways things can go down:
All the sounds are played at once
All the sounds are played, but each sound can be offset by a fixed or variable amount from when the Cue is triggered.
Only one sound is played, and each sound is given a weighting that determines the probability of its being chosen
Only one sound is played in random or sequential order regardless of weighting.
You can create your own named variables that are mapped to various aspects of playback, either per Cue instance or globally. You can then get/set those variables at runtime, linking audio rendering to any program specific variable in your app.
Waves, Sounds, and Cues are accessed by their index values, and the tools create a C++ header file each time the XAct project is built. The header contains enums that map each item’s index value to an enum entry with the name you gave the item in the GUI.
There’s lots of other stuff I either don’t understand yet or don’t have bandwidth to get into. If anyone is trying to use the Managed interface, I’d be happy to share my working C# code. The docs for the managed interface are almost non-existent, and I don’t think I could have gotten it to work without Reflector. (I think the Managed interface is actually still in Beta)