I am always curious to see sound engines implement Doppler effects but not the more vital feature of having speed take time to propagate based on location of source and listener.
I am very impressed by FMOD’s overall scope and level of documentation, but I wonder if this feature is ever to be incorporated? Otherwise, I think I’m going to have to do this myself atop FMOD. It seems very analogous to your virtual voices feature. Please consider doing this… it could benefit from an elegant and integral approach, I’m sure!
- tone asked 10 years ago
we have always discussed this as something that could be added, (ie ‘real speed of sound’ feature), but just never got around to it. I think it would have to be optional, as most people would think it was just bad latency on playing a sound.
When implemented in a game correctly, this is an awesome feature.
I put this in Brothers in Arms: Road to Hill 30 after we finished our prototype, but had to remove it because enough content was created that had already "faked" the feel.
I definitely think the FMOD team could put this in the engine elegantly, but there would have to be knobs to turn so it can be tweaked for each game. However, if you’re already using FMOD you should lots of free time for writing said feature ;p
- vatoloco answered 10 years ago
I am finding it fairly simple to add this atop FMOD. The relatively simple design of the whole API suggests several ways to do it. I take the expedient of having a request to "play" a Channel be a "logical" request to consider it having started at its 3D position — I timestamp the sound with a sourceTime, notice the distance between the channel’s position and the ear’s position and calculate the "earTime" where its actual playback should commence, and throw it on a list of queued Channels waiting out their predelays.
Then, before calleding FMOD::System::update(), I check the Channels on this queue to see if (timeNow > channel->earTime), and if so, I start them playing in FMOD and move them to a queue of actively playing Channels.
The logic is not perfect, but the difference between this treatment and reality only matters if the ear was moving fast enough to be near the speed of sound, so I figure that’s good enough.
Has anyone done a fully dynamic streaming Channel yet, where the app supplies samples as needed during System::update()? I need to move my VOIP code to this.
- tone answered 10 years ago
A similar feature is actually supposed to be exposed through Channel::setDelay but unfortunately the ‘startdelay’ parameter is not implemented yet, just enddelay (you may ask why you would want an end delay, it was so that dsp tails could finish, such as echo, without cutting off prematurely).
Please login first to submit.