[SDL] SDL 1.3 status ?

Pallav Nawani pallavnawani at gmail.com
Wed Jul 27 22:55:41 PDT 2011

Congratulations on the success of your game.

But that success didn't have anything to do with using SDL 1.2.
You made a good game, and you could have made a better game in lesser 
time if you had used Popcap framework or the Playground SDK.

IMHO it is a common fallacy (amongst people with open source background) 
that the game/software you make should be as compatible as possible, 
while in fact it should be as *awesome* as possible, even if it means 
sacrificing some compatibility.  No point having a compatible game when 
no one wants to play it. Besides, as your experience with OpenGL shows, 
there is no such thing as 'fully compatibile' software, at least on the 
PC. Today when even a mobile phone has 3D acceleration, going after 
compatibility makes even less sense. Don't get me wrong, compatibility 
across *platforms* is a good thing. I am all for it. However, all the 
significant platforms today support 3D acceleration so no reason why SDL 

My first two games (Last Man Standing and Riotball) were made using SDL 
1.2. While SDL was immensely useful, it also held me back, a fact that 
immediately became apparent when I started using the PopCap Framework. 
With Popcap framework, the quality of game(s) I made rose dramatically, 
and time I needed to make them fell just as dramatically. Asa  game 
developer, improving the quality of the game you make, and reducing the 
time it takes to make it are far more important than compatibility.

I also don't understand why *everyone* has to roll it themselves, and 
Popcap framework is living proof that adding 'Big Stupid Thing to the 
API that pretends things aren't texture memory when they really are' 
works magnificently well. There is no reason for SDL to still stay in 
1998 when the whole world has moved to 2011.

So this is another vote for adding things like rotation to SDL 1.3 and 
dumping the compatibility layer.

On 28-07-2011 10:37, Nicholas Vining wrote:
> 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 wobbly.)
> 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.
> N.
> 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
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

*Pallav Nawani*
*Game Designer/Writer/CEO*
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

More information about the SDL mailing list