The previous method wasn't good enough: we were still maxing-out at
96 (did the Decaf devs misread that as hex? Is that why the
emulator's limit is 150 instead?).
Anyway, this new solution is a little brutish, but I can't think of
anything else that would work: right now, I have the Organya thread
constantly polling a linked-list of the currently-loaded sounds, and
checking if their voices have finished playing or not. If they've
finished, they get freed.
When AudioBackend_PlaySound is called, if checks if the sound's voice
has been freed or not, and reallocates it if it has.
There doesn't seem to be a noticable overhead to this, and it keeps
the number of currently-allocated voices *very* low (from 10 to 20 on
average).
I'm getting some rare audio hangs. I tried doing some
regression-testing, but it's so random that I'm getting anomalous
results. That said, there were suspicious results around this change
(and also the way `mix_data` is initialised/cleared), so I'm
reverting this for now, and restoring it next time I encounter a
hang.
Currently doesn't produce sound unless you stop Organya from calling
AudioBackend_CreateSound, because it exhausts the Wii U's 150-sound
pool before the SFX get any of them.
The keyboard API allows me to bind multiple buttons to the direction
keys, unlike the controller API. I probably need to rethink the
controller API at some point.
With this backend, CSE2 can run on the Wii U.
It's not ideal - it doesn't have its own renderer yet, so it just
uses the software renderer, and it only displays on the gamepad,
because drawing to the TV as well makes the game lag.
Also there's no sound.
Also the lack of input rebinding is annoying.
Also does absolute nothing.
The point of these things is so it's easier to test out new ports.
For example, with the Null backends and the software renderer, we
don't need to write any code to build for other platforms.
In addition, by having no platform-dependant code, this can be used
to trace crashes. For example, I was having crashes on the Wii U,
despite there being no Wii U-specific code at all - the cause turned
out to be that the executable wasn't stripped, and it had nothing to
do with the code at all.
We need to avoid `WindowsWrapper.h` in the backends whenever we can,
to avoid name collisions (the Wii U homebrew library) defines its own
BOOL/TRUE/FALSE, which really doesn't work with CSE2.
