If an event’s ‘Oneshot’ property is set to ‘No’ that event will not stop unless the game code specifically calls for it to. Events that are not stopped will still be classed as ‘active’ and will remain in the DSP network. (This makes it possible for a sound designer to create an event with deliberately silent sections.) However, since every event in the DSP network consumes CPU, failing to stop events when they are no longer needed will result in CPU usage increasing every time an event is called. Extreme CPU usage can, of course, lead to stuttering audio and other performance issues.
1. Ensure that any event not specifically stopped by the game code has its ‘Oneshot’ property set to ‘Yes.’
This will cause the event to automatically stop once none of its sounds are active, removing from the DSP network and reducing CPU use accordingly.
Note that this is specifically the Event’s property, as distinct from the Sound Instance and Event Parameter properties with similar names and settings.
1. Create a template.
2. Set the newly created template’s ‘Oneshot’ property to ‘Yes.’
3. Base all created events that should not be stopped in the game code on the template created in step 1.
This technique is essentially Solution 1 via a template.
1. Ensure that each event that will not be stopped in the game code meets the following conditions:
– Has no more than one layer.
– Contains no more than one Sound Instance.
– Uses no Sound Defs that have spawning behaviour.
– Uses no ‘programmer’ sounds.
– Includes no parameters.
– Includes no effects.
Each event that meets these conditions will behave as if its ‘Oneshot’ property was set to ‘Yes.’
The ‘Oneshot’ property of newly created events is set to ‘No’ by default, since our analysis of recieved support requests indicates that this causes problems for a smaller number of users.
Information about the ‘Oneshot’ event property can be found on pages 139 and 374 of the Designer 2010 manual.
- You must login to post comments