0
0

I wonder how much of event processing should be handled by FMOD and how much should be optimized in client by us when we deal with many of JFIQ sounds.
I have a lot of (1000+) looped sounds on a level (say, torches, fountains, animals, water and fire sources, etc) with JFIQ behavior and Max Playbacks parameter is around 10. Also, Max Playbacks is set to sound category, not for only event, because a lot of different types of events may be placed on a level. So I wonder what is the best way to handle that high number of events?

I see two ways of handling this:

  1. Play all events right after level is created. After that, each tick (or once per some ticks) reasquire and play again all stolen/failed sound events. In this case, the biggest workload goes to FMOD engine: recalculation of closest, most audible sounds, mixing every available event.

  2. Filter events by distance and start only events around player (50-100 meters). Each tick (or once per some ticks) reasquire stolen events.
    In this case a lot of calculations goes to client wrapper code which deals with FMOD. Closest sounds should be found, (and also not only closest: if I have something like waterfall, audible from a great distance, I should check it either) and checked.

So, the question is, what behavior is better and should be used when we have to deal with large number of simultaneously playing events?

  • You must to post comments
0
0

It’s been a while since I did this, but I had good results on an FPS project using a variation of option #2.

Basically, those sounds that were inside of their ranges from the listener would update their JFIQ status every update. The other sounds would not check every update. Rather, each sound know when it was last updated, and would only check every 5 or so updates (depending on your update rate, of course). I also had to smooth out the distribution of sounds, so that not too many got checked every time. That way, FMOD wasn’t occupying too many resources trying to re-acquire a sound that I knew ahead of time (with a simple Distance^2 check) wouldn’t play. Once it was determined that it should play, it went into the list of playing sounds, and was updated with the rest of the JFIQ Events.

Hope that helps!

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.