[SDL] SDL 1.3 status ?

Nicholas Vining mordred at icculus.org
Wed Jul 27 22:07:08 PDT 2011

As the maker of Dungeons of Dredmor, I feel that we could use some 
facts. Accordingly - my facts, let me show you them. :)

I recently shipped Dungeons of Dredmor, a modestly successful indie 
title, on Steam. We're about two weeks in and have a good feel for what 
worked, and what didn't. We're not pushing Minecraft's numbers, but we 
were #1 on Steam for awhile, are still wandering on and off the Top 20, 
and we are now in the unenviable position where I (and, by extension, 
Ryan when I grump at him) have to do support for a large user base. This 
is also a pretty good set of instructions vis-a-vis shipping a 
commercial title with SDL, what works, and what doesn't.

First off, I would not ship with SDL 1.3. It is so not ready for prime 
time; not it's fault, it doesn't have eleven years of development on it. 
I have to make an architectural decision sometime soon about whether to 
keep using SDL 1.2 for the next game, which is no longer officially 
supported, or if I should move to SDL 1.3. I am really leaning towards 
1.2, but I may just be a pessimist.

Dungeons of Dredmor currently ships a modified version of SDL 1.2.13; 
SDL 1.2.14 has major bugs in the mouse code related to a Google Summer 
of Code project from previous years that were never addressed by the 
intern after his return to academic society. (GSoC interns: please don't 
do that.) By default, we run using software rendering, and the WinGDI 
driver. We don't use the DX5 driver because it also has major issues. 
(We added it in as a hidden, undocumented command line parameter that we 
passed to the people who wanted to run with FRAPS, and we get a good two 
or three complaints a day about it doing something it ought not to.) The 
GDI driver is very good, and runs pretty much everywhere. It is not 
perfect; for instance, see this: 
http://www.gaslampgames.com/forum/discussion/510/game-flickers-white - 
and you're invited to guess what the problem is because I have no clue. 
Nonetheless, the majority of users can run Dredmor because it doesn't 
require anything fancy.

We added an OpenGL "renderer" in patch 1.0.3 to support the Steam 
overlay, because Steam's overlay will only work with OpenGL or Direct3D 
code. Instead of creating an SDL surface for our screen, we run using 
SDL_OPENGL, create a texture, and then upload a software surface to it 
per frame using glTexSubImage2D(). We then draw a textured triangle and 
flip it. We get about five issues being reported, per day, from the 
userbase. This is the *simplest* possible OpenGL program you could make. 
It's basically the textured polygon example in the Red Book. And yet, we 
get support requests from people who use it and can't make it work, or 
whose machine it just doesn't work on.

So, no. It is incorrect to assume that "everybody has OpenGL" on 
Windows, or even "nearly anybody." I expect a major flare-up in issues 
*with GDI* once we hit the next few portals, which will be more casual 
in nature. Heck, not everybody has a version of DirectDraw that works! 
That's from... what, 1992? Based on what we want to do for the next 
game, I'm going to end up writing an actual OpenGL renderer, and that's 
going to be a support nightmare. Them's the breaks, I suppose.

As it stands, SDL works well. I don't have to spend five hours a day 
teaching people how to install Catalyst drivers, and I'm happy. For 
folks further down the food chain, and more embedded in the casual 
sphere than we are, I imagine that the difference between OpenGL and GDI 
based games is even more dramatic in terms of the support load. Very few 
grandmothers play Dredmor, although there are a few.

SDL_TTF worked well, too; I was very happy not having to touch Freetype 
directly. SDL_Image has one major bug with paletted images on 8-bit PNG 
files on OS X (!), which was enough for me to ditch it and use stb_image 
which does the right thing. (I would really like SDL_image to use 
libraries consistently across all platforms, just so I don't have to 
deal with stuff like this when Apple's PNG loader decides to throw a 

We also managed to trigger about three different race conditions in 
SDL_mixer. Go team. :-) I think next time I'll use OpenAL and write my 
own decoder.

If SDL did not support Linux, and did not support it robustly, there 
would be no versions of Dungeons of Dredmor for Linux. Period. Full 
stop. And this would make me sad. In terms of robust support, for 
Dredmor this means that I would want the game to run on a modern 
distribution out of the box. This means a software renderer; anything 
else runs afoul of both practicality *and* the free software purists.

Also, for the record: what is a "modern renderer"? Nobody complaining 
about what SDL 1.3 is missing out on by continuing to maintain some of 
the older, Actually Useful renderers, is willing to let themselves get 
pinned into a corner by admitting what a "modern renderer" is. It's a 
NONSENSE WORD. Simply talking about hardware acceleration via OpenGL, 
and calling that a modern renderer, doesn't solve anything. Everybody 
thinks they want that, but nobody actually does, because once you start 
doing that you can't expand on it without throwing the library out and 
writing it yourself. As soon as you want to do something that the 
"modern renderer" doesn't allow you to, it becomes useless.

I agree with Ryan; if we're just talking about hardware acceleration 
here, we could all waste everybody's time by adding a Big Stupid Thing 
to the API that pretends things aren't texture memory when they are, 
juggles it around and tries to pretend everything is cutesy and made of 
sprites and so forth... but if you want that? Roll it yourself, for 
crying out loud. Writing your own OpenGL based rasterizer for when you 
want this sort of thing has two major advantages: a) the memory usage 
better matches your game's memory usage and hardware usage patterns, and 
b) when something goes wrong, it is unquestionably your fault. :-) The 
only thing Dredmor might have wanted that it didn't get from SDL 1.2 and 
WinGDI is hardware-accelerated alpha blending, and this turned out not 
to be a major deal in the end. (And if the other thread is just going to 
turn into some sort of yelling match, or involves the words "rotated and 
scaled sprites", just shoot me now and be done with it. The honest 
truth? If you actually had an art director, and dared to rotate and 
scale his beautiful artwork, he would probably kill you with a rusty 
paring knife, and your death would be brutal and unpleasant.)

Go buy Dungeons of Dredmor! It's $5! And if anybody else has any 
questions about using SDL for a commercial title, don't hesitate to ask. 
I want it to be useful for commercial titles so I can do my next one 
with it, and some of this talk is very, very troubling.


On 7/27/2011 9:16 PM, Ryan C. Gordon wrote:
>> It makes no sense to let a tiny fraction of a percent hold SDL 1.3/2.0
>> back from implementing
>> modern rendering features.
> Not to be disagreeable, but my primary reason for working on SDL has 
> _always_ been the Linux compatibility. Because Linux games are how I 
> keep the electricity on at my house.
> I don't think the software rendering code is holding anyone back. 
> Also, the #1 game on Steam last week was Dungeons of Dredmor, which 
> not only uses software rendering, it uses SDL's GDI target on 
> Windows.  :)
> --ryan.
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

More information about the SDL mailing list