[SDL] SDL 1.3 status ?
masonwheeler at yahoo.com
Thu Jul 28 06:54:43 PDT 2011
From: Tim Angus <tim at ngus.net>
Subject: Re: [SDL] SDL 1.3 status ?
>You're about 5 years out of date. If you install e.g. Ubuntu today it
>/requires/ hardware acceleration to work as intended and certainly
>doesn't need any manual configuration. If you're going to try and
>support your argument with information, at least make sure said
>information is correct in the first place ;). It's fallacious to say that
>desktop Linux is any more or less of a factor in guiding SDL's
>direction than any other platform, in my opinion.
It's not my argument; it's the one that the people arguing *against*
my argument used last time this came up.
>> It makes no sense to let a tiny fraction of a percent hold SDL
>> 1.3/2.0 back from implementing modern rendering features.
>I think the problem is that SDL serves two relatively distinct purposes:
>1. A platform abstration layer.
>2. An API for 2D rendering.
You don't see rendering backends as sufficiently complex to warrant the
"platform" designation? I do, which makes your distinction a case of
>Hopefully we can agree that everyone cares about 1; it is the reason SDL
>exists in the first place. Now, the people that primarily use SDL for this
>purpose basically don't care about the rendering API. I count myself in
>The other use case for SDL is as a means to write simple games, with
>simple being the operative word. It is after all what the S in SDL stands for.
Argh! Not this again. There are two possible meanings for "simple" in this
context. One is "simplify"--taking something complicated and making the
complexity more manageable--and the other is "simplistic"--having a very
limited feature set. "Simplify" is good. "Simplistic" is bad. People use SDL
because it simplifies complex tasks. It is afterall what the S in SDL stands
for. But when they run up against limitations in an overly simplistic API,
people get frustrated with SDL and turn to other libraries. (See this very
thread for examples.)
>The people that have invested time in using SDL for this purpose may
>have outgrown the limitations of this API and, rightly or wrongly, feel
>that it is now holding them back. They may now be getting to the stage
>where their games aren't so simple any more. I think this is where you are.
>For what it's worth, I reckon the question is not one of what is stopping
>the SDL rendering API being extended, it is whether or not it's appropriate
>to do so in the first place. OpenGL is already there as a portable and vastly
>more capable API than anything SDL is or can aspire to be, so what is the
>point in trying to make SDL encroach on its capabilities?
I've been over this before. For 90% of what I'm trying to do, the existing
functionality is just fine. But there are some very important cases where I
need to be able to flip, rotate, and even apply effects that require shaders
to certain individual sprites. I think it's silly to go and throw out the
simplifying abstractions that serve me so well in the 90% case (which would
basically require me to reimplement all of SDL, most likely with plenty of
new bugs) just to get the 10% case working. That's crazy talk.
>I acknowledge (and have sympathy with) the argument that OpenGL is
>harder to learn than the SDL rendering API, but it's not that bad really.
>For the purposes of doing simple 2D games, the required OpenGL is pretty
>minimal, to be honest.
Just out of curiosity, have you ever looked at the implementation of
GL_CreateTexture in sdl_render_gl.c?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SDL