The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I disagree with Pallav and Mason on "ditching" X11 and GDI. For me the software renderer is essential. For example, on both my Linux desktops, the harware "accellerated" openGL driver is so slow that it's actuallly 50% slower than the SDL software renderer. And on windows, the GDI backend does wonders for compatibility with systems with a crummy setup. Not to mention a (future?) linux fbcon driver for the many tiny devices that don't have opengl/es. You'd be surprised how many of them there are out there. SDL is not only used for games, it's also the underlying api for GUIs in non-accelerated embedded devices. Look at DACHSview-SDL, CEGUI, Agar, Milkytracker on GPX2, etc. And, if you're writing a graphics or sprite editor in SDL, how will you draw to the bitmap that the user is editing if you don't have a software renderer? I don't think the software renderer is "holding back" development of SDL. What are those features that other 2D game libs have and that SDL is mising? When I look at Allegro 5, the main missing things are rotozooming, tinted blits, and the drawing of primitive triangles, rounded rectangles, ellipses, circles, arcs, splines and ribbons. It's not like a software version of those things are that hard to write. Just look at SPRIG, SGE, SDL_gfx, Allegro , or ... Plenty of sources we can ask to borrow code from (with Allegro it's even easier as it's zlib license is comatible with sdl's). I also disagree with Ryan though. I don't believe in a slippery slope argument. There are many things that SDL has been lacking historically, compared to other 2D game API's like Allegro. So everyone and their dog implemented software extension libraries on top of SDL to deal with these missing features. I think it's high time we enrichened SDL's 2D functionality. And now that SDL has a new renderer API, it seems like a great time to do that. The only thing I think which doesn't belong into SDL is 3D functionality, which belongs in the many diverse 3D engines that are built on SDL. I already found and fixed a small bug in the software scaling, and I'm willing to contribute more to keep the software renderer alive and kicking. If people want more accellerated 2D functionality in the renderer, then please suggest it and implement it for Opengl and Direct3d, and I'll step up to the plate and contribute a software version too. In fact, for things like circle primitives, a well written, generic software renderer can be of assistance in calculating the points for the lines or triangle strips. I say, let's stop complaining, and start contributing. As for the versioning, definitely make it SDL 2.0. We should start to call it sdl 2.0 beta ASAP. And I'm all in favor of dropping the 1.2 compatibility API. If we increase the major version number, dropping backwards compatibility is absolutely acceptable, and may win us some time.

Wilbefast: that's exactly what I'm getting at. The strength of SDL is the wide array of backends it supports. If you want a game lib that only supports popular HW accelerated backends, then SFML (OpenGL only, IIRC) or Allegro 5 (OpenGL + DirectX, IIRC) will do just fine. No sense in occupying the same market space as those libraries. As for your reasons to like SFML better, 1) Is amply covered since there are at least 3 c++ free wrappers of SDL, not to mention wrappers in Python, Ruby, Haskell , Scheme, lisp, ... and whatever other language really. That's why it's nice SDL is written in plain c, it's easy to wrap for other languages. 2. Is being solved now, and 3 and 4 are some things we should work on.

Forest, sure, IF (big IF that) HW acelleration works well, it's faster, of course. As for software renderers being CPU hogs, that's true but not a problem, since games simply are CPU hogs, to be better of service to our customers. However it's not a matter of "misconfigured drivers" only. On linux there's the "not very good drivers" phenomenon. On windows there's the "users who don't know how to install drivers" phenomenon. And sometimes the hardware simply sucks. As I said before, I have a hardware accellerated card under linux (in a desktop box that cost me only 230 euro when I bough it) where the HW accel is slower than sw blitting, simply because the graphics card itself sucks that much (it's one for nettops, I think). Not to mention the Intel graphics chip on my nettop which has similar problems. (It seems Intels loves it that you use the CPU more than the gfx chip.) I think some people here just don't understand how underpowered some graphics hardware can be. It's not because your lastest high end gfx card is so fast, that all other people have a similar one. There are much more people with badly accelerated or unacellerated devices than you might imagine. Plenty of old and/or underpowered and/or tiny devices and computers out there. SDL is ideal for those to, since it's so widely portable.

Alberto, you seriously mention Mesa 3D? It's as slow as molasses, certainly for 2D rendering. The SDL software renderer beats the socks off it, often SDL is 50%-100% faster. So Mesa 3D is simply a non-option. In some cases it's so slow that it might even be faster to emulate software 3d with SDL's software renderer than to use Mesa. Just look at TinySDGL.