SDL 1.3 status?

Gregory_Smith · July 28, 2011, 12:53pm

Nicholas,On Wed, 27 Jul 2011, Nicholas Vining wrote:

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

Aleph One (http://marathon.sourceforge.net/) uses an SDL_Image Framework
built with SDL_IMAGE_USE_COMMON_BACKEND defined, and also includes JPEG
and PNG Frameworks. There are instructions on how we built it here:
http://marathon.svn.sourceforge.net/viewvc/marathon/frameworks/trunk/README

We do this because stock SDL_Image can’t load combined normal/height maps
from PNG files–an operation just as fundamental as loading 8-bit PNGs.

A few people have been bitten by SDL_Image’s different and limited
behavior on Mac OS X. I wonder if there’s a better way to publicize
SDL_IMAGE_USE_COMMON_BACKEND than by my posting a reply every time someone
says they’ve already ditched SDL_Image.

I’d suggest offering an official alternate version, with full
functionality for those of us who need it at the cost of the 100s of K
using UIKit saves. But, we can’t volunteer to maintain it outside of our
game–we don’t even really want to maintain it inside our game

Gregory

Mason_Wheeler · July 28, 2011, 1:04pm

To explain, the last time we did this discussion, that was pretty much the only source
of resistance.? The argument could be summed up as “we can’t do that because it’s
hard to get OpenGL working right on desktop Linux.? 3D drivers are very difficult
to get right.? The video card companies don’t bother writing them for anything but
Windows,because that’s where all the market share is, and even when they do make
thenecessary technical information available, which is pretty darn rare because of
perceived intellectual property concerns, actually writing a correct OpenGL
implementationis very, very difficult for your average Free Software hacker because
it requires specialized skills and advanced math.? So we can’t get good drivers, so
dropping support for X11 is equivalent to dropping support for Linux entirely, which
would be a horrible thing!”

Apparently your experience is different from theirs, but that same basic argument was
coming in from multiple people.? I just sorta thought it was silly then, and still do.
Feels like the tail wagging the dog to me.________________________________
From: bob@pendleton.com (Bob Pendleton)
Subject: Re: [SDL] SDL 1.3 status ?

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.

Mason_Wheeler · July 28, 2011, 1:22pm

Please, no.? The last thing I want is to make the SDL DLL Hell even worse!? I like my deployments to be as clean as possible, and to be frank, SDL is the major thing standing in the way of that goal.? Right now my installer consists of the EXE, a few data files, and the support DLLs:

5 DLLs required to support the database

SDL
SDL_Image
2 DLLs required to support SDL_Image (Would be more, except I made a design decision to only support PNG images)

SDL_Mixer
5 DLLs required to support SDL_Mixer (there are a lot more libraries involved, but those a the ones I couldn’t get to statically link into SDL_Mixer for various reasons.)
2 different C runtimes to support all the other dependencies

Ideally, I’d like to be able to deploy one single “SDL.dll” that handles all multimedia needs.? That would clear up so many headaches for me.? But in the absence of that, can we please at least not make it any worse?________________________________
From: tim@ngus.net (Tim Angus)
Subject: Re: [SDL] SDL 1.3 status ?

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.

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.

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

Brian_Barnes · July 28, 2011, 1:30pm

I’ll wade into this with a vote only for removing the compatibility
layer. In dim3, I need SDL 1.3 for iOS, but until I get relative mouse
movement I can’t use it on the OS X/windows/linux desktop version.

So my code looks like this:

#ifdef D3_SDL_1_3
sdl_flags=SDL_WINDOW_OPENGL|SDL_WINDOW_SHOWN;
if (!gl_in_window_mode()) sdl_flags|=SDL_WINDOW_FULLSCREEN;

sdl_wind=SDL_CreateWindow("dim3",SDL_WINDOWPOS_CENTERED,SDL_WINDOWPOS_CENTERED,setup.screen.x_sz,setup.screen.y_sz,sdl_flags);
if (sdl_wind==NULL) {
	sprintf(err_str,"SDL: Could not create window (Error:

%s)",SDL_GetError());
return(FALSE);
}

sdl_gl_ctx=SDL_GL_CreateContext(sdl_wind);

#else
if (gl_in_window_mode()) {

surface=SDL_SetVideoMode(setup.screen.x_sz,setup.screen.y_sz,32,SDL_OPENGL|SDL_HWSURFACE);
SDL_WM_SetCaption(“dim3”,NULL);
}
else {

surface=SDL_SetVideoMode(setup.screen.x_sz,setup.screen.y_sz,32,SDL_OPENGL|SDL_FULLSCREEN);
}

if (surface==NULL) {
	sprintf(err_str,"SDL: Could not set video mode (Error:

%s)",SDL_GetError());
return(FALSE);
}

#ifdef D3_OS_MAC
	if (!gl_in_window_mode()) SetSystemUIMode(kUIModeContentSuppressed,0);
#endif

#endif

It’s NOT that big of a deal. I really didn’t have to do this a lot, and
only in a couple places (the events were the places that got most
sticky, but that wasn’t bad either.)

So, I say drop the comparability layer, especially if it’s slowing down
development or introducing bugs that have to be fixed with a boat load
of spaghetti code.

[>] Brian

Mason_Wheeler · July 28, 2011, 1:54pm

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:

A platform abstration layer.

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

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.

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?From: tim@ngus.net (Tim Angus)

Subject: Re: [SDL] SDL 1.3 status ?

Beoran · July 28, 2011, 2:05pm

Mason, you say that adding a few rendering 2D functions to the SDL core is “feature creep”, but the you want to put the whole of SDL_image and SDL_mixer into SDL? How is that not feature creep? Honestly, if we split this up in a separate SDL_renderer library, you’ll be distributing that too before long. Wagging the dog indeed.

As for the problems with Linux, it’s not only the drivers. Sometimes the hardware just sucks, and that’s onot only on linux as well. I said the same several times before on the forum, but my messages didn’t came though on the mailing list.

Beoran · July 28, 2011, 2:11pm

Mason Wheeler wrote:

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.

Actually, here I agree mostly with you. I think complex shaders might be overkill for
2d games, but color shading not. But I want a software version too of most things.
So I’ll write those, if we can agree upon the functions we need.

Kind regards,

B.

Tim_Angus · July 28, 2011, 2:13pm

It’s not my argument; it’s the one that the people arguing against
my argument used last time this came up.

Regardless of whose argument it is, it’s a poor one.

You don’t see rendering backends as sufficiently complex to warrant
the “platform” designation? I do, which makes your distinction a case
of splitting hairs.

No since OpenGL is portable enough that it doesn’t need an abstraction
except for the parts which SDL already provides. I see SDL and OpenGL as
symbiotic.

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 think you’re rather over-estimating how complicated OpenGL is to use.
You certainly don’t need to “reimplement all of SDL” to make use of it.

Just out of curiosity, have you ever looked at the implementation of
GL_CreateTexture in sdl_render_gl.c?

I hadn’t since I don’t use the SDL rendering API and don’t really have
any interest in it. I’ve looked just now since you’ve effectively asked
me to. It looks fine to me? I’m not sure what your point is?On 28/07/2011 14:54, Mason Wheeler wrote:

Mason_Wheeler · July 28, 2011, 2:24pm

Mason, you say that adding a few rendering 2D functions to the SDL
core is “feature creep”, but the you want to put the whole of SDL
image and SDL_mixer into SDL? How is that not feature creep?

Actually no, I did not say that adding a few rendering 2D functions
to the SDL core is “feature creep”.? Feature creep is adding unnecessary
features for the sake of adding features.? I don’t find the things I’m asking
for unnecessary.>From: Beoran

Subject: Re: [SDL] SDL 1.3 status ?

Mason_Wheeler · July 28, 2011, 2:36pm

It’s not my argument; it’s the one that the people arguing against
my argument used last time this came up.

Regardless of whose argument it is, it’s a poor one.

Fair enough.? One less reason to let it influence decisions about the
future of SDL, then.

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 think you’re rather over-estimating how complicated OpenGL is to use.
You certainly don’t need to “reimplement all of SDL” to make use of it.

If I can’t use SDL textures for sprites, I need something else.? If I’m not
using SDL video, I can’t use SDL events, because the two are very tightly
coupled.? I also can’t use SDL_Image, for obvious reasons.? Without
SDL video and SDL events, I have no need for the library at all, except
the subset that SDL_Mixer is dependent on.

Just out of curiosity, have you ever looked at the implementation of
GL_CreateTexture in sdl_render_gl.c?

I hadn’t since I don’t use the SDL rendering API and don’t really have
any interest in it. I’ve looked just now since you’ve effectively asked
me to. It looks fine to me? I’m not sure what your point is?

My point is, it’s ~150 lines of code and requires 10 local variables, 10
if statements, 5 returns and 4 ifdefs.? That’s a whole lot of complexity
required to correctly set up a texture, which I’m really glad to not have
to deal with or reimplement.>From: Tim Angus

Subject: Re: SDL 1.3 status ?
On 28/07/2011 14:54, Mason Wheeler wrote:

Tim_Angus · July 28, 2011, 2:49pm

If I can’t use SDL textures for sprites, I need something else. If I’m not
using SDL video, I can’t use SDL events, because the two are very tightly
coupled.

That’s not the case, you can use events without using the SDL rendering
API. If you’re writing an SDL/OpenGL application you’re still using the
video subsystem. If you couldn’t use events with such an application it
would make SDL rather pointless.

I also can’t use SDL_Image, for obvious reasons.

You can still use SDL_Image if you wanted to. SDL_Image is just a
frontend to various image loaders. It’s no problem to buffer an OpenGL
texture from an SDL_Surface or any other decoded image buffer for that
matter.

My point is, it’s ~150 lines of code and requires 10 local variables, 10
if statements, 5 returns and 4 ifdefs. That’s a whole lot of complexity
required to correctly set up a texture, which I’m really glad to not have
to deal with or reimplement.

This is a special case though; it’s having to do everything in terms of
SDL. If all you want to do is buffer a texture from a memory buffer, you
don’t need all that code.On 28/07/2011 15:36, Mason Wheeler wrote:

Beoran · July 28, 2011, 3:08pm

Ok, I misunderstood you there. I actually agree that these features (rotozoom/coloring, etc)
should be added to SDL too.

If I understand you correctly, the reason you want to drop sw rendering and X11 is because
you see them as a hinderance to getting the features you want into SDL. I think that’s not
neccesarily the case. I know you want these features but that’s not a reason for other,
existing features to be dropped! What you really need is more developers helping out with SDL,
not chasing them off by droping or not implementing features they might need.

As I said before, I need those functions you want HW accellerated in software.
So, I think we should cooperate! We agree on the needed functions, you write the HW
accellerated versions and I do the SW equivalents. If you’re done earlier than me just
put in stubs for the SW versions until I catch up. I always like more code and less arguing.

Kind Regards,

B.

Mason Wheeler wrote:>

Actually no, I did not say that adding a few rendering 2D functions
to the SDL core is “feature creep”. Feature creep is adding unnecessary
features for the sake of adding features. I don’t find the things I’m asking
for unnecessary.

Andreas_Schiffler · July 28, 2011, 3:58pm

In my view to have a software-only implementation of rendering functions

however slow it may be - is actually a good thing as it can serve as a
"reference implementation" for testing other renderers. This years GSoC
student - whom I am mentoring - has made great progress in writing some
tooling to automate and improve the testing of SDL. Although pixel-level
testing will probably not be part of this new framework due to time
constraints, it was originally a goal. Such tests would have to rely on
a software-only simulation (or implementation) to validate the output
(screencapture) of other renderers.

Personally, I would prefer an implementation that is based on a 3D-only
approach with Mesa3D as a software-based failsafe and visual reference
via the Off-screen rendering API (OSMesa - see
http://mesa3d.org/osmesa.html).

–Andreas

Beoran · July 28, 2011, 4:12pm

Andreas,

It’s true that an sw renderer is also useful for testing. It’s also useful for writing
image editing programs, to do precomposing or prerendering of your sprites, etc.
But Mesa3D is slow as molasses. It’s not a viable replacement for SDL’s current
software renderer.

Kind Regards,

B.

RodrigoCard · July 28, 2011, 7:32pm

I am completely against droping support for software rendering.

When you develop simple 2D games, people who play your games expect it to run everywhere, even on crappy old integrated video stuff.
As a developer, I also expect to everyone who wants to play my game, that they can do it on their old Pentium III.

If you are someone who thinks that no one have awful PCs, and the “few” ones in this conditions dont deserve to play your game, its your choice.
Just dont expect to everyone to think like you =)----------

About the SDL_Compat, I dont think it worth the effort, since it is not fully compatible.

just my 4 cents =)

Mason_Wheeler · July 28, 2011, 8:18pm

See, that’s just it. The P3 was released in 1999. Accelerated video was already a standard feature on new Windows boxes by then.? A P3 running Windows 98 can handle up to DX7 without trouble, and DX8 on most video cards, though some crappy integrated chips don’t support it.? I still remember those days.________________________________
From: cuecax@gmail.com (Rodrigo C. Rocha)
Subject: Re: [SDL] SDL 1.3 status ?

I am completely against droping support for software rendering.

When you develop simple 2D games, people who play your games expect it to run everywhere, even on crappy old integrated video stuff.
As a developer, I also expect to everyone who wants to play my game, that they can do it on their old Pentium III.

If you are someone who thinks that no one have awful PCs, and the “few” ones in this conditions dont deserve to play your game, its your choice.
Just dont expect to everyone to think like you =)

Beoran · July 28, 2011, 8:44pm

It’s not just 10 year ago. My nettop and cheap desktop have equally crappy integrated chips and they’re 4 and 3 years old. The software renderer is ±50% faster than the HW “accelerated” one on them for me. And yes, I have the right driver. The driver can’t help the crappiness of the hardware. And think a bit out of the box. SDL is being used for car automation, for GUIs on devices that don’t even have Opengl or Directx acceleration, on underpowered handheld gaming devices like the GPX2, and all the other framebuffer devices out there, and the Nintendo DS. And apart from that software rendering is very useful for other things too like testing, image editing, precomposing, …

Martin, I think you’ll be happier to use Haaf’s game engine in stead of SDL. It’s windows only but HW accellerated based on Directx and has everything you seem to want. http://hge.relishgames.com/

Mason Wheeler wrote:> See, that’s just it. The P3 was released in 1999. Accelerated video was already a standard feature on new Windows boxes by then. A P3 running Windows 98 can handle up to DX7 without trouble, and DX8 on most video cards, though some crappy integrated chips don’t support it. I still remember those days.

Beoran · July 28, 2011, 6:55am

I disagree with Pallav and Mason on “ditching” X11 and GDI. For me the software renderer is essential. For example, on both my Linux desktops, the harware “accellerated” openGL driver is so slow that it’s actuallly 50% slower than the SDL software renderer. And on windows, the GDI backend does wonders for compatibility with systems with a crummy setup. Not to mention a (future?) linux fbcon driver for the many tiny devices that don’t have opengl/es. You’d be surprised how many of them there are out there. SDL is not only used for games, it’s also the underlying api for GUIs in non-accelerated embedded devices. Look at DACHSview-SDL, CEGUI, Agar, Milkytracker on GPX2, etc. And, if you’re writing a graphics or sprite editor in SDL, how will you draw to the bitmap that the user is editing if you don’t have a software renderer?

I don’t think the software renderer is “holding back” development of SDL. What are those features that other 2D game libs have and that SDL is mising? When I look at Allegro 5, the main missing things are rotozooming, tinted blits, and the drawing of primitive triangles, rounded rectangles, ellipses, circles, arcs, splines and ribbons. It’s not like a software version of those things are that hard to write. Just look at SPRIG, SGE, SDL_gfx, Allegro , or … Plenty of sources we can ask to borrow code from (with Allegro it’s even easier as it’s zlib license is comatible with sdl’s).

I also disagree with Ryan though. I don’t believe in a slippery slope argument. There are many things that SDL has been lacking historically, compared to other 2D game API’s like Allegro. So everyone and their dog implemented software extension libraries on top of SDL to deal with these missing features. I think it’s high time we enrichened SDL’s 2D functionality. And now that SDL has a new renderer API, it seems like a great time to do that. The only thing I think which doesn’t belong into SDL is 3D functionality, which belongs in the many diverse 3D engines that are built on SDL.

I already found and fixed a small bug in the software scaling, and I’m willing to contribute more to keep the software renderer alive and kicking. If people want more accellerated 2D functionality in the renderer, then please suggest it and implement it for Opengl and Direct3d, and I’ll step up to the plate and contribute a software version too. In fact, for things like circle primitives, a well written, generic software renderer can be of assistance in calculating the points for the lines or triangle strips. I say, let’s stop complaining, and start contributing.

As for the versioning, definitely make it SDL 2.0. We should start to call it sdl 2.0 beta ASAP. And I’m all in favor of dropping the 1.2 compatibility API. If we increase the major version number, dropping backwards compatibility is absolutely acceptable, and may win us some time.

Beoran · July 28, 2011, 7:47am

Wilbefast: that’s exactly what I’m getting at. The strength of SDL is the wide array of backends it supports. If you want a game lib that only supports popular HW accelerated backends, then SFML (OpenGL only, IIRC) or Allegro 5 (OpenGL + DirectX, IIRC) will do just fine. No sense in occupying the same market space as those libraries.

As for your reasons to like SFML better, 1) Is amply covered since there are at least 3 c++ free wrappers of SDL, not to mention wrappers in Python, Ruby, Haskell , Scheme, lisp, … and whatever other language really. That’s why it’s nice SDL is written in plain c, it’s easy to wrap for other languages. 2. Is being solved now, and 3 and 4 are some things we should work on.

Beoran · July 28, 2011, 8:19am

Forest, sure, IF (big IF that) HW acelleration works well, it’s faster, of course. As for software renderers being CPU hogs, that’s true but not a problem, since games simply are CPU hogs, to be better of service to our customers.

However it’s not a matter of “misconfigured drivers” only. On linux there’s the “not very good drivers” phenomenon. On windows there’s the “users who don’t know how to install drivers” phenomenon. And sometimes the hardware simply sucks. As I said before, I have a hardware accellerated card under linux (in a desktop box that cost me only 230 euro when I bough it) where the HW accel is slower than sw blitting, simply because the graphics card itself sucks that much (it’s one for nettops, I think). Not to mention the Intel graphics chip on my nettop which has similar problems. (It seems Intels loves it that you use the CPU more than the gfx chip.)

I think some people here just don’t understand how underpowered some graphics hardware can be. It’s not because your lastest high end gfx card is so fast, that all other people have a similar one. There are much more people with badly accelerated or unacellerated devices than you might imagine. Plenty of old and/or underpowered and/or tiny devices and computers out there. SDL is ideal for those to, since it’s so widely portable.