SDL 1.3 status?

[William_Dyce]

I won’t lie, I actually switched from SDL to SFML some time ago because:

1. the API is object-oriented, I find it more intuitive
2. I didn’t know that SDL supported HW acceleration at the time
3. you can rotate, fade and stretch sprites easily
4. it has shinier, friendly, simpler tutorials and documentation

Now I’m back to SDL again because it supports Android and iOS and I have a
job to do. It helps too that it’s older, with a larger community and
more resources: SFML is very young and hasn’t been used in
many successful projects. It’s also made by French people, and Americans
don’t like the French because the two countries are no longer united in
their hatred of the English (they both still hate the English, but they do
so independently). As a result not so many people use SFML.

Now: If Google is anything to go by a lot of people are asking questions
about which of these two libraries they should choose. I think it’s
important for each to specialise in some specific kind of application rather
than competing against one another. We should all be on the same side I
think.

WilliamOn 28 July 2011 16:44, Bob Pendleton wrote:

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

---

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

[Alberto_Luaces_Ferna]

Nicholas Vining writes:

We also managed to trigger about three different race conditions in
SDL_mixer.

Do you know if those races are corrected in the current version of
SDL_mixer? If not, are them at least registered in the bugtracker?–
Alberto

[Alberto_Luaces_Ferna]

Nicholas Vining writes:

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.

The use of Mesa 3D graphics library could help for those `GL challenged
environments’. Mesa 3D can implement OpenGL calls in software ? on
windows, there is a GDI backend.–
Alberto

[icculus]

Do you know if those races are corrected in the current version of
SDL_mixer? If not, are them at least registered in the bugtracker?

He’s talking about these two fixes:

 http://hg.libsdl.org/SDL_mixer/rev/777497efacaa
 http://hg.libsdl.org/SDL_mixer/rev/3a4c352a9a00

–ryan.

[Forest_Hale]

I think that discussion of software OpenGL is off-topic to this discussion as this discussion centers mostly on the reality that FEW people lack hardware acceleration, and those that do, are often a
matter of misconfigured drivers.

I will remark however on the performance of software rasterizers in general.

Anyone not interested in software rasterizer performance on x86 + SSE2 need read no further, but there are some interesting hardware anecdotes here:

Software rasterizers are CPU hogs like nothing else, in my darkplaces engine the DPSOFTRAST code (written as a collaboration between me and Lee Salzman of sauerbraten fame) can max out 6 threads and
find itself severely memory bound, and still only struggle to reach 30fps at 1080P with modest geometry and shaders for optimal fillrate, and Mesa (with the softrast implementation or with llvmpipe)
is sometimes “playable” performance but worse than the custom code in DPSOFTRAST, and far from adequate.

An even worse problem arose however - there is no GOOD way to get system memory pixels to the video card framebuffer, even if you can fill them fast enough.

On X11 there’s a way with asynchronous DMA transfers using the XShm shared memory extensions to get the highest performance observed so far, but still not what I would call good.

Other platforms tend to be a bit more mediocre at this, limiting framerate further (to be clear, Windows GDI does not suck at this task, but isn’t quite as good as XShm DMA transfers), usually with
unnecessary synchronization.

So basically… filling pixels on the CPU sucks, blitting them to video memory sucks even more.

Rendering entirely in video memory (D3D/GL/GLES/etc) is win for this reason alone.On 07/28/2011 12:42 AM, Alberto Luaces wrote:

Nicholas Vining writes:

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.

The use of Mesa 3D graphics library could help for those `GL challenged
environments’. Mesa 3D can implement OpenGL calls in software ? on
windows, there is a GDI backend.

–
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

[Karl_Glatzer]

I guess i’m a little late for the discussion but here is what i think:

Yes please drop SDL_Compat it’s really useless. It can’t even compile
the simple SDL_Gears demo. I tried to extend it so it could (even wrote
a stupid email to the mailing list about my ideas for extending it) but
it actually is impossible since the SDL 1.2 API often collides with the
SDL 1.3 API.

I think we should keep updating SDL 1.2 atleast till SDL 1.3 has become
SDL 2.0.

On the SW renderer vs HW renderer/accelaration part:

I don’t know much about these things but i see no reason for dropping
the SW renderer. If you don’t like it just don’t use it!

And if you want to use D3D/OPENGL(ES) then learn it. In my opinion SDL
isn’t made to simplify this and thus you have the freedom to use it how
you want.

[Jon_Dowland]

I agree in principle, but why not move away from sdl-config altogether and just
use pkg-config exclusively for 1.3 and beyond?

http://www.freedesktop.org/wiki/Software/pkg-configOn Sun, Jul 24, 2011 at 07:18:10PM +0200, Torsten Giebl wrote:

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.

–
Jon Dowland

[Torsten_Giebl]

Hello !

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.

Not long ago, we had the exact same discussion. The result of it was, the majority voted against
dropping X11, GDI and Co., but if simple functions like rotating and zooming would be added to the SDL
API would be perfectly happy, if only generic functions would be added to the software blitter,
instead of having optimized ones for every corner case.

What a coder of classic 2d games would like to have in SDL 1.3/2.0 :

Multiple window support, for games like SimCity, Railroad Tycoon and
in general games, that use more than one window: CHECK

Hardware Accelerated Alpha Blending on systems that support it: CHECK

Hardware Accelerated Functions for SNES Mode 7 like Efffects Rotating and Zooming: HOPEFULLY SOON

CU

[Alberto_Luaces_Ferna]

Forest Hale writes:

I think that discussion of software OpenGL is off-topic to this
discussion as this discussion centers mostly on the reality that FEW
people lack hardware acceleration, and those that do, are often a
matter of misconfigured drivers.

Yes ? my point was to keep a GL 2D title working without touching a
single line of code in environments were the user is not even able to
correctly configure the drivers.

Nevertheless, thanks for the insight.–
Alberto

[Beoran]

I fully agree with Thorsten. Now that’s said, what API’s should be added? How about SDL_RenderRotate(renderer, texture, srcrect, dstrect, angle)? // rotozoom as SDL_RenderCopy already can do scaling. What else? SDL_RenderTint(renderer, texture, srcrect, dstrect, color) perhaps ? If people can agree on what to add, I’ll help out with it.

[Torsten_Giebl]

Hello !

I fully agree with Thorsten. Now that’s said, what API’s should be added?
How about SDL_RenderRotate(renderer, texture, srcrect, dstrect, angle)? // rotozoom as SDL_RenderCopy already can do scaling. What else?
SDL_RenderTint(renderer, texture, srcrect, dstrect, color) perhaps ? If people can agree on what to add, I’ll help out with it.

I like that rotozoom combines everything into one call.
Does it also allow to flip x/y ? Another important feature for every
2D game.

CU

[Tim_Angus]

tl;dr version:

• Don’t be silly, HW acceleration on Linux is ubiquitous now and has
  been for some time.
• It doesn’t make sense to extend the SDL rendering API now when OpenGL
  is available everywhere that matters and SDL is never going to be able
  to compete with it on a functionality basis anyway.

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.

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

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 this category.

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. 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 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.On 28/07/2011 01:00, Mason Wheeler wrote:

[Tim_Angus]

I don’t necessarily think the compatibility layer should be removed as
you do, but I do agree that any new APIs should not be comprimised in
order to improve compatibility.

Also, while I don’t advocate its removal, I do think that the
compatibility layer should not be enabled by default. When doing 1.3/2.0
stuff now I routinely have to define SDL_NO_COMPAT somewhere in order to
ensure I’m building against the correct API. It should be opt in, not
opt out.On 28/07/2011 00:19, Bob Pendleton wrote:

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

[Forest_Hale]

The compatibility layer is probably superfluous and confusing, but that said I currently use SDL_SetVideoMode in darkplaces because I have yet to implement relative mouse motion in SDL 1.3 on Windows
and Linux (yeah, keep pestering me about that) and the SDL_SetVideoMode code does have relative mouse motion it seems

Regarding 2D acceleration, I do agree that it may not be “necessary” in any real sense in SDL, and that everyone should use OpenGL or D3D directly, but this adds a significant burden to people who
specifically used 2D to avoid this headache on each platform - especially the differences between OpenGL and OpenGL ES are of interest here :)On 07/28/2011 03:36 AM, Tim Angus wrote:

tl;dr version:

• Don’t be silly, HW acceleration on Linux is ubiquitous now and has been for some time.
• It doesn’t make sense to extend the SDL rendering API now when OpenGL is available everywhere that matters and SDL is never going to be able to compete with it on a functionality basis anyway.

On 28/07/2011 01:00, 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 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.

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

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 this category.

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

---

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

[Torsten_Giebl]

Hello !

I think the problem is that SDL serves two relatively distinct purposes:

1. A platform abstration layer.
2. An API for 2D rendering.

Definitely, but even for simple 2D games people wanted,
since the SDL 1.2 days, Alpha Blending, Rotation, Zooming, and Flipping X/Y ( all if possible HW accelerated ! )
Features that every old 16 bit console like Genesis, SNES, … had.

Many people wrote that it would be perfectly fine for them,
if the software ones, would be generic functions without special optimizations.

If someone is coding a 2D game, he could ask SDL if HW acc. is possible
and if not, maybe pre-process stuff like rotation.

I do not want SDL to become a second Allegro Library,
but stuff like this is usefull even for the simplest 2D game.

Is this something that Sam Lantinga, Ryan Gordon and others here would agree to ?

CU

[Tim_Angus]

If there is really that much demand for this sort of thing I think it
may make sense to separate the renderer part of SDL off into its own
tertiary library in the same way that e.g. SDL_image is done. This could
have its own developers which care about this use case who would be free
to extend it without impingeing on the basic functionality. Sticking
this kind of stuff into the core of SDL feels like feature creep to me.On 28/07/2011 12:09, Torsten Giebl wrote:

since the SDL 1.2 days, Alpha Blending, Rotation, Zooming, and Flipping
X/Y ( all if possible HW accelerated ! )
Features that every old 16 bit console like Genesis, SNES, … had.

[Pallav_Nawani]

Exactly, SDL should sit under those frameworks, but can’t, because SDL
feature set is missing some useful stuff.

For instance, Popcap framework supports rotated blitting etc
(I intend to port Popcap to SDL 1.3, btw)On 28-07-2011 11:59, Ryan C. Gordon wrote:

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.

---

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

[Torsten_Giebl]

Hello !

since the SDL 1.2 days, Alpha Blending, Rotation, Zooming, and Flipping
X/Y ( all if possible HW accelerated ! )
Features that every old 16 bit console like Genesis, SNES, … had.

If there is really that much demand for this sort of thing I think it may make sense
to separate the renderer part of SDL off into its own tertiary library in the same
way that e.g. SDL_image is done. This could have its own developers which care
about this use case who would be free to extend it without impingeing on the
basic functionality. Sticking this kind of stuff into the core of SDL feels like feature creep to me.

One function for Rotation + Zooming + Flipping
and another one to query the size that the final surface will have.

Two functions and you can make every 2D coder happy.

Would that really feel like feature creep ?

The 3D ones will be very short, just doing some matrix stuff,
the 2D one will be a little bit longer, but it will not double the size
of SDL or anything like that.

CU

[Beoran]

I agree with Thorsten and disagree with Tim.
Since SDL 1.3, we have SDL_Renderer being part of SDL.
Now, unless you’re arguing that this should be taken
out into a separate libary, rendering is now part of SDL also.
And rightly so, because the renderer wraps important details
about the hardware (or software) in a uniform interface.

And if rendering is in, then let’s make it powerful enough to
have at least the features of a 16 bits game console, not like
an 8 bit game console now. SDL as a solid basis for 2d games,
so everyone and their horse doesn’t have to reivent the wheel.

Torsten is right, what we need is a affine matrix transform
blitting and coloring function. In Hajime Hoshi’s starruby this is
just about 200 lines of C for a software variant. This and this does
all the flipping, projecting to mode 7 style, coloring, rotating,
shearing, etc, in one go. I’ll start writing this function right away
if it will be accepted into SDL.

[Tim_Angus]

To be honest I don’t really have any particularly strong feelings on the
matter, but I can understand the resistance in adding this stuff if the
software path is to be maintained. Having affine transformations here
entails breaking the existing assumption that any rendering operations
are pixel perfect and opens a whole can of worms in terms of what to do
with filtering/anti-aliasing.

Having a separate rendering library frees up the responsibility for all
this stuff to someone who cares about the renderer’s funcionality and
has the impetus to put the effort in, leaving the job of maintaining the
core and primary functionality of SDL to the existing developers.

It’s just as idea; as I say I don’t really care either way, providing
SDL continues to be a nice platform abstraction layer.On 28/07/2011 12:34, Torsten Giebl wrote:

One function for Rotation + Zooming + Flipping
and another one to query the size that the final surface will have.

Two functions and you can make every 2D coder happy.

Would that really feel like feature creep ?