0
0

Thinking of removing this function, would anyone miss it. It basically just lets you randomize volume/frequency/pan. I dont think this sort of high level behaviour is something that should be in the low level API and is more suited to data driven API , ie fmod event system through fmod designer events.

  • You must to post comments
0
0

It’s been a while since I worked on the code, but I believe that we used this on my last project. I also have a vague memory of removing the call, and replacing it with something that was a little more robust.

It’s also not that difficult to do something like:
[code:155bgjps]System->playSound(FMOD_CHANNEL_FREE, Sound, true, &Channel);
float freq, vol;
Sound->getDefaults(&freq, &vol, NULL, NULL);
RandomizeValues(freq, vol);
Channel->setFrequency(freq);
Channel->setVolume(vol);
// Other stuff...
Channel->setPaused(false);
[/code:155bgjps]

We’re using the event system on my current project, so this is less relevant to me now.

  • You must to post comments
0
0

Not relevant at all to us. Even if we were using the Ex API primarily, I’d probably want something like that to be a feature of our level on top of FMOD.

  • You must to post comments
0
0

We might be wanting to use this… we’re reducing our use of complex events to save memory and I’m guessing this is what we would use to add variation to sounds triggered through a "programmer sound" callback. I’ll bring it up with our audio coder.

  • You must to post comments
0
0

Nah, its ok… we’re going with "programmer selected" from a sound def instead.

  • You must to post comments
0
0

variations are a bit like sound definitions that have random vol/pitch variations, and those are available in simple events anyway.

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.