I’m very new to fmod and searching for some best practices when using voice overs.
Background story in a few words:
We decided to integrate fmod in our fan project Meteor Mess 3D (a Maniac Manion remake) for adaptive background music and voice over handling.
Therefore we had to write a wrapper (a C++ dll) for accessing fmod from Gamestudio’s lite-c language (we use this as 3D engine). This task is almost
done … we can access most fmod basic features from within the engine.
Now, I read in the best practices documentation that for voice overs an empty dummy event should be used with programmers sound flag set.
So I wrote a short demo project in lite-c for fmod’s callback feature implementation. This works fine. I start the dummy event, the callback function
is called, I create a sound, the sound is played and then the callback function is called to release the sound. Everything fine so far.
Now my questions:
1) What exactly is the benefit using a programmer sound event in compare to directly doing a createSound without using events?
2) Currently I’m using getSubSound in my callback function to get a sound from within my fsb file. The problem is that I have to know the index of
the sound within the fsb file when I just know the filename. Is there a best practice to get a sound by name (or maybe a string id) from within an fsb file?
I’d like to avoid having my sound files as single files in the project … I’d prefer to have them bundled in fsb files.
Thanks in advance for your answers.
- Pegamode asked 7 years ago
thanks for your answer.
Is there a best practice how to handle all those dialogue-samples properly. The handling wouldn’t be a problem if I would put all my sound files in a folder and get them from there.
But I’d prefer to have them in an fsb file … is there a best practice to handle this, because in the game scripts I only know the file name of the sound, but not its index inside the
- Pegamode answered 7 years ago
If you are using FSBank to generate the FSB you can specify the ‘generate C header’ option which will output a header file which matches the sound name to it’s index. Something like this:
define DRUMLOOP16 0
define JAGUAR 1
define SWISH 3
Most users parse this file to generate some meta data which maps names to indices.
I think the primary advantage is that you can apply complex event behaviours on top of the programmer sounds, giving more control to the sound designer. There is also the benefit that they are triggered like events so your high-level triggering logic doesn’t need to interface with both the EventSystem and the FMOD Ex APIs. If you’re not using any complex event features and you’re happy to trigger them using playSound then that would be just as good.
Please login first to submit.