Now that I've thought it over for a while I think the better approach is to just set sfx_command directly for each sound event. The approach I outlined before doesn't give the engine the chance to prioritize sounds to ensure that uninterruptible sounds take precedence over others when they occur in the same game loop. The trick is that you have to set sfx_command to CMD__IDLE at the top of your loop, otherwise back to back occurrences of the same sound (like the player firing the laser twice in a row) would be missed by the engine (because the engine needs to see a change in the command value to recognize an event). Then on top of that you have to be a mindful that ideally there should be 1/22000 of second ( ~ 46 usec) between issuing CMD_IDLE and any code which issues a sound command on either side of the IDLE (i.e. before it and after it). If you're clever (and I think cramming Defender and Donkey Kong into the propeller establishes that [noparse]:)[/noparse] you could keep track of whether any sound commands were issued in a game loop and only set IDLE in the case where none were. That would get rid of the 46 usec requirement before IDLE, and you'd only have to ensure 46 usec after.
All of that being said there is still a potential pitfall in issuing absolutely essential sounds like YOU_DIE and PLANET_EXPLODE. If you don't ensure a 46usec window after commanding any absolutely essential sound then it is possible that the sound command could be overwritten by some other sound before the engine gets a chance to read it.
Also, I've realized that any sound with IS_UNINTERRUPTIBLE set will play until completion even if another uninterruptible sound is requested. That means that if, for instance, LANDER_DIE is playing when you issue PLANET_EXPLODE you will never hear PLANET_EXPLODE (a sequence of events which is quite plausible). I can probably squeeze in a new IS_HIGH_PRIORITY flag to ensure that YOU_DIE and PLANET_EXPLODE will always play if requested. If I can't manage the code space there are things we could do in the game engine to fix that issue, but I'll try to make it transparent to you.
Comments
All of that being said there is still a potential pitfall in issuing absolutely essential sounds like YOU_DIE and PLANET_EXPLODE. If you don't ensure a 46usec window after commanding any absolutely essential sound then it is possible that the sound command could be overwritten by some other sound before the engine gets a chance to read it.
Also, I've realized that any sound with IS_UNINTERRUPTIBLE set will play until completion even if another uninterruptible sound is requested. That means that if, for instance, LANDER_DIE is playing when you issue PLANET_EXPLODE you will never hear PLANET_EXPLODE (a sequence of events which is quite plausible). I can probably squeeze in a new IS_HIGH_PRIORITY flag to ensure that YOU_DIE and PLANET_EXPLODE will always play if requested. If I can't manage the code space there are things we could do in the game engine to fix that issue, but I'll try to make it transparent to you.
Post Edited (epmoyer) : 12/6/2007 4:47:23 PM GMT