I wanted to have a callback when an event terminates, but I see a few problems. I had a question about the intent of EVENT_CALLBACKTYPE_EVENTFINISHED.
EVENT_CALLBACKTYPE_EVENTFINISHED is only triggered by a terminating parameter. This means events that have the new "one shot" property, will not fire this event even though the event finishes. Watching for EVENT_CALLBACKTYPE_SOUNDDEF_END would work for one-shot events, but not a general solution.
I’ve found cases where the callback would never get called. I play an event with a eventfinished callback. I then play another event that triggers a synchronous sound bank load, the first event appears to finish during the load, and the callback is never invoked.
Point 2 was more as fyi. Asynchronous loading and preloading is preferred in normal cases. I was more concerned with looking for a reliable event finished notification.
Does it makes sense to have a callback when the event is no longer active or do you believe polling a playing status is more appropriate.
- mmarks asked 10 years ago
I noticed Event::stop won’t propogate a EVENT_CALLBACKTYPE_EVENTFINISHED notification (or any other callback event for that matter). This is fine, I can just trigger the notification myself at the point I call Event::stop, was just wondering if this is intentional or not. Specifically is there any chance in future Event::stop will begin generating some kind of complete notification. Code could easily misbehave if it receives two consecutive EVENT_CALLBACKTYPE_EVENTFINISHED notifications, one I generate, and one from FMOD – I’d hate to see bugs introduced from this.
- Jade_Lee answered 10 years ago
Please login first to submit.