SDL 1.3 status?

Is there any ETA on when SDL 1.3 will supersede SDL 1.2 ?

Is it wise to use this for production level code yet ?
Also, does SDL 1.3 support hardware colored mouse cursor ? I know
this was on the TODO list for 1.2.

Thanks for the info.

On this topic, I’d like to note that replacing SDL 1.2 with SDL 1.3 system-wide is a nightmare on Linux distros, I think that SDL 1.3 either needs to be ABI-compatible (thus distros would consider it
a straightforward package upgrade) or have sdl12-config and sdl13-config scripts and so on, and of course differently named static and dynamic libraries by version.

I realize this might be taken out of context - I’m not saying that major changes should occur to SDL 1.3 or not, I’m saying that the packaging situation should be sorted out before SDL 1.3 gets out of
beta :slight_smile:

As it stands I’d like to use SDL 1.3 on all platforms but it’s a thorny problem on Linux with distros not packaging SDL 1.3, and static linking being something that is generally frowned upon on linux
(for security patch reasons).On 07/23/2011 11:53 PM, buginator wrote:

Is there any ETA on when SDL 1.3 will supersede SDL 1.2 ?

Is it wise to use this for production level code yet ?
Also, does SDL 1.3 support hardware colored mouse cursor ? I know
this was on the TODO list for 1.2.

Thanks for the info.


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

As it stands I’d like to use SDL 1.3 on all platforms but it’s a thorny problem on Linux with distros not packaging SDL 1.3, and static linking being something that is generally frowned upon on linux
(for security patch reasons).

(I agree we have some issues to sort out in this area, but…)

The 1.3 builds won’t be 100% ABI compatible; Even with the SDL_compat
layer, I’d expect that there will have to be a legacy sdl12 package on
distros that need it, since SDL_compat isn’t perfect and even if it was,
software-rendering games might suddenly work poorly when the screen
isn’t an X11 window so much as a glX context. This is why we bumped the
library version number, though: so it can coexist with SDL 1.2.

Open source things should, I hope, migrate to SDL 1.3’s API eventually.
When we get closer, I’ll be begging for volunteers to start submitting
patches for their favorite projects to do this.

My policy has always been to ship a copy of SDL with closed source
games. It isn’t installed by default on, say, Ubuntu, and if it is, I
can’t guarantee it’s built correctly (i.e. - Debian and/or Ubuntu has,
in recently times, improved the SDL package, but for a long time, it
wasn’t built with good options for audio targets).

–ryan.

Open source things should, I hope, migrate to SDL 1.3’s API eventually.
When we get closer, I’ll be begging for volunteers to start submitting
patches for their favorite projects to do this.

The main hold back for people to start porting games is that SDL 1.3 breaks
SDL 1.2 installs.

We’d get more developers, more testers, more patches, more ports, and
generally more of everything once SDL 1.3 installs into its own area.

There is a decade of SDL 1.2 software that is unlikely to be ported to SDL
1.3 any time soon. Installing SDL 1.3 into its own area will make it easier
for people to use old software, and use new software. For now, many will
not use SDL 1.3 because it will break older software.

cheers,On Sun, Jul 24, 2011 at 8:23 AM, Ryan C. Gordon wrote:

I agree that this is an urgent issue for getting more people working on and
with SDL 1.3. If it takes a bit more work to set up and seems like it is
going to change soon, many won’t even bother.

Jonny DOn Sun, Jul 24, 2011 at 5:21 AM, Ren? Dudfield wrote:

On Sun, Jul 24, 2011 at 8:23 AM, Ryan C. Gordon wrote:

Open source things should, I hope, migrate to SDL 1.3’s API eventually.
When we get closer, I’ll be begging for volunteers to start submitting
patches for their favorite projects to do this.

The main hold back for people to start porting games is that SDL 1.3 breaks
SDL 1.2 installs.

We’d get more developers, more testers, more patches, more ports, and
generally more of everything once SDL 1.3 installs into its own area.

There is a decade of SDL 1.2 software that is unlikely to be ported to SDL
1.3 any time soon. Installing SDL 1.3 into its own area will make it easier
for people to use old software, and use new software. For now, many will
not use SDL 1.3 because it will break older software.

cheers,


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

2011/7/24 Ren? Dudfield > On Sun, Jul 24, 2011 at 8:23 AM, Ryan C. Gordon wrote:

Open source things should, I hope, migrate to SDL 1.3’s API eventually.
When we get closer, I’ll be begging for volunteers to start submitting
patches for their favorite projects to do this.

The main hold back for people to start porting games is that SDL 1.3 breaks
SDL 1.2 installs.

We’d get more developers, more testers, more patches, more ports, and
generally more of everything once SDL 1.3 installs into its own area.

There is a decade of SDL 1.2 software that is unlikely to be ported to SDL
1.3 any time soon. Installing SDL 1.3 into its own area will make it easier
for people to use old software, and use new software. For now, many will
not use SDL 1.3 because it will break older software.

cheers,

I dont see why those libaries can’t cohexist. I remember having two versions
of libpng a while ago. sdl-config12 and sdl-config13 may be the way to make
this come true. And as other said, a multitude of software wont be ported to
SDL 1.3, so SDL 1.2 need to be installed along with 1.3;

Hello !

On this topic, I’d like to note that replacing SDL 1.2 with SDL 1.3 system-wide is a nightmare on Linux distros, I think that SDL 1.3 either needs to be ABI-compatible (thus distros would consider it a straightforward package upgrade) or have sdl12-config and sdl13-config scripts and so on, and of course differently named static and dynamic libraries by version.

I realize this might be taken out of context - I’m not saying that major changes should occur to SDL 1.3 or not, I’m saying that the packaging situation should be sorted out before SDL 1.3 gets out of beta :slight_smile:

As it stands I’d like to use SDL 1.3 on all platforms but it’s a thorny problem on Linux with distros not packaging SDL 1.3, and static linking being something that is generally frowned upon on linux (for security patch reasons).

I agree the user should be able to install SDL 1.3 in friendly coexistence to SDL 1.2.
The same is needed for the SDL Helper libs like SDL_image, SDL_mixer …

I would like to see that in the future a system has a sdl-config for old SDL 1.2 sdl13-config for SDL 1.3.
Two versions SDL_mixer with different names on the same system, one for SDL 1.2 and one for SDL 1.3.

CU

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

Jonny DOn Sun, Jul 24, 2011 at 1:18 PM, Torsten Giebl wrote:

Hello !

On this topic, I’d like to note that replacing SDL 1.2 with SDL 1.3

system-wide is a nightmare on Linux distros, I think that SDL 1.3 either
needs to be ABI-compatible (thus distros would consider it a straightforward
package upgrade) or have sdl12-config and sdl13-config scripts and so on,
and of course differently named static and dynamic libraries by version.

I realize this might be taken out of context - I’m not saying that major
changes should occur to SDL 1.3 or not, I’m saying that the packaging
situation should be sorted out before SDL 1.3 gets out of beta :slight_smile:

As it stands I’d like to use SDL 1.3 on all platforms but it’s a thorny
problem on Linux with distros not packaging SDL 1.3, and static linking
being something that is generally frowned upon on linux (for security patch
reasons).

I agree the user should be able to install SDL 1.3 in friendly coexistence
to SDL 1.2.
The same is needed for the SDL Helper libs like SDL_image, SDL_mixer …

I would like to see that in the future a system has a sdl-config for old
SDL 1.2 sdl13-config for SDL 1.3.
Two versions SDL_mixer with different names on the same system, one for SDL
1.2 and one for SDL 1.3.

CU

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

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

–ryan.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.

So we can continue using version 1.3 and once it gets stable enough
for a final release we can bump the version up to 2.0.On Sun, Jul 24, 2011 at 10: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.


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

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

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


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


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

Hello !

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.

Bob i agree 100% The biggest problem with the compat. layer
is that it is not 100% compat. with SDL 1.2. It misses some
functions. I tried to compile my own game with it and it fails
because of missing functions. Better than a compat. is having
good tutorials to advice the programmer how he/she can update his
code.

In the end people will have to install SDL 1.2 and SDL 1.3/2.0 in
parallel to be happy.

CU

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.com (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

'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

I support getting rid of the compatibility layer because there’s no need
to have something that is “like SDL 1.2, but not quite” specially
because there’s the real SDL 1.2 which can be used instead. I’d also say
removing non-accelerated rendering back ends would be good, but I would
keep at least some support for compositing / slicing surfaces.

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.

-GatoOn 07/27/2011 07:00 PM, Mason Wheeler wrote:

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
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

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%.

JeffOn 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.

Totally agree: the 1.2/1.3 confusion was a serious stumbling block for me
during Android development. I think the two need to be more clearly defined:
I had no idea there even was a compatibility mode at first. I just kept
using the library as I always had, and wondered why it wasn’t working. Even
some sort of little warning that compatibility mode is being used would be
very helpful.

As for Linux: as I recall SDL was originally developed by Loki for gaming on
Linux. Dropping Linux support would be… odd. I for one use Ubuntu on my
little laptop… but I do have working OpenGL drivers so generally use
hard-acceleration.

WilliamOn 28 July 2011 13:06, Jeff Post <j_post at pacbell.net> wrote:

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%.

Jeff


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

'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.

I don’t think Mason was suggesting that Linux support is dropped; just that
the non-accelerated (software) rendering backends are removed. Linux would
still work just fine as long as there is OpenGL - just as on the other
platforms.

My first reaction is to agree, but…

The software 2D backends are handy for higly portable GUI code and stuff like
that, and off-line rendering, preparation of textures for OpenGL etc. GUIs and
the like would be where hardware acceleration comes in; when available, it
speeds things up nicely, while saving CPU cycles and power.

Either way, as long as SDL doesn’t wrap OpenGL and Direct3D in a proper,
unified 3D API, I don’t see it having much use as the main rendering API in
games in the near or distant future.

Personally, I’ve switched to OpenGL (still doing “2D”), and there’s no going
back to a 2D API without arbitrary transforms, proper blending and all that.
Everything is just so incredibly awkward without OpenGL, and despite the extra
work, results will never be what one expects from a game less than ten years
old. Why put up with that when even cellphones have hardware accelerated
OpenGL…?

Maybe there are still a few Direct3D-only boxen out there, but so be it. What
kind of sales figures would you need for the potential increase to cover the
cost of adding Direct3D support?

So, basically, I’m suggesting that one uses the SDL 2D API for anything that
needs to be extremely portable (GUI toolkits, for example), and/or only needs
the basic “retro style” 2D stuff. OpenGL for everything else.

From that perspective, it makes perfect sense to have a “retro” 2D API with
both software rendering and hardware acceleration, while not trying to make it
a viable alternative to OpenGL or Direct3D for “modern” 2D games.On Thursday 28 July 2011, at 03.38.20, Jeaye wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

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.

Amen to that :POn 28 July 2011 14:16, 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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org