SDL 1.3 status?

I never said “ditch Linux development”, I said “don’t let people use the (perceived)
problemsthatdesktop Linuxhas with a lack of good OpenGL driver support as an
excuse tohold backthenecessaryremoval of support for non-accelerated backends
which areblockingimplementation ofimportant modern rendering features.”

Please don’t oversimplify what I say into strawman versions.? That’s a serious pet
peeve ofmine.

Mason________________________________

From: jeaye@arrownext.com (Jeaye)
Subject: Re: [SDL] SDL 1.3 status ?

'ello,

I wholeheartedly disagree with Mason. Ditching Linux development is a
naive approach to SDL 1.3 advancement. SDL 1.3 is Linux’s hope for better
OpenGL support with SDL, and potentially its hope for more desktop gamers.

Cheers,
Jeaye

Sorry Mason, I’ll admit that I jumped the gun a bit on that one. How many
Linux applications don’t use HW acceleration these days? I wouldn’t think a
huge amount… still, it’s a useful option to have up your sleeve. Surprised
it isn’t supported for other platforms actually…On 28 July 2011 14:15, Mason Wheeler wrote:

I never said “ditch Linux development”, I said “don’t let people use the
(perceived)
problems that desktop Linux has with a lack of good OpenGL driver support
as an
excuse to hold back the necessary removal of support for non-accelerated
backends
which are blocking implementation of important modern rendering features.”

Please don’t oversimplify what I say into strawman versions. That’s a
serious pet
peeve of mine.

Mason


From: "jeaye@arrownext.com" (Jeaye)
**Subject: Re: [SDL] SDL 1.3 status ?

'ello,

I wholeheartedly disagree with Mason. Ditching Linux development is a
naive approach to SDL 1.3 advancement. SDL 1.3 is Linux’s hope for better
OpenGL support with SDL, and potentially its hope for more desktop gamers.

Cheers,
Jeaye


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think the software backends actually serve a slightly different use: a
reference to compare HW accelerated output to when porting the backend to
other systems that are hardware accelerated. Just my 2c. As far as I can
tell, the only feature excluded in the name of software rendering is the
lack of affine transformations of 2D stuff.On Wed, Jul 27, 2011 at 11:15 PM, Mason Wheeler wrote:

I never said “ditch Linux development”, I said “don’t let people use the
(perceived)
problems that desktop Linux has with a lack of good OpenGL driver support
as an
excuse to hold back the necessary removal of support for non-accelerated
backends
which are blocking implementation of important modern rendering features.”

Please don’t oversimplify what I say into strawman versions. That’s a
serious pet
peeve of mine.

Mason


From: "jeaye@arrownext.com" (Jeaye)
**Subject: Re: [SDL] SDL 1.3 status ?

'ello,

I wholeheartedly disagree with Mason. Ditching Linux development is a
naive approach to SDL 1.3 advancement. SDL 1.3 is Linux’s hope for better
OpenGL support with SDL, and potentially its hope for more desktop gamers.

Cheers,
Jeaye


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Argh! Where are you people getting this from?? Why is it that, out of everyone who has commented on
this thread so far, the only person who understood what I wrote was David Olofson?!?? I never said
anything about discontinuing Linux development!________________________________
From: icculus@icculus.org (icculus)
Subject: Re: [SDL] SDL 1.3 status ?

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.? :slight_smile:

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You used the word “Linux” and “market share” in the same sentence! :XOn Wed, Jul 27, 2011 at 11:25 PM, Mason Wheeler wrote:

Argh! Where are you people getting this from? Why is it that, out of
everyone who has commented on
this thread so far, the only person who understood what I wrote was David
Olofson?!? I never said
anything about discontinuing Linux development!


From: Ryan C. Gordon

**Subject: Re: [SDL] SDL 1.3 status ?

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. :slight_smile:

–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

I think that pulling the compat layer would speed development by
freeing use from any need to stay compatible with 1.2.

I don’t think a lot of thought is going into 1.2 compatibility. I’m not
sure what the current state of the compat layer is, but I think the
bigger problem is that mixing compat calls with 1.3 APIs is likely to
blow up in ways we haven’t even thought about, and it’s not clear where
the line is drawn between the two APIs.

I think people are asking me to make a decision about this, and I don’t
have one yet. Also: I’m not actually sure I’m the guy that gets to make
that sort of decision.

Also: holy crap, am I the guy that gets to make that sort of decision?!

–ryan.

Please don’t oversimplify what I say into strawman versions. That’s a
serious pet peeve ofmine.

Sorry, I misread what you said.

The software renderer isn’t just there for Linux people without good GL
drivers (these people are, generally, beyond our help anyhow for most
modern games), but it’s good to not be locked out of the strange
platforms that pop up. I would argue that this was part of SDL 1.2’s
success.

As far as I can tell, that code is done at this point anyhow.

–ryan.

Argh! Where are you people getting this from?

To be fair, you wrote a whole bunch about how the Linux desktop is
irrelevant, with one sentence about software renderers tucked in before
it. Smarter people than myself misread it, too.

More to the point: the software renderer isn’t being held back. Sam and
I spent a long time debating how much the renderer APIs should do…it
wasn’t really a question of how much does it make sense to implement in
software, but how much of API should we be creating when people should
really be using OpenGL or Direct3D. My argument was anything more than a
simple blit is wasted effort, and once you add rotation, people will ask
for every other piece of the fixed function pipeline.

So while the software renderer was probably a pain to build, it’s built
now, and it’s not holding back further development, because adding more
functionality to that API is a fool’s errand.

We feel it’s at the point where you can throw together a simple game
with some basic effects quickly, and if you need more, you should use
OpenGL.

–ryan.

I think the bigger problem is that mixing compat calls with 1.3 APIs is
likely to blow up in ways we haven’t even thought about, and it’s not
clear where the line is drawn between the two APIs.

Agreed.

Also: holy crap, am I the guy that gets to make that sort of decision?!

Depends if you want the responsibility I guess. Dunno, I know nothing about
how SDL is organised: always figured you guys were a short of
anarcho-syndicalist commune :stuck_out_tongue:

My argument was anything more than a simple blit is wasted effort, and once
you add rotation, people will ask for every other piece of the fixed
function pipeline
(…)
We feel it’s at the point where you can throw together a simple game with
some basic effects quickly, and if you need more, you should use OpenGL.

Guess that answers my rotations question :-SOn 28 July 2011 14:55, Ryan C. Gordon wrote:

Please don’t conflate “Linux”, which is in use in a whole lot of places, with “desktop
Linux,” (Linux on home PCs and laptops, in direct competition to home versions of
Windows and OSX,) which is specifically what I was talking about, and has
unfortunately but quiteverifiably alwaysbeena dismal failure when it comes to
capturing market share.? Again, I mean what I say, and not some other similar-sounding
thing that I did not say, and it drives me up the wall when people turn what I say into
strawman versions.? Especially when it’s other programmers.? If anyone in the world
has no excuse for screwing up the interpretation of precise language, it’s us!

I’m not saying that desktop Linux’s low market share is good or that it’s bad, only that
that is, and that it’s a verybad idea to let ideology and personal preference trump
facts when it comes tomaking important decisions about the future.? And deciding
whether or not SDL will support modern rendering techniques is very important to
its future.? It will decide, more than anything else, whether SDL remains relevant
or fades into obscurity.? And SDL is right now caught at a classic “engineering
trinity” decision: “useful modern features, non-accelerated backends, all backends
supportingall rendering options. Pick two.”? And it’s been made quite clear that the
third pointis non-negotiable.________________________________
From: j_post@pacbell.net (Jeff Post)
Subject: Re: [SDL] SDL 1.3 status ?

On Wednesday 27 July 2011 19:29, Gato wrote:

Now, about desktop Linux. Probably you don’t use it, but that doesn’t
make it irrelevant. The support for OpenGL on Linux is much better than
it was a few years ago, and will very likely only improve in the future,
so I see no point in crippling SDL by not supporting Linux.

Please remember SDL isn’t only for the hardcore gamer. Many applications
have been written using SDL, and I’m sure many more would benefit from
features in SDL 1.3, like multiple windows, even if the OpenGL they’re
running on isn’t blazing fast.

Well said, Gato. Far too many people seem to have the attitude that “since I
have no need of X, X is irrelevant for anyone”. I could expound on why people
make such blatantly silly statements, but suffice it to say that they’re
wrong.

And I second the opinions expressed by Bob Pendleton earlier; I think that’s
the way to go. Currently I have no need of SDL 1.3 as 1.2 suits my needs, but
I like the direction 1.3 is going. When it’s mature enough I’ll make the
switch.

To Mason: the statement that Linux is less than 1% of market share is a myth
pushed on the public by Microsoft. It’s not true. What the actual market
share is is unknown for various reasons that you can find out via Google (if
you care enough to find out),? but it is certainly considerably higher than
1%.

Fair enough.? And, as I said the last time we all had this discussion, I’ve got nothing wrong with keeping a software renderer around as a reference implementation.? I think that’s a good idea, in fact.? What I want to throw out is “all backends must support the entire rendering API, and you can’t do XYZ in GDI/X11/whatever else, so we can’t implement that.”? Sacrifices must be made.? Toss GDI and X11 so we can build a rendering system that will stay relevant.________________________________
From: icculus@icculus.org (icculus)
Subject: Re: [SDL] SDL 1.3 status ?

Please don’t oversimplify what I say into strawman versions. That’s a
serious pet peeve ofmine.

Sorry, I misread what you said.

The software renderer isn’t just there for Linux people without good GL drivers (these people are, generally, beyond our help anyhow for most modern games), but it’s good to not be locked out of the strange platforms that pop up. I would argue that this was part of SDL 1.2’s success.

As far as I can tell, that code is done at this point anyhow.

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

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. :slight_smile: 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. :slight_smile: 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. :slight_smile:

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

?See, I don’t get that.? It just feels like it hasn’t been thought through very far.? You make it sound like using OpenGL or Direct3D is something simple to transition to.? If anyone really thinks that, I invite them to take a look through SDL_render_gl.c sometime.? Look at how big some of the functions are, how much functionality is being wrapped in these simple SDL calls.? Most of them include at least 4 OpenGL calls; some have a lot more than that.? SDL takes a low-level API and builds powerful high-level abstractions out of it, and it does a good job of that.? Saying “but we’ll only go this far, no further, and if you want advanced effects you need to master a completely new API and learn all about matrices and transformations and projections” is a bit off-putting.

If SDL doesn’t provide rotation, to give just one example, then everyone is going to end up having to roll their own rotation abstractions.? And a bunch of them will be wrong, because that’s what happens when people reinvent wheels.? And they’re going to end up in games that say “made with SDL” on them, and people are going to look at the games and say “wow, SDL games suck! They’ve got graphical errors all over the place!”? When in fact, the problem isn’t in the SDL part of the game at all; it’s in the stuff that was left out of SDL.? But that won’t matter; the perception will be there, and SDL will get a bad reputation for low quality.? Does anyone really want that?________________________________
From: icculus@icculus.org (icculus)
To: SDL Development List
Sent: Wednesday, July 27, 2011 9:55 PM
Subject: Re: [SDL] SDL 1.3 status ?

Argh! Where are you people getting this from?

To be fair, you wrote a whole bunch about how the Linux desktop is irrelevant, with one sentence about software renderers tucked in before it. Smarter people than myself misread it, too.

More to the point: the software renderer isn’t being held back. Sam and I spent a long time debating how much the renderer APIs should do…it wasn’t really a question of how much does it make sense to implement in software, but how much of API should we be creating when people should really be using OpenGL or Direct3D. My argument was anything more than a simple blit is wasted effort, and once you add rotation, people will ask for every other piece of the fixed function pipeline.

So while the software renderer was probably a pain to build, it’s built now, and it’s not holding back further development, because adding more functionality to that API is a fool’s errand.

We feel it’s at the point where you can throw together a simple game with some basic effects quickly, and if you need more, you should use OpenGL.

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

Are you familiar with the concept in legal documents known as
"incorporates by reference"?? Something like that is in play here.
I’m not sure how
long you’ve been following the SDL list, but this
discussion is not
something new.? It’s been around for a couple years
now, and your
"NONSENSE WORD" is anything but.? But for the
benefit of those who are
new to the discussion, allow me to provide
an informal working
definition:

A modern renderer understands that sprites are not, and do not have
tobe, immutable rectangles.? It is capable of scaling, rotating, flipping,
and arbitrarily distortingthem.? It can also play around with their colors
in interesting ways, some of which may require shaders.

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.

Sorry, not buying it.? Any sealed abstraction that you cannot get beneath
when necessary is evil, and anyone who builds a library (of any kind) that
way has no business building libraries.? You want to see it done right, take
a look at the gold standard of widget libraries, the Delphi VCL.? It does
for the windows API what SDL does for low-level rendering systems: it
wraps them in simple, high-level, easy-to-understand abstractions that
makes it possible for people to quickly and easily build stuff out of
them.? But the interesting thing is, all the winapi stuff is still there, and
it’s still accessible if necessary.? In fact, if it’s needed, every VCL control
has a Handle property that returns the control’s HWND, allowing direct
access to the low-level winapi commands.

A well-designed renderer would do the same thing: wrap the complicated,
low-level GL/D3D/GLES functionality and keep it out of the coder’s face
so he can concentrate on building a working system, but still provide a
Handle that would give access to each object’s underlying GLUint or other
renderer-specific handle, to make it possible to do things that the “modern
renderer” didn’t account for.

Mason>From: Nicholas Vining

Subject: Re: [SDL] SDL 1.3 status ?

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
shouldn’t.

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. :slight_smile:

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. :slight_smile: 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. :slight_smile:
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. :slight_smile:

–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
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768

On the topic of Dungeons of Dredmor, I should mention that the Steam Community Overlay does not work with it, because it uses GDI :slight_smile:

For my own bit in this debate, I strongly advocate the following feature configurations as critical:

  1. accelerated 2D and 3D using OpenGL/OpenGL ES (Windows, Linux, OSX, Android, iphoneos, MeeGo-based devices, OpenPandora, etc)
  2. accelerated 2D and 3D using Direct3D9/10/11 (Windows - yes it’s windows specific, but in many cases the drivers are better, and an easy way to initialize a D3D context is still welcome)
  3. unaccelerated 2D (all)

If one is writing a 2D game, one expects it to run everywhere, even if poorly, but preferably fast.

If one is writing a 3D game, one knows it won’t run everywhere, but if it does run it should run well.On 07/27/2011 09:14 PM, William Dyce wrote:

Amen to that :stuck_out_tongue:

On 28 July 2011 14:16, Ryan C. Gordon <icculus at icculus.org <mailto:icculus at icculus.org>> 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 <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/__listinfo.cgi/sdl-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


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

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.

This conversation is about to veer off the rails (and I blame myself,
for misreading Mason’s email and thus throwing gasoline on the
campfire)…so I’m just going to point out that there isn’t anything
inherently wrong with building what you’re describing…it’s a game
engine.

Different developers like different things. There’s nothing wrong with
PopCap Framework (or HGE, or Unity, or UDK, etc), but they serve
different purposes than SDL. I don’t think it’s SDL’s place to compete
with them on feature set. In fact, I think a great use for SDL is to sit
under those frameworks, so they can pile on features and know that
they’ll be reasonably portable out of the box.

–ryan.

Yes, please.? And while we’re at it, can we please finally remove support
for the non-accelerated
rendering backends that are holding SDL back?

Oh YES! Pretty please? I’ve been asking for that for t many years.
And, as for the Linux problem… it doesn’t exist. Really, it
doesn’t. I have lost count of how many years it has been since I have
had any problem getting accelerated OpenGL running on a LInux box.
I’ve been doing it since at least 2000. And, it became trivial in the
early days of Ubuntu and Fedora. It just isn’t a problem anymore.

So, speaking as someone who uses Linux for almost everything… (I
find that I am ethically bound to use MS Office running on WIndows to
grade work done in Office on Windows because of them minuscule chance
that Office running on wine or crossover might give a result that
would affect a students grade.) I feel perfectly fine dropping support
for non-accelerated platforms.

Bob PendletonOn Wed, Jul 27, 2011 at 7:00 PM, Mason Wheeler wrote:

I’m sure the desktop Linux folks will raise a big hue and cry about it again
because they can’t seem
to get working OpenGL drivers in a lot of cases, but the fact of the matter
is, desktop Linux is
irrelevant because the actual users are simply not using it.? The serious
platforms today are
Windows (guaranteed D3D and GL in 99%+ of all cases), mobile *nix
(guaranteed GLES on all
platforms I’m aware of) and, to a much lesser extent, OSX (guaranteed GL in
all cases).? Desktop
Linux still has less than 1% market share, and only a fraction of that
tiny fraction actually cares
about gaming.? And for them, there’s still SDL 1.2.
It makes no sense to let a tiny fraction of a percent hold SDL 1.3/2.0 back
from implementing
modern rendering features.
Mason


From: Bob Pendleton <@Bob_Pendleton>
Subject: Re: [SDL] SDL 1.3 status ?

On Sun, Jul 24, 2011 at 2:50 PM, Ryan C. Gordon wrote:

On 7/24/11 12:15 PM, Jonathan Dearborn wrote:

I still favor bumping it up to SDL 2 before making the naming decisions,
since it is such a big, purposefully incompatible upgrade.

To be fair, 1.3 was meant to be the unstable development version that
becomes a stable 2.0.

–ryan.

Hey Ryan,

The last time I tried to anything serious with 1.3 (a while back I
admit) I wound up adding the compile flag that disables/removes the
compatibility layer. I did that because the compatibility layer kept
messing me up. I would accidentally use something from the
compatibility layer and it would cause something to run really slow or
mess up in some other way and then I would spend time figuring out
what I was doing wrong. OK, so what I am trying to say is that we
should just dump the compatibility layer because it complicates the
code and confuses programmers and we should bump the version to 2.0 at
the same time all the compatibility code is pulled.

I think that pulling the compat layer would speed development by
freeing use from any need to stay compatible with 1.2. Right now every
time anyone thinks of a change or addition you have to think “How will
this effect compatibility?” Also, there is a bunch of code that is
only there in 1.3 to retain compatibility. And, IIRC, some of it is
wedged in to some really odd places.

Moving to version 2.0 will confuse a lot of people… But, a lot of
people are waiting for it to happen too so it will generate a lot if
interest. Maybe get a bunch of people working on it again? So… Drop
compat, move to version 2.0 add an extra . to the end of the version
and make it something like version 2.0.00000 and update the last part
of the version number for each patch so people can easily see how much
progress is being made. (Ok, you can ignore the last part, but please,
at least think about the rest of what I said.)

Bob Pendleton


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


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

Everyone, I know think you know what Mason said, but it is not what he
actually said…

Mason said, drop support for platforms that do not have hardware
graphics acceleration.

He did not say “Drop support for Linux”.

Mason did say that he expected a lot of blow back from Linux users
because he beleived that Linux has poor support for hardware
accelerated graphics. That does not imply dropping support for Linux!
Any he was right that he will get a lot of blow back from some Linux
users. But, Linux has great 3D graphics accelerations and has had for
many years.

Perhaps Mason could have said what he meant in a way that is less
likely to cause a fire storm. But, please, read what he actually said,
not what you think he said.

How about we change it to something like:

Only support platforms that support widely used graphical APIs such as
OpenGL and DirectX?

Lighten up folks!

Bob Pendleton