Last night we finally combined the new sound code with @trelemar 's work-in-progress game called “Doon”.
The music (added by me) is by an Italian guy called Filippo Vicarelli and is running at 22kHz. Level data is coming from SD card.
We are just beginning to arrive to the level I knew we can go - and beyond.
I owe a big thank you to all the talented people here. Let’s keep working. You make games and ideas, and I will make sure in 2018, that there will be enough Pokittos to go around for everyone.
EDIT: I hope @trelemar forgives me for flaunting his amazing project. I think it deserves it and is going to set the bar very high indeed.
So there’s a few things here I’d like to clear up about this project, as I think it’s the right time.
Doon is just a placeholder name I randomly typed in when making a new build target. This game will not be called Doon. The main characters name however, is Doon.
This game runs at about 35-40 fps without any sound. With this brand new sound system just implemented, and this being the very first test build with SD streaming audio, the framerate is actually at a pretty playable point already. It’s not 100% ideal right now as alot of the game’s flow relies on a higher frame rate, but the progress already has blown me away!
I can’t thank Jonne enough for the awesome work he’s been doing lately on sound. This will most likely have all original music, made by anyone willing to help. I’d really like to avoid using any assets or songs that were not made specifically for this project. If you’d like to help with some music, feel free to message me!
Yep, you’re right about the framerate. Needs more.
Mind you, sound will always take cpu cycles, there is no way to avoid that.
Luckily this example is still running on the size-optimized but unbuffered and slower petitfatfs SD library. It is possible to squeeze more horsepower out
EDIT: it seems streaming sound from SD takes approximately 15-20% of your CPU. But going from 22kHz to 11kHz only changed the situation by 2-3 fps, so it seems SD card reading (not the mixing) is the bottleneck.
While it is a very cool and nice feature to play the music from SD, would it be more efficient in a game to play tracker music from ROM? There are e.g. Jonne’s RBoy tracker and I also found this https://github.com/JarkkoPFC/arduino-music-player. The latter solution also compresses the music data size somehow.
The strategy of optimization is to start from the inner loops. We will get to the tracker soon but let me explain whats going on.
The deepest layer is the DAC. Pokitto has three ways of making an analog signal. A bit-by-bit dac_write, a masked dac write and a PWM dedicated to sound. Bit-by-bit DAC gives the cleanest sound by far, whereas PWM is better for pulse waves.
The second layer is the sound interrupt. There are three alternatives: pokSoundIRQ (synth & SD stream), audio_IRQ (Gamebuino sound & SD stream) and pokBufferedSoundIRQ (used at the moment only for SDFileSystem wav player test)
Up to this point it doesn’t matter where the sound data comes from. Its about making the inner loop as tight as possible because all mixing is real time. So if calculating one byte of sound takes say 100 cycles, were already talking millions of cycles per second for the sound.
Sd streaming is a great way to test the system, because you know from listening on pc what you’re supposed to get out. Any cracks / drops / glitches can be caught and it stresses the system to max
EDIT: …aaand I just realized I can optimize even further. We are doing zero latency byte by byte mixing at the moment, where every byte gets the function call overhead. If we accept latency (eg. 10ms, inaudible for human perception) we can process in chunks of 256 to 512 bytes at a time, removing the push / pop stack operations that are now done for each byte. That could save a lot of cycles.
Thanks for the info! It is always very interesting. For the pure background music we can accept even more latency, e.g. several hundred milliseconds (supposing you mean the latency when the music starts)
What is masked DAC write? How DMA fits in the picture?
DMA is not used yet - at all. I haven’t had time to implement it. I have tested but not yet implemented.
Masked DAC is a faster way of writing the DAC by masking the DAC ports and writing the whole port at once. Unfortunately, it introduces some artefacts which I have not been able to eliminate.
Latency means the time it takes before the sound begins from the event that causes it. If we have a 256 byte buffer at 11kHz, will be filled with sound data in 11,6 milliseconds. This means that the “boing” sound of your jump will start playing 11,6 milliseconds after you have jumped. For reference iOS touch to sound latency is 50ms.
I wouldn’t mind if someone else wanted to work on the project. Can’t believe how long it’s been since I’ve really worked on anything. At this point if I pick up gamedev again it’s safe to say I won’t be coming back to this.
