1
0

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

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

[quote="brett":31nynqg4]as most people would think it was just bad latency on playing a sound.[/quote:31nynqg4]

so true :)

  • You must to post comments
0
0

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

  • You must to post comments
0
0

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

  • You must to post comments
0
0

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).

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.