GoldSrc games: distorted audio, black screen
WARNING: EARRAPE!
Forcing pulseaudio (or rather, probably forcing anything other than PipeWire) mostly fixes this, see #176.
For HL1, I additionally needed to comment out the SDL2_AUDIO_ALLOW_*_CHANGE code in sdl2-compat so SDL_OpenAudioDevice gets exactly what it requests...it sounds like it didn't handle the sample rate change otherwise and played too fast.
SDL3 refuses to accept really low sample rates during device opens, in case another thing is going to come along and open the device at a higher rate later, so my guess is SDL2 always gave Half-Life 1 the 22050Hz it wanted. When the ALLOW_x_CHANGE flags are ignored, SDL3 just does the sample rate conversion transparently and everything works.
I guess we'll need a quirk for that.
No idea what's up with the black screen, but it's probably either loading the wrong GL library or the 32-bit binary is failing to get the right GL driver or something. Notably, 32-bit Counter-Strike: Source is rendering, though, so I don't know.
This is written to the console at startup, though:
Successfully compiled "gl_shaders/vs_world.vert"
Successfully compiled "gl_shaders/fs_world.frag"
ERROR: failed to link program!
Compiler reported: error: vertex shader lacks `main'
Without sdl2-compat (which might actually be some other LD_LIBRARY_PATH trickery that I broke trying to wedge sdl2-compat into this, and not sdl2-compat itself!), this writes...
Successfully compiled "gl_shaders/vs_world.vert"
Successfully compiled "gl_shaders/fs_world.frag"
Successfully linked program!
...and the intro screen and main menu renders.
Let me know if you need more info about what we query for SDL GL stuff for the GoldSrc games.
I wrote that shader code for overbrights, so happy to help :)
SDL3 commit 8857b0f13aebe62b1fc77eaa279ea13ba2af0c2e makes BuildAAudioStream change audio format, so it could be that there's a wide library of applications that don't expect the audio format change but do expect frequency/rate changes. DOSBox-X is one example of this.
So SDL2 also had format changes, and SDL3 has one fewer format than SDL2. :)
We did have apps that explode when they discovered float32 format by accident, but I thought they would have shaken out in the last ten years.
I think slouken is right on this: just always tell the app they got what they asked for and do the conversion for them in sdl2-compat.
I believe this is fixed for the 2.30.52 release. Please let us know if that's not the case!