SDL/Linux port

[z33ky]

I'm working on a Linux port which uses SDL to create the windows, the OpenGL context and manage input.
I'm implementing the sound backend through OpenAL and will (probably) rip some code from libsox to handle decompression of the sound data (MS ADPCM).

UUmPlatform_Linux is added and the build-system sets a preprocessor variable UUmSDL which functions orthogonally to UUmPlatform. This allows SDL to be selected for Windows and Mac as well, essentially "overwriting" the platform-specific bits handled by SDL.
The setting currently implies OpenAL, though that could be decoupled.

I'm pushing this work on my sdl-linux branch.

[madebr]

About external libraries, ffmpeg's libavcodec has bink support.
I can play intro.bik and outro.bik with vlc, so the support is sufficient.
Perhaps libavcodec can also be used to decode the audio?

[z33ky]

Yes, it also has a decoder for Microsoft's variant of ADPCM.
I've hooked it up and while I can make out some sensible artifacts it generally sounds very corrupted and overmodulated. I'm not sure if maybe I'm passing some incorrect parameter to ffmpeg or if maybe I'm handling the OpenAL buffer or sources poorly.
I'm also just hearing a single sound effect for different actions, maybe I'm not handling the sound-data coming from the frontend incorrectly, though it's just a buffer and a length, I'm not sure how I could mess that up.
I'm not sure how I'll debug it. I'll try shuffling some code around and hope I can hit a shot in the dark.

[z33ky]

I've progressed to being able to properly decode and upload single sounds, so I have the libavcodec stuff figured out.
It breaks down when I configure multiple channels, so I'll try to figure this one out now.

[z33ky]

Stuff sounds good now.
I'll need to clean it up a bit to properly free memory in error cases. I also seem to be leaking memory in non-error cases, but I'm not certain where from exactly - AddressSanitizer doesn't seem to give me the full stack trace (despite using no optimizations) and valgrind doesn't start because it doesn't like libx265. Maybe this can be caught on a review when I make the PR, so I'll just leave it for now and slap a comment on it.

I think some sounds that should be looped don't get looped.
The OpenAL buffer/source usage can probably be optimized.
It seems to run out of channels pretty often (i.e. sounds don't get played when lots is happening). I don't suppose this is a problem in the current Win32 backend?
These seem minor enough to defer fixing them after the initial PR.

So just a little cleanup and fixing the display mode/resolution handling and I'll be opening the PR.