As you might have seen when our twitter account blew up this morning, we’ve switched the mainline ioquake3 (master branch) to SDL 2. This won’t make a huge difference to the experience of playing Quake 3 and the assorted games that have been built with this engine, but if you’ve got a copy of Q3A please try out the new test builds. This will give us a chance to see if everything checks out OK.
Please report any issues you find with the test builds on these forums, in IRC, or on bugzilla.
Amazing work, guys. Thanks! 
I oppose the change, because SDL2 is suffering from a critical bug since over a year, which the developers fail to patch since December 2013 (despite patch being available) concerning multihead compatibility on Linux.
I have tried to get an ugly hack running to avoid it, but it seems there is no hope without applying the patch from the bugreport to SDL2 itself:
https://bugzilla.libsdl.org/show_bug.cgi?id=2192
The only remaining option is to run a separate X server … but that isn’t possible for me due to a bug in the nvidia driver. Running two accelerated X servers never really was well supported with any driver anyway, and it often crashes and fails as badly and randomly after updates as Xinerama does.
SDL 1.2 on the other hand never had multihead issues and seemed to be well supported in comparison.
We aren’t changing away from SDL 2
May I ask what the thought-of advantages of using SDL2 for ioquake3 are supposed to be?
It seems like SDL2 tries to support a lot of features of the modern age (touch display events, multi-window multi-monitor support, etc.) that are entirely irrelevant with a single window OpenGL game that was developed over 10 years ago and has no awareness of or future purpose for them anyway. Those new implements are at the root of the problem of most of the bugs that are still open in their bugtracker because they require more fundamental changes. To me it seems more reasonable to stick with the well-supported, less complicated, more tested, SDL 1.2 which obviously does a better job at what it is needed for and especially doesn’t suffer from such major bugs.
SDL 2 is more compatible with modern operating systems and platforms than SDL 1.2. Feel free to fork ioquake3 from the SDL 1.2 point and call it something else. It sucks that it doesn’t work in your edge case situation, but we aren’t changing from it.
I can only object to this claim, if thought through in detail. SDL 1.2 runs as well as ever on all versions of the PC operating systems Linux, Windows and OS X - there simply is no “more compatible” here and it is not like there are any other “modern operating systems” coming out for the PC in the near future. It is not like we have any major OS changes coming up the next years (like MS switching away from DOS or something…) which could possibly break what SDL does for quake3 (which is 1: mouse and keyboard input, 2: opening a window with an OpenGL context. Audio and 2D acceleration are done by OpenGL and OpenAL anyway.)
As for Android: SDL2 has no real Android support, it isn’t even available for Java. Theoretically though it is possible to use it through the NDK with C, which has severe disadvantages in terms of putting it on the android market and general device plus OS version specific compatibility. You can pretty much assume a 50:50 chance that an NDK app will crash at random on some arbitrary different device. No one uses NDK because of those issues. I figure that similar problems exists on the iphone OS. And seriously … playing quake 3 with touchscreen on a phone? It seems that this rather would be the “edge case situation” - compared to just someone using multiple screens on linux - even if ioquake3 would already be ported to those two OSes… Consider if you want to get it running on different OSes, that ioquake3 is already ported to Javascript, because that actually works out and has a future if the mobile devices just get a little bit faster http://www.quakejs.com/ .
Correct me if I am wrong please.
Maybe there will be an SDL3 when this whole ChromeOS, FirefoxOS trend progresses any further. Maybe then a few years into the future SDL 1.2 support will be dropped. Maybe there will be a Windows 10 that is binary incompatible and a new processor architecture? But now it isn’t like that and it won’t be any time soon.
This isn’t something you can “vote against”. You are not a maintainer of ioquake3. We are not switching back to 1.2.
Your options are:
Arguing against SDL 2 will get you nowhere.
Sir, you just have lost a loyal customer.
Hi, I’m an SDL engineer. Just wanted to clarify a few points.
SDL 1.2 is unmaintained. We will not be shipping another release. Occasionally we’ll accept simple fixes into revision control (for example, this is the only way to get a working SDL 1.2 on the latest Mac OS X, as we will not release a 1.2.16 with those fixes). All things should stop using SDL 1.2 as soon as possible.
SDL2 supports Android as an official platform. It has a small shim of Java code and the rest is, in fact, C. This has worked out okay so far, and as far as we can tell, most significant games are native code anyhow. iOS is always native code, and SDL2 supports that too. Although unofficial forks of various quality exist, SDL 1.2 doesn’t really support either, and the API isn’t well-suited to these platforms.
Even discounting the good possibility that everything is going to be an iOS or Android app some day, Microsoft did have a major change recently (Win8/WinRT/WinPhone development is dramatically different than prior Win32 development, and SDL2 offers ports to these platforms that hides most of that difference from the app). Mac OS X changes important game development APIs every release (SDL 1.2.15, the last official release, doesn’t even compile on Mac OS X 10.9 out of the box), and Linux desktops will soon want you to talk to Wayland or Mir instead of X11 (SDL2 supports all three, SDL 1.2 does not. Even SDL 1.2’s X11 support is becoming obsolete).
SDL 2.0.4 will ship with support for Google’s Native Client (it’s already done and in revision control), so you can build “Chrome” games out of the box, and engineers are currently working on making Emscripten support SDL2 so you can have SDL2 games in HTML5. That work is almost ready to ship, too (for 2.0.5?), so if you’re trend is correct, ChromeOS and FirefoxOS are already a done deal, if your app upgrades to SDL2.
None of these things are going to be supported in 1.2, which is a dead codebase. No one is working on SDL 1.2.
Moving to SDL2 will not only make ioquake3 live on a maintained codebase, but it will open up other features to them, like SDL_WINDOW_FULLSCREEN_DESKTOP, game controller support, force feedback, etc.
–ryan.
There are assholes already selling ioquake3 on iPad, iPhone, and on various and sundry Android marketplaces. I would very much like to replace them with a free experience.