Upgrading an FMOD-based sound system
- July 2023
Upgrading an FMOD-based sound system
- July 2023
In Palette Knight, I was given the task of creating the sound system for our engine. That means using the FMOD library to create functions that, given the name of a sound, would load the mp3 from the assets folder into the engine to be played later. I hadn't worked with the library before this point, so my implementation was pretty simple; 3 static arrays, defined at compile time, would store all the info I needed. One would store the sound pointers, another would store the channel type (if it was SFX or music) and the third stored the name -- and sounds would share the same index between arrays, so you could keep track of which was which.
There are a couple flaws with this execution: for one, you can only have a fixed number of sounds before the array fills up and you have to start unloading some. The number of sounds we used was 32, which didn't really prove to be a problem since there weren't a lot of sound effects that needed to be loaded in all at the same time. Also, complexity. Again, not a huge problem in this case, but every time you need to load, play, or free a specific sound, there has to be a O(N) search through the array before you find the one you're looking for.
CODE SNIPPET - Palette Knight Load Sound function
Lastly, this was a consistent bug that happened to us whenever a slime got stuck in a wall. (This happened during a presentation in front of the professors!! Uh oh!!) The problem here is that a slime tries to jump whenever it touches a ground tile - but when it clips into a wall like this, it tries to jump every frame, playing the jump sound every frame and making this nightmarish sound. This is more an issue with the collision system, but I felt a little responsible since there was an easy way for me to make this better -- just check if the slime sound is already playing, and if it is, don't play it again until the original sound finishes.
The problem was that the implementation I used was fire-and-forget, meaning once you played a sound effect, it was impossible to tell what happened afterwards. There was no way for FMOD to tell if the slime jump sound was already playing.
So, fast forward to me joining Wholehearted Games and starting work on Shroom and Doom. I volunteered to work on the sound system again - partly because I was already familiar with it, and partly because I wanted to fix some of the mistakes I had made before.
So what did I do? Well, Shroom and Doom was written in C++ so that means out with arrays, in with maps. That way, you can get rid of the name array from before, and this time have the name of the sound be the key that can find the sound pointer/ channel. This also means that complexity is down to O(log N)! But how did I fix the overlaying sounds issue? Well, to explain that, I have to go more in depth on how FMOD plays sounds.
There are two classes that are important right now: sounds and channels. A sound object stores the actual 1s and 0s that make up the waveform of the sound. Channels are what those sounds "play through"; i.e., when FMOD gets initialized, you give it a number of channels for the library to reserve. Then, when you play a sound, FMOD takes a channel out of that reserve and uses it as one instance of that sound. After the sound finishes, the channel gets put back in the reserve. I like to think of it as: sounds are TV signals, and channels are TV channels (creative, I know). The signal on its own is useless until you have a channel that can play it, and you can't tell if the signal is playing or not without the channel.
So knowing that, what I did was make a new parameter for the LoadSound function, a boolean named "giveChannel". If giveChannel was false, load the sound into the sounds map like normal. If it's true, give the sound its own channel, and save it in a respective channel map. Then, once you go to play the sound, check to see if it has a channel in the channel map. If it does, only play the sound through that channel, and only if that channel isn't playing a sound at that second.
The problem now is that FMOD only gives out channels to sounds that have been called using PlaySound. You can't just take channels out of the reserve on command. The solution to this I found was: if you're loading a sound that needs a channel, play it, but paused. That way the sound gets assigned a channel, but it doesn't play when you load it. Then in the PlaySound function, make a check to see if that channel is paused, and if it is, just unpause it instead of playing the sound.
CODE SNIPPET - Shroom and Doom Load Sound function
So now, if we have a function that calls PlaySound every frame, like the slime bug did, by default it sounds something horrible like this:
Now take the same sound, and instead load it with PlayOnce as true and:
Much better.