[SDL] SDL 1.3 status ?
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:
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
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. :)
> SDL mailing list
> SDL at lists.libsdl.org
More information about the SDL