This email went out on the SDL mailing list today, and I thought it might be of interest to many of you. * What's happening with SDL? Over the past year and a half, I've been swamped with a newborn child and working on World of Warcraft. I finally have time to move forward with SDL development. I've caught up on the SDL list e-mail, and Ryan Gordan is hosting an SDL bug tracking system based on bugzilla: http://bugzilla.libsdl.org (ignore the SSL certificate warning, it's a virtual host on icculus.org) Here's what's happening: SDL 2.0, the intended complete rewrite of SDL is officially vaporware. Nobody has the year or so of time it would take to completely redesign and re-implement the level of platform support that SDL has right now. So, the ideas that were going to be in SDL 2.0 are going to be migrated incrementally into SDL 1.2 and SDL 1.3. SDL 1.3 is the experimental branch of SDL, where we will be breaking binary compatibility and upgrading the API to fix a few shortcomings and support new functionality. At one point SDL 1.3 had experimental render to texture support, but it wasn't possible to maintain the same GL context semantics on each platform, and it has been phased out in favor of the OpenGL vertex buffer object extension. The original render to texture code is in bugzilla as a patch relative to 1.3, for historical interest. Right now, I'm in the process of integrating the SDL 2.0 build system into SDL 1.2 and 1.3. This involves dropping automake and going to an autoconf based build system. It's more work, but it avoids the constant workarounds trying to stay compatible with three or four versions of automake that are common on the platforms SDL supports. In addition, I've set up enough C library support that SDL can potentially be built without any C runtime support on the target platform. A proof of concept was done on the Win32 platform. There is also a configuration header SDL_config.h which makes it much easier to set SDL up for new platforms, and other kinds of build systems. This work is almost complete, and you can check it out in SDL 1.2 CVS (http://www.libsdl.org/cvs.php) Other people are busy working on SDL as well: Bob Pendleton is working on multi-window support based on the SDL 1.3 code, and has some proof of concept work in progress for the X11 driver. Eric Wing is working on MacOS X 10.4 projects and Universal Binary support. Stephane Marchesin has contributed the glSDL code for inclusion in SDL 1.3, and will be integrated once the build system revamp is done. David Olofson is working on non-power-of-2 audio conversion in the SDL audio code. Once the build system revamp is done, I'll be doing a sweep of bugzilla to catch important bug fixes, review compatible API improvements, and I'll be putting together a SDL 1.2.10 release. * So you want to help? If you're interested in helping, you can grab the latest CVS snapshot and build it and test it out on any platforms you have available to you. http://www.libsdl.org/cvs.php If you have a bug report in the current version of SDL, please make sure it hasn't been fixed in CVS, and then submit a bug report to bugzilla. http://bugzilla.libsdl.org If you want to help with development, feel free to browse the bug list and pick up anything that you'd like to help with. See ya! -Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

To be honest, I stopped reading the main SDL list over 2 years ago, and even then I could tell that SDL 2.0 was never going to happen. They should have concentrated on getting OpenGL rendering into what they already have and making incremental improvements a long time ago.

Thanks for sharing Kylotan!

LazyFoo, since they're working on 1.2 and 1.3 rather than 2.0 I expect the API will remain largely constant. Once glSDL is integrated you should probably be able to switch to OpenGL rendering just as easily as you currently switch between DirectX and GDI now. (Which I bet lots of people don't know how to do, actually! But it is easy.)

Done through environment variables..

Example:
set SDL_VIDEODRIVER=directx
or
set SDL_VIDEODRIVER=windib

in a batch file prior to launching the app.

(you could also set them through system calls prior to starting SDL_VIDEO as well)