As of today, I’ve been working on an experimental branch towards SDL2 migration and I can tell you people that it’s cooking really nice!, all of it has been built along with SDL1 with certain code separation via some preprocessor directives generated at config time, I’m really loving this baby so far. This brand new and shiny SDL2 backend is now on its heaviest development state and it will be eventually merged onto the
master branch when I consider it appropriate (when it gets a little more decent if I may be sincere with you). Of course it’s working, it compiles and runs without any crashes at least, it has some flaws and deficiencies, but as you know SDL2 is barely seeing the light of dawn, as soon as it made it to RC1 I got interested to finally use it and give it a try. SDL2 so far has proven to be potentially the greatest feature present in htq2 for its v0.2 release!.
At a first glance, thanks to this wonderful new SDL we have a real scancode-based keyboard input interpretation instead of the “old” (but nevertheless relevant)
SDLKey-based one, yayyyyyy! at last!, this was by far the biggest pain in the A when it came to porting any Quake-based engine with SDL, including ioquake3. At the same time, it seems to me that I watched a much smaller performance hit on the OpenGL rendering system, specially when it comes to swapping buffers (but I have to make sure about that), I can also see great opportunities for htq2 as I dig deeper into the SDL2 source code, there are these cool new kids on the block that I’m considering in this very moment. Currently, I’m focusing my efforts into the most appropriate implementation for the input system.
These are the new features so far:
SDL_Scancode-based keyboard input interpretation (it makes run the game with virtually any keyboard now!).
- Use of the new
SDL_SetRelativeMouseMode(where available). If relative mouse mode is not supported on target platform htq2 will then proceed to it’s manual calculation through
- Use of
SDL_SetWindowBrightnessfor setting up the gamma ramp (it still doesn’t do any effect on my Ubuntu box at least).
- SDL sound system was left untouched (as it hasn’t changed at all in SDL2) and it works flawlessly so far.
- Several other equivalent SDL2 routine translations from SDL1 and some new calls that were necessary.
- Usage of SDL2 is optional through CMake via
What isn’t working so good by now:
- Fullscreen window support (I haven’t worked on that): It can switch to fullscreen back and forth, but internal surface dimensions do not comply with the current set display mode. I made a test case specially for this issue and apparently it’s likely to be a bug on SDL2. On full screen mode, resolution tends to be always at desktop resolution no matter what. The issue is officially open at SDL Bugzilla.
I noticed a few very small issues when I tried to compile it on my PC-BSD box, so far I can’t get it to run on these BSD systems because apparently SDL2 is unable to get a valid OpenGL context on that system for some reason (I haven’t dug deep enough on that issue yet) . I’m watching this library very closely while I’m writing to literally everyone on the SDL IRC channel, it’ll be almost a sure thing that SDL2 will come out with a bunch of little bugs and something tells me already that I’ll have to download their bleeding-edge source code in order to get the most of their fixes (specially on non-Linux/non-Windows systems).
You’re most welcome now to try out my SDL2 branch at GitHub and drop me a line for whatever you may find :). I’m open to contributions. This is the current topic on htq2 IRC channel under discussion, so join in :).