[SDL] SDL 1.3 status ?

Mason Wheeler masonwheeler at yahoo.com
Wed Jul 27 17:00:01 PDT 2011


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?

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 matteris, desktop Linux is
irrelevant because the actual users are simply not using it.  The seriousplatforms 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 (guaranteedGL 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 at pendleton.com>
Subject: Re: [SDL] SDL 1.3 status ?

On Sun, Jul 24, 2011 at 2:50 PM, Ryan C. Gordon <icculus at icculus.org> 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
>



-- 
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email: Bob at Pendleton.com
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110727/3ec962f1/attachment-0008.htm>


More information about the SDL mailing list