Discussion:
Proposal: Drop support for software rendering in 1.3
(too old to reply)
Mason Wheeler
2011-01-20 22:41:48 UTC
Permalink
After some discussion on the "Again Rotozoom" thread, I figure I may as well
formally raise this proposal:

Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.

Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels. As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.


Can everyone agree on this?

Mason
Nathaniel J Fries
2011-01-20 23:01:13 UTC
Permalink
I agree that it is silly to stunt progress just to support some archaic method of rendering.

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Jonathan Dearborn
2011-01-20 23:21:06 UTC
Permalink
Ugh. I like having a fallback and assurance that SDL 1.3 would work on odd
platforms, but I feel like I agree... :(

Jonny D
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels. As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Drake Wilson
2011-01-20 23:42:19 UTC
Permalink
Post by Mason Wheeler
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Can we clarify which parts of SDL are being discussed here? I would
be rather unhappy if SDL decided that it wouldn't give me a window at
all on an X11+OpenGL system. Are you referring to the parts that do
2D graphics primitives that I see in SDL_surface.h in the Hg repo?

I'm a little wary about losing in-process compositing in general,
since pushing stuff to the video card and then getting it _back_ is
both awkward and expensive, but I've rarely used it from the SDL side
per se, so that's not much of a vote. I rather doubt I'd bother with
fancy optimized CPU blits anymore, at least; I think in-process blits
are mostly useful for preprocessing these days. E.g., in one OpenGL
program I transform a giant image strip into a more rectangular lookup
texture by slinging rectangles from the one to the other, but I do it
with an internal grayscale-image structure, so SDL isn't involved in
that case (despite using it for the interface setup of the program).

---> Drake Wilson
Sam Lantinga
2011-01-20 23:42:37 UTC
Permalink
I'm not opposed to this, but I'd like to hear lots of people's opinions
before making any changes.

A few thoughts:

* One of the nice things about this is we can expand the renderer API with
some features like rotation that just aren't possible at speed with software
only solutions.

* If we do this, I'd like to standardize on texture formats and renderer
capabilities to simplify people's experience making games.
- What would be the minimum set of supported texture formats?

* Does the surface and blit API go away? How do we represent pixel data
that's uploaded to textures? What do we do for SDL 1.2 compatibility?

* I know of several companies relying on the YV12 texture support for video
playback. Right now most of the accelerated back ends do not support YV12
textures.
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels. As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Mason Wheeler
2011-01-21 00:00:43 UTC
Permalink
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
* Does the surface and blit API go away?
I'm fine with keeping surfaces and blits. I
actually use those in conjunction with the
PNG-saving routine I added to SDL_Image
to do simple image manipulation. (Stuff like
chopping images up.) I'm talking about the
rendering-to-screen side of things here.
* I know of several companies relying on the
YV12 texture support for video playback. Right
now most of the accelerated back ends do not
support YV12 textures.
No idea, but I bet if you posted a question about
how to embed YUV playback in a [OpenGL|D3D]
rendering context on StackOverflow.com, you'd
get at least one good answer within a few hours...
Greg Jandl
2011-01-21 00:15:28 UTC
Permalink
Post by Sam Lantinga
I'm not opposed to this, but I'd like to hear lots of people's opinions
before making any changes.
You can put me in the +1 camp, I suppose, though it sure *seems* like
we should be able to provide a path to fall back to software
rendering.

As long as there was a clear way to query for acceleration (preferably
on a per-feature basis), I don't see why it should hold back hardware
accelerated features. A user of the software rendering engine would
simply have to not use features that they find too slow.

It's really no different than checking supported extensions in OpenGL
or checking supported features in D3D, is it?
Post by Sam Lantinga
* If we do this, I'd like to standardize on texture formats and renderer
capabilities to simplify people's experience making games.
 - What would be the minimum set of supported texture formats?
As long as I don't lose the ability to load PNGs and JPEGs, I
personally have no preference.
Post by Sam Lantinga
* Does the surface and blit API go away?  How do we represent pixel data
that's uploaded to textures?
I certainly *hope* the surface API doesn't go anywhere! it's too useful.
Post by Sam Lantinga
What do we do for SDL 1.2 compatibility?
I propose we drop it all together, regardless of whether or not 1.3
ends up with a software rendering engine. The SDL 1.2 compatibility
story should be "Use SDL 1.2".

Of course, that may mean at least giving lip service to maintaining
1.2, but, if it's really in that much demand, someone should be
willing to step forward and help out there.
Post by Sam Lantinga
* I know of several companies relying on the YV12 texture support for video
playback.  Right now most of the accelerated back ends do not support YV12
textures.
Are these companies currently using 1.2 (or the 1.2 compatibility API
in 1.3), or have they moved to native 1.3? If the former, then I'm not
sure I see a problem.
--
Do what you can, where you are, with what you have. - T. Roosevelt
Neil White
2011-01-21 00:29:12 UTC
Permalink
i think SDL should remain as crossplatorerablility as possible

lots of people running linux may not have gl installed, and on some systems,
low grade intel gfx, it is an ass

i have had systems where a simple 2d game will run like a sak of dogs doo
just cos no gl is installed

lowlevel devices may not have gl capability

but, saying that, the 'just use sdl1.2' is the best and sdl1.3 should move
to reflect modern technologies rather than keep a minority of users and
developers happy,

perhaps even make a sure of distinguishing the difference between sdl1.2 and
sdl1.3 by upon release calling it something else, like sdml or something,
that would also mean less headache when having both new sdl and old sdl on
the same system ( esp linux )
jon
2011-01-21 00:48:01 UTC
Permalink
Post by Neil White
i think SDL should remain as crossplatorerablility as possible
lots of people running linux may not have gl installed, and on some
systems, low grade intel gfx, it is an ass
i have had systems where a simple 2d game will run like a sak of dogs
doo just cos no gl is installed
lowlevel devices may not have gl capability
but, saying that, the 'just use sdl1.2' is the best and sdl1.3 should
move to reflect modern technologies rather than keep a minority of
users and developers happy,
perhaps even make a sure of distinguishing the difference between
sdl1.2 and sdl1.3 by upon release calling it something else, like sdml
or something, that would also mean less headache when having both new
sdl and old sdl on the same system ( esp linux )
FWIW (and I'm mostly a lurker) since the 1.2 api is so different from
1.3 it seems like a major version number should have been incremented.

SDL 1.3 -> SDL 2.0

Unless that was discussed to death and shot down..
Sam Lantinga
2011-01-21 01:14:12 UTC
Permalink
No, it will be bumped to 2.0 before release. 1.3 is the in-progress
version.
Post by jon
Post by Neil White
i think SDL should remain as crossplatorerablility as possible
lots of people running linux may not have gl installed, and on some
systems, low grade intel gfx, it is an ass
i have had systems where a simple 2d game will run like a sak of dogs
doo just cos no gl is installed
lowlevel devices may not have gl capability
but, saying that, the 'just use sdl1.2' is the best and sdl1.3 should
move to reflect modern technologies rather than keep a minority of
users and developers happy,
perhaps even make a sure of distinguishing the difference between
sdl1.2 and sdl1.3 by upon release calling it something else, like sdml
or something, that would also mean less headache when having both new
sdl and old sdl on the same system ( esp linux )
FWIW (and I'm mostly a lurker) since the 1.2 api is so different from
1.3 it seems like a major version number should have been incremented.
SDL 1.3 -> SDL 2.0
Unless that was discussed to death and shot down..
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Rainer Deyke
2011-01-21 03:23:05 UTC
Permalink
Post by Sam Lantinga
* One of the nice things about this is we can expand the renderer API with
some features like rotation that just aren't possible at speed with software
only solutions.
Realtime software rotation has been used in games for at least /2
decades/ now, and predates consumer-level 3D acceleration by quite a
bit. This is not a good reason for dropping the software renderer.
--
Rainer Deyke - ***@eldwood.com
Alex Barry
2011-01-21 03:35:18 UTC
Permalink
I think instead of dropping support directly, it should be put in as a
seperate library, much like SDL_image or SDL_net. I don't know how easy
that would be, but it would offer an easy add-in for new platforms, plus a
compatibility layer for older machines. How feasible is this, and how much
work would it take for it to be completely community maintained (As opposed
to just Sam [and the other devs?]).

-Oz
Post by Mason Wheeler
Post by Sam Lantinga
* One of the nice things about this is we can expand the renderer API
with
Post by Sam Lantinga
some features like rotation that just aren't possible at speed with
software
Post by Sam Lantinga
only solutions.
Realtime software rotation has been used in games for at least /2
decades/ now, and predates consumer-level 3D acceleration by quite a
bit. This is not a good reason for dropping the software renderer.
--
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Torsten Giebl
2011-01-21 03:39:42 UTC
Permalink
Hello !


1.
Does SDL 1.3 still support palette based surfaces ?

If yes, would it help clean up SDL 1.3 to remove those palette stuff,
when needed we could always advice people to use SDL 1.2.
Every major device that might want to run SDL 1.3 has at least HiColor
support.

2.
I would personally be against dropping X11, GDI and those non accelerated
backends. First, we need X11, GDI and so on to get OpenGL running,
second, when we have a software renderer, even a slow one, we can use
it with X11, GDI, ..., third i want to have a way to display error messages
and have other setup stuff, in a way, that i can be sure it runs on every system.

If for whatever reason OpenGL, D9D, D10D does not run a system, i can at least
open a window with an error message or let the user change some settings, in a GUI way.

GUI toolkit makers will get interested in SDL in the future, as it has all the
usefull stuff, like Multi Window, Multi touch, touch events ....

3.
When reading all the mails about dropping the 2D stuff, i am curious about
how to do unconventional stuff with SDL 1.3 and OpenGL, DX9, DX10 that is different than
the normal rect blitting.

When i am interested in a special effect like rotating, zooming, i can implement a software
renderer easily in my game, as a fallback, but what when i want to use OpenGL tricks,
shader stuff and so on in addition to SDL 1.3.

What are the things i have to take care of ?
With 2D i create my software surfaces, maybe have to lock them,
but then can do anything on the pixels, without restrictions, what about 3D ?

Game coders need to do more with 3D than only straight rect blitting,
what are the rules in OpenGL, DX9, DX10, OpenGL ES ? Is there some info
in the wiki ?

I want to be able to write a plugin library, like SDL_image, but for special effects
for SDL 1.3, that can use hardware acceleration, if available.

Is this possible ?


CU
Jeff Post
2011-01-21 04:16:40 UTC
Permalink
Post by Torsten Giebl
I would personally be against dropping X11, GDI and those non accelerated
backends.
If X11 support were dropped, that means I'd have to find some other GUI
library to use, and dammit, I *like* SDL!

Jeff
Nicholas Vining
2011-01-21 08:53:53 UTC
Permalink
Post by Sam Lantinga
I'm not opposed to this, but I'd like to hear lots of people's
opinions before making any changes.
Count me among the opposed. I'm actually writing my first post on this
mailing list in five years (I think) to weigh in here, so I suppose
that's some measure of my opposition.

The main advantage of SDL, versus its competitors, is that SDL is a
lightweight platform that makes certain guarantees. One of these
guarantees is its software render: any application using the sprite and
blit architecture, written with SDL, is pretty much guaranteed to work.
I can sell more games this way, because SDL's GDI target means that
it'll work on hideously broken Windows XP installs with incorrect
drivers running DirectX 7, and the user will still get a good framerate.
The software renderer also guarantees that a correctly written SDL
application will, with the exception of the odd platform-specific bug,
work on multiple platforms with minimal code changes. My current project
runs just fine on Windows, OS X, and Linux, because in each case it does
the stupidest thing possible on the operating system of choice. As a
result, I can spend more time working on things that matter, and less
time trying to navigate the complicated and hideous web of bugs that
may, possibly, be related to IHV drivers, but which are made all the
more fun by the fact that all your blitting functions - the things that
you're trying to debug - are suddenly hidden in another library. SDL
insulates me from all of that. This is a Good Thing.

Why is it a good thing? Simply put, anybody who thinks that software
rendering does not have its place when trying to sell software in the
year 2011 has obviously never had the experience of shipping a
commercial game to real users. Things are somewhat better if you are
trying to sell to the hard-core PC gamer market, but that consists of
about three people in a basement in Grand Forks. Anybody who wants to
sell game software to the casual market will encounter a wide variety of
machine configurations, ranging from the somewhat normal to the
completely insane.

Here's an example: imagine, for a moment, your grandmother. Now imagine
that your grandmother wants to play your spiffy new Solitare clone. Now
imagine what is involved in telling your grandmother how to install a
new set of video drivers on her aging computer, over the phone. For
bonus points, get her to install an updated DirectX redistributable
runtime as well. I would much rather that my Solitare clone - which
doesn't need hardware accelerated rendering in the first place - uses
GDI and is done with it.

So, yes, software rendering still has a place in the world. As a further
example of that, I would point out that RAD Game Tools is still selling
Pixomatic, a ridiculously hand-optimized DirectX 7/DirectX 9 drop in
software renderer, as their solution for dealing with just this kind of
hideously broken computer. One company I know, who will not be named,
ships a product with Direct3D, OpenGL and Pixomatic rendering targets.
To their surprise, and mild horror, Pixomatic *beats* the other two
"hardware-accelerated" render targets in terms of performance on many of
their users' machine, mainly because their users are running things like
Intel Extreme 2 Integrated Graphics Accelerators, with drivers from
2001, on clapped out Dell Inspirons. You know what? These people deserve
to be able to use and buy our software too. Let them have their software
renderer.

That said, there may be a case for getting rid of a lot of the software
rendering pipeline in SDL. I would be fine, for instance, if SDL 1.3
just gave me a framebuffer and told me to fill it. Radically
streamlining the software rendering pipeline in this fashion so that
other parts of SDL 1.3 can be finished might be a good trade-off. We
could also get rid of a bunch of things, like line drawing functions,
that don't really meet the "Simple" criterion of the Simple DirectMedia
Layer.

In my mind, it is not acceptable for us to get rid of the software
renderer in exchange for a bunch of fancy, bejewelled gewgaws like
"hardware accelerated rotational blitting", whatever the heck that is.
If you want to have a game with rotating sprites, you have two sane
choices.

1. Use OpenGL (or Direct3D), and do the math yourself, in the
application, to calculate the rotated position of the four points of the
sprite. Draw a textured quad spanning those points. The math is very
simple, consisting of a 2x2 matrix rotation, and has been known since
the 17th century. It is also very easy to set OpenGL up with an
orthographic projection.

2. Do the math to calculate the rotated position of the four points of
the sprite, and then write your own texture blitter. The math is still
very simple, and you can still find an accurate depiction of the texture
mapping process in sources such as Michael Abrash's Graphics Programming
Black Book, which is still available online.

Forcing SDL to carry these burdens for you is not a sane choice, nor is
it a choice that is compatible with the library's designated purpose:
providing a thin layer of access, in a cross-platform manner, to OS
level multimedia facilities. I must confess, I'm already puzzled as to
why we have things like line drawing functions in SDL 1.3. Bresenham's
line algorithm is a fun, easy programming exercise that programmers of
all ages and skill levels can enjoy, and I don't think that it's fair to
deprive people of this pleasure.

I would encourage anybody who thinks that they have a good idea for SDL
to strongly consider what the feature they propose adds, and at what
cost. Feature creep is a very, very good way to kill projects.

Signing out for another five years,

N.
--
Nicholas Vining
Lead Programmer, Gaslamp Games
Dungeons of Dredmor, Coming in April 2011: http://www.gaslampgames.com
Damian Paz
2011-01-21 08:59:51 UTC
Permalink
To be honest I've never thought about using SDL to write a game for a 386 SXL. I
just wanna have a cross platform API that will allow me to create an OpenGL
context to do something that is worth watching at with ease, having event
handling and sound management is just a bonus for me.



________________________________
From: Nicholas Vining <***@icculus.org>
To: SDL Development List <***@lists.libsdl.org>
Sent: Fri, January 21, 2011 5:53:53 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/20/2011 3:42 PM, Sam Lantinga wrote:


I'm not opposed to this, but I'd like to hear lots of people's opinions
before making any changes.
Count me among the opposed. I'm actually writing my first post on this
mailing list in five years (I think) to weigh in here, so I suppose that's
some measure of my opposition.


The main advantage of SDL, versus its competitors, is that SDL is a
lightweight platform that makes certain guarantees. One of these guarantees
is its software render: any application using the sprite and blit
architecture, written with SDL, is pretty much guaranteed to work. I can
sell more games this way, because SDL's GDI target means that it'll work on
hideously broken Windows XP installs with incorrect drivers running DirectX
7, and the user will still get a good framerate. The software renderer also
guarantees that a correctly written SDL application will, with the exception
of the odd platform-specific bug, work on multiple platforms with minimal
code changes. My current project runs just fine on Windows, OS X, and Linux,
because in each case it does the stupidest thing possible on the operating
system of choice. As a result, I can spend more time working on things that
matter, and less time trying to navigate the complicated and hideous web of
bugs that may, possibly, be related to IHV drivers, but which are made all
the more fun by the fact that all your blitting functions - the things that
you're trying to debug - are suddenly hidden in another library. SDL
insulates me from all of that. This is a Good Thing.


Why is it a good thing? Simply put, anybody who thinks that software
rendering does not have its place when trying to sell software in the year
2011 has obviously never had the experience of shipping a commercial game to
real users. Things are somewhat better if you are trying to sell to the
hard-core PC gamer market, but that consists of about three people in a
basement in Grand Forks. Anybody who wants to sell game software to the
casual market will encounter a wide variety of machine configurations,
ranging from the somewhat normal to the completely insane.


Here's an example: imagine, for a moment, your grandmother. Now imagine that
your grandmother wants to play your spiffy new Solitare clone. Now imagine
what is involved in telling your grandmother how to install a new set of
video drivers on her aging computer, over the phone. For bonus points, get
her to install an updated DirectX redistributable runtime as well. I would
much rather that my Solitare clone - which doesn't need hardware accelerated
rendering in the first place - uses GDI and is done with it.


So, yes, software rendering still has a place in the world. As a further
example of that, I would point out that RAD Game Tools is still selling
Pixomatic, a ridiculously hand-optimized DirectX 7/DirectX 9 drop in
software renderer, as their solution for dealing with just this kind of
hideously broken computer. One company I know, who will not be named, ships
a product with Direct3D, OpenGL and Pixomatic rendering targets. To their
surprise, and mild horror, Pixomatic *beats* the other two
"hardware-accelerated" render targets in terms of performance on many of
their users' machine, mainly because their users are running things like
Intel Extreme 2 Integrated Graphics Accelerators, with drivers from 2001, on
clapped out Dell Inspirons. You know what? These people deserve to be able
to use and buy our software too. Let them have their software renderer.


That said, there may be a case for getting rid of a lot of the software
rendering pipeline in SDL. I would be fine, for instance, if SDL 1.3 just
gave me a framebuffer and told me to fill it. Radically streamlining the
software rendering pipeline in this fashion so that other parts of SDL 1.3
can be finished might be a good trade-off. We could also get rid of a bunch
of things, like line drawing functions, that don't really meet the "Simple"
criterion of the Simple DirectMedia Layer.


In my mind, it is not acceptable for us to get rid of the software renderer
in exchange for a bunch of fancy, bejewelled gewgaws like "hardware
accelerated rotational blitting", whatever the heck that is. If you want to
have a game with rotating sprites, you have two sane choices.


1. Use OpenGL (or Direct3D), and do the math yourself, in the application,
to calculate the rotated position of the four points of the sprite. Draw a
textured quad spanning those points. The math is very simple, consisting of
a 2x2 matrix rotation, and has been known since the 17th century. It is also
very easy to set OpenGL up with an orthographic projection.


2. Do the math to calculate the rotated position of the four points of the
sprite, and then write your own texture blitter. The math is still very
simple, and you can still find an accurate depiction of the texture mapping
process in sources such as Michael Abrash's Graphics Programming Black Book,
which is still available online.


Forcing SDL to carry these burdens for you is not a sane choice, nor is it a
choice that is compatible with the library's designated purpose: providing a
thin layer of access, in a cross-platform manner, to OS level multimedia
facilities. I must confess, I'm already puzzled as to why we have things
like line drawing functions in SDL 1.3. Bresenham's line algorithm is a fun,
easy programming exercise that programmers of all ages and skill levels can
enjoy, and I don't think that it's fair to deprive people of this pleasure.


I would encourage anybody who thinks that they have a good idea for SDL to
strongly consider what the feature they propose adds, and at what cost.
Feature creep is a very, very good way to kill projects.


Signing out for another five years,

N.
--
Nicholas Vining
Lead Programmer, Gaslamp Games
Dungeons of Dredmor, Coming in April 2011: http://www.gaslampgames.com
Nathaniel J Fries
2011-01-20 23:56:21 UTC
Permalink
* If we do this, I'd like to standardize on texture formats and renderer capabilities to simplify people's experience making games.
 - What would be the minimum set of supported texture formats?
I would go with any non-paletted pixel format supported by PNG as the very minimum.
PNG is frequently used for 2D graphics and textures.

[quote="Sam Lantinga"]* Does the surface and blit API go away?  How do we represent pixel data that's uploaded to textures?  What do we do for SDL 1.2 compatibility?[/code]
This is still practical for image pre-processing and Surfaces are still useful as a universal pixel buffer.
I wouldn't worry too much about SDL 1.2 compatibility; though. SDL 1.2 is stable enough for most purposes, and SDL 1.3 is so vastly different that anybody using it isn't using it to get SDL 1.2's features.
I know that ignoring backwards compatibility is generally not welcomed, but in this case the two APIs have such vital differences that I don't think it's practical to even bother maintaining a compatibility layer.
* I know of several companies relying on the YV12 texture support for video playback.  Right now most of the accelerated back ends do not support YV12 textures.
Something to put on the TODO list; and in the meantime hold onto software rendering?

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Nathaniel J Fries
2011-01-21 01:14:56 UTC
Permalink
Post by jon
Post by Neil White
i think SDL should remain as crossplatorerablility as possible
lots of people running linux may not have gl installed, and on some
systems, low grade intel gfx, it is an ass
i have had systems where a simple 2d game will run like a sak of dogs
doo just cos no gl is installed
lowlevel devices may not have gl capability
but, saying that, the 'just use sdl1.2' is the best and sdl1.3 should
move to reflect modern technologies rather than keep a minority of
users and developers happy,
perhaps even make a sure of distinguishing the difference between
sdl1.2 and sdl1.3 by upon release calling it something else, like sdml
or something, that would also mean less headache when having both new
sdl and old sdl on the same system ( esp linux )
FWIW (and I'm mostly a lurker) since the 1.2 api is so different from
1.3 it seems like a major version number should have been incremented.
SDL 1.3 -> SDL 2.0
Unless that was discussed to death and shot down..
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
From my understanding (I didn't even check the mailing list until long after it was decided to be 1.3); it's supposed to be a middle point between where SDL was and where they want it to be. So it might be more accurate to be called SDL 1.5; but whatever. :P
------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Rainer Deyke
2011-01-21 04:17:55 UTC
Permalink
Post by Mason Wheeler
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Can everyone agree on this?
Just give me a plain frame buffer that works without hardware acceleration.

I don't really care about most of SDL's video functions, accelerated or
non-accelerated. I already have my own 2D renderer built on top of SDL,
with both OpenGL and software rendering paths, that exceeds the
capabilities of the SDL video functions. I'm talking about
functionality such as:
- Matrix-based color transforms.
- Per-pixel lighting, using the alpha channel of the frame buffer to
store lighting information.
- Magnification using the scale2x algorithm.

One of the major uses for SDL is for games that implement their own
software renderer on top of an SDL-provided frame buffer. This includes
ports of old games, new games that don't need hardware acceleration, and
new games that use rendering techniques which cannot be accelerated. It
would be ridiculous if these games required 3D acceleration just to
transfer the result of their software renderer onto the screen.

Don't tell me to use SDL 1.2. SDL has always been about more than just
the graphics subsystem. I'm not going to give up features such as
keyboard scancodes and multiple display support just because I have no
need for SDL's video functions.

Also, systems with no or broken OpenGL support are still common. Many
virtualization systems still have no 3D acceleration or "experimental"
(read "broken") acceleration. VNC servers often don't support hardware
acceleration. Many computers don't have appropriate drivers installed.
Many drivers are buggy.
--
Rainer Deyke - ***@eldwood.com
Torsten Giebl
2011-01-21 04:38:38 UTC
Permalink
Hello !
Post by Rainer Deyke
- Matrix-based color transforms.
- Per-pixel lighting, using the alpha channel of the frame buffer to
store lighting information.
- Magnification using the scale2x algorithm.
Even in oldschool games, there was always a strong wish to be able
to rotate, zoom, to do Mode 7 like effects with hw acceleration.

Instead of having SDL 1.3 rotate and zoom features, i would
like to be able to have "special effects" in a helper library.

As Rainer wrote what about Per Pixel Features.
It was always possible to have them with 2D easily, but what
about 3D ?


CU
Mason Wheeler
2011-01-21 04:49:24 UTC
Permalink
----- Original Message ----
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Hello !
Post by Rainer Deyke
- Matrix-based color transforms.
- Per-pixel lighting, using the alpha channel of the frame buffer to
store lighting information.
- Magnification using the scale2x algorithm.
Even in oldschool games, there was always a strong wish to be able
to rotate, zoom, to do Mode 7 like effects with hw acceleration.
Instead of having SDL 1.3 rotate and zoom features, i would
like to be able to have "special effects" in a helper library.
As Rainer wrote what about Per Pixel Features.
It was always possible to have them with 2D easily, but what
about 3D ?
Per pixel effects are easy to implement on modern, accelerated
platforms with shaders, and there's a lot more you can do with
them. But it would be difficult to implement a SDL_Shader API
if we're shackled to renderers that don't support them.

Here's something you *can't* do easily in 2D, though:

Imagine you wanted to render a rectangular shape as a trapezoid,
for any of a number of reasons. Maybe you want to do scrolling
text in the style of the Star Wars intros, for example. In software,
you have to go through a lot of work to write a special zoomer
routine, and it'll render slowly. In hardware, you just render it
as a quad and put the top two vertices closer together than the
bottom two, and you're done; the GPU takes care of all the
details for you.
Torsten Giebl
2011-01-21 05:00:19 UTC
Permalink
Hello !
Post by Mason Wheeler
Per pixel effects are easy to implement on modern, accelerated
platforms with shaders, and there's a lot more you can do with
them. But it would be difficult to implement a SDL_Shader API
if we're shackled to renderers that don't support them.
Imagine you wanted to render a rectangular shape as a trapezoid,
for any of a number of reasons. Maybe you want to do scrolling
text in the style of the Star Wars intros, for example. In software,
you have to go through a lot of work to write a special zoomer
routine, and it'll render slowly. In hardware, you just render it
as a quad and put the top two vertices closer together than the
bottom two, and you're done; the GPU takes care of all the
details for you.
I agree that a star wars scroller like effect is harder to code in 2D.

My point is, how can an external library use for example
shader effects in combination with SDL 1.3 ?

I don't want to have an API in SDL for zoom, rotate, shader and
everything else you can imagine ?

Is this possible ? I am a newbie to that stuff, but i imagine
that every 3d game today needs more than simple rectangle blitting.


CU
Greg Jandl
2011-01-21 05:30:44 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
Per pixel effects are easy to implement on modern, accelerated
platforms with shaders, and there's a lot more you can do with
them.  But it would be difficult to implement a SDL_Shader API
if we're shackled to renderers that don't support them.
If we're going to start talking shader use, let's not forget that
there's a huge pile of machines out there running GMA950 chipsets -
netbooks are a prime example, but there are scads of 'em out there.
They're a major target for casual to low end mainstream games.

GMA950 supports pixel shaders, but vertex shader programs are all on the CPU.
--
Do what you can, where you are, with what you have. - T. Roosevelt
Rainer Deyke
2011-01-21 06:03:57 UTC
Permalink
Post by Mason Wheeler
Per pixel effects are easy to implement on modern, accelerated
platforms with shaders, and there's a lot more you can do with
them. But it would be difficult to implement a SDL_Shader API
if we're shackled to renderers that don't support them.
Some pixel effects are easy to implement as shaders. Others are more
difficult. Even those that are easy to implement as shaders may not run
on all on computers with hardware acceleration.

In my particular case, I'm not even using shaders. Instead, I'm
generating a composite image by rendering the same polygon with multiple
basis textures combined additively, using different blending modes and
color settings. In theory, my renderer should work even in plain OpenGL
1.0 with no extensions, although I've never tested this.

I've meant to write a shader-based version of my renderer for some time
now, but I haven't gotten around to it yet.
Post by Mason Wheeler
Imagine you wanted to render a rectangular shape as a trapezoid,
for any of a number of reasons. Maybe you want to do scrolling
text in the style of the Star Wars intros, for example. In software,
you have to go through a lot of work to write a special zoomer
routine, and it'll render slowly.
Slower than a plain blit, sure, but not prohibitively slow. Realtime
software 3D renderers are ancient technology, and this effect is a lot
cheaper in software than a full 3D renderer.

On the hand, if you want to map your image to a non-polygonal shape such
as a circle or a spiral, things become a lot more difficult for your
accelerated renderer while staying approximately the same for the
software renderer. For the accelerated renderer, your options are
basically to tessellate the shape into triangles (which is either slow
or ugly, depending on how finely you tessellate) or to use a pixel
shader (which has higher hardware requirements and is potentially slower
than the software renderer).
--
Rainer Deyke - ***@eldwood.com
icsiwtf
2011-01-21 04:33:32 UTC
Permalink
Drop software rendering? I think that's ridiculous.
Jared Maddox
2011-01-21 06:18:54 UTC
Permalink
SDL Digest, Vol 49, Issue 98
Message: 4
Date: Thu, 20 Jan 2011 15:42:37 -0800
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset="iso-8859-1"
I'm not opposed to this, but I'd like to hear lots of people's opinions
before making any changes.
* One of the nice things about this is we can expand the renderer API with
some features like rotation that just aren't possible at speed with software
only solutions.
I say add the functions that really make sense regardless of whether
software rendering is retained, but specify that they may return 'not
implemented' or 'restricted implementation' errors in some cases. This
actually applies to some potential functions even with hardware
rendering (some of the embedded variants of OpenGL apparently don't
require the ability either to render to a texture, or to read a
texture back out of the GPU).
* If we do this, I'd like to standardize on texture formats and renderer
capabilities to simplify people's experience making games.
- What would be the minimum set of supported texture formats?
I'd favor an absolute minimum of a black and white format, a 4-bit
RGBA format, and a 32-bit RGBA format that the hardware can convert to
a lower-quality format. The only reason for the first two is that I
expect that to be trivial to implement ;)

It might be a good idea to declare 32-bit RGBA the 'SDL standard'
format and provide an interface (through SDL_Image? dedicated SDL
register/convert/release functions?) to register converters for
various other formats (whether any converters would be built into the
converter-support code is a completely unrelated matter, of course).
* Does the surface and blit API go away? How do we represent pixel data
that's uploaded to textures? What do we do for SDL 1.2 compatibility?
I think the surfaces themselves should stay (I occasionally toy with
the idea of a widget interface based on them), and surface->texture
should stay. I'm ambivalent about the blit API, since it should be
possible to do that with textures, but perhaps it could simply be
removed to a 'graphics processing' library, so that (for example)
image editor programs can still use it?

For SDL 1.2 compatibility, I'd suggest writing a backend that targets
SDL 1.3. I believe that this should (at least almost) entirely handle
the compatibility issue, while rather nicely separating legacy code
from what we really want to keep. This would also potentially allow
chaining future versions of the library together, so that you could
still run SDL 1.2 programs when SDL has moved to version 3+, without
writing new backends for it...
* I know of several companies relying on the YV12 texture support for video
playback. Right now most of the accelerated back ends do not support YV12
textures.
A software converter (as described above), maybe?
SDL Digest, Vol 49, Issue 99
Message: 6
Date: Thu, 20 Jan 2011 17:14:12 -0800
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset="iso-8859-1"
No, it will be bumped to 2.0 before release. 1.3 is the in-progress
version.
That should make it easier to keep both versions of the library on a
system at the same time, so I assume that Linux distro devs will
appreciate it when release time comes :) .
SDL Digest, Vol 49, Issue 101
Message: 4
Date: Thu, 20 Jan 2011 22:35:18 -0500
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset="iso-8859-1"
I think instead of dropping support directly, it should be put in as a
seperate library, much like SDL_image or SDL_net. I don't know how easy
that would be, but it would offer an easy add-in for new platforms, plus a
compatibility layer for older machines. How feasible is this, and how much
work would it take for it to be completely community maintained (As opposed
to just Sam [and the other devs?]).
I'm not sure that it would help much, because that would require a
backend-api. Such a thing could be useful (imagine the ability to have
a on-screen keyboard library that uses the backend-api to slot between
a program and SDL), but if I were doing the actual SDL coding I know
I'd be hesitant to actually do it. That having been said, I haven't
looked at how complex the code that loads the SDL library is, so it
might be pretty simple. But even then, probably only on certain
platforms.
SDL Digest, Vol 49, Issue 102
Message: 3
Date: Fri, 21 Jan 2011 05:38:38 +0100
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello !
Post by Rainer Deyke
- Matrix-based color transforms.
- Per-pixel lighting, using the alpha channel of the frame buffer to
store lighting information.
- Magnification using the scale2x algorithm.
Even in oldschool games, there was always a strong wish to be able
to rotate, zoom, to do Mode 7 like effects with hw acceleration.
Instead of having SDL 1.3 rotate and zoom features, i would
like to be able to have "special effects" in a helper library.
As Rainer wrote what about Per Pixel Features.
It was always possible to have them with 2D easily, but what
about 3D ?
I believe that the standard answer is 'use OpenGL', but it would be
nice to have a SDL_OpenGL library (or several, one for each OpenGL
version) that would load the necessary function pointers for you.
Sam Lantinga
2011-01-21 08:39:50 UTC
Permalink
I've thought a lot about this, and here's my thoughts...

SDL serves three types of video API users:

1. People who just want a framebuffer and use SDL 1.2 blit and direct pixel
access to do the job.
2. People who just want an OpenGL context, and use OpenGL or OpenGL ES to do
the job.
3. People who want a hardware accelerated 2D API

For #1 and #2, the functionality was available in SDL 1.2 and the feature
set is well understood.

For #3, this is a new area that SDL 1.3 is supporting, and it's really easy
to lose the "Simple" in "Simple DirectMedia Layer"

So I think here is a good time to remember that the goal of the SDL
rendering API is simply to hardware accelerate operations that were
typically done with the SDL 1.2 API.

This is tricky, since people did lots of interesting things with direct
framebuffer access, but let me break it down into a feature set:

copying images
filling rectangles
drawing single pixel lines
drawing single pixel points

SDL 1.2 provided colorkey, alpha channels, and per-surface alpha, as well as
nearest pixel scaling.

Again, to break that down into a feature set:

blending for all operations
single vertex alpha for all operations
single vertex color for all operations
scaling for image copy operations

It's tempting to add functionality here, but that road lies madness.


Right now SDL provides renderers with varying levels of functionality, and
the API user has to query renderers and capabilities and so forth.

Again, in the interest of simplicity, I will be pulling out the partially
functional renderers, and requiring all renderers to be fully functional.

This leaves the following renderers, availability depending on platform:
* software (always available, blasting pixels through the 1.2 interfaces)
* Direct3D
* OpenGL
* OpenGL ES

See ya!
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels. As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Sam Lantinga
2011-01-21 09:34:36 UTC
Permalink
I'm curious, would people rather see the rendering API go away?

Does it increase the complexity of the API without bringing enough
functionality to be useful?
Post by Sam Lantinga
I've thought a lot about this, and here's my thoughts...
1. People who just want a framebuffer and use SDL 1.2 blit and direct pixel
access to do the job.
2. People who just want an OpenGL context, and use OpenGL or OpenGL ES to
do the job.
3. People who want a hardware accelerated 2D API
For #1 and #2, the functionality was available in SDL 1.2 and the feature
set is well understood.
For #3, this is a new area that SDL 1.3 is supporting, and it's really easy
to lose the "Simple" in "Simple DirectMedia Layer"
So I think here is a good time to remember that the goal of the SDL
rendering API is simply to hardware accelerate operations that were
typically done with the SDL 1.2 API.
This is tricky, since people did lots of interesting things with direct
copying images
filling rectangles
drawing single pixel lines
drawing single pixel points
SDL 1.2 provided colorkey, alpha channels, and per-surface alpha, as well
as nearest pixel scaling.
blending for all operations
single vertex alpha for all operations
single vertex color for all operations
scaling for image copy operations
It's tempting to add functionality here, but that road lies madness.
Right now SDL provides renderers with varying levels of functionality, and
the API user has to query renderers and capabilities and so forth.
Again, in the interest of simplicity, I will be pulling out the partially
functional renderers, and requiring all renderers to be fully functional.
* software (always available, blasting pixels through the 1.2 interfaces)
* Direct3D
* OpenGL
* OpenGL ES
See ya!
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels. As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Rainer Deyke
2011-01-21 10:48:07 UTC
Permalink
Post by Sam Lantinga
I'm curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough
functionality to be useful?
I don't need the rendering API, but I can see how other people might
find it useful. Especially when using SDL through slow interpreted
languages like Python where direct frame buffer access is not practicable.

My vote: keep the rendering API, but keep the rendering API simple, and
keep the software renderer.
--
Rainer Deyke - ***@eldwood.com
Vittorio G.
2011-01-21 11:37:45 UTC
Permalink
I wouldn't be against it, instantiating the renderer, choosing the
renderer, destroying the renderer in my opinion only adds complexity
that is not required in a Simple direcmedia libarary.
In my opinion you could leave that in only for advanced use and not
expose it for standard use.

jm2c
Vittorio
Post by Sam Lantinga
I'm curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough
functionality to be useful?
Post by Sam Lantinga
I've thought a lot about this, and here's my thoughts...
1. People who just want a framebuffer and use SDL 1.2 blit and direct
pixel access to do the job.
2. People who just want an OpenGL context, and use OpenGL or OpenGL ES to
do the job.
3. People who want a hardware accelerated 2D API
For #1 and #2, the functionality was available in SDL 1.2 and the feature
set is well understood.
For #3, this is a new area that SDL 1.3 is supporting, and it's really
easy to lose the "Simple" in "Simple DirectMedia Layer"
So I think here is a good time to remember that the goal of the SDL
rendering API is simply to hardware accelerate operations that were
typically done with the SDL 1.2 API.
This is tricky, since people did lots of interesting things with direct
copying images
filling rectangles
drawing single pixel lines
drawing single pixel points
SDL 1.2 provided colorkey, alpha channels, and per-surface alpha, as well
as nearest pixel scaling.
blending for all operations
single vertex alpha for all operations
single vertex color for all operations
scaling for image copy operations
It's tempting to add functionality here, but that road lies madness.
Right now SDL provides renderers with varying levels of functionality, and
the API user has to query renderers and capabilities and so forth.
Again, in the interest of simplicity, I will be pulling out the partially
functional renderers, and requiring all renderers to be fully functional.
* software (always available, blasting pixels through the 1.2 interfaces)
* Direct3D
* OpenGL
* OpenGL ES
See ya!
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels.  As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Mason Wheeler
2011-01-21 13:13:22 UTC
Permalink
I've seen a lot of people reply to this saying "Noooo! You can't add advanced
features! Those aren't simple!" It seems to me that they're confusing "simple"
and "simplistic."

A few definitions here:

Simple: Used as in "simplify." Make things that tend to be difficult easier to
do, so that game programmers can focus on what they're trying to do for their
particular game instead of reinventing wheels. Highly desirable quality.


Simplistic: Minimal, posessed of a small feature set. In other words, a library
that doesn't do much. Highly undesirable quality; will lead to such libraries
being dropped in favor of alternative libraries that *can* do what people want.

And I've gotta agree with Rene's "Do we *still* have buggy drivers?" bit.
People who mention this tend to mention it in conjunction with Linux. Most
Linux distributions have good drivers worked out, and for those that don't, I
really find it difficult to sympathize, especially seeing as how desktop Linux
still maintains less than 1% of market share.

If the Linux community, which is frequently regarded as being quite
above-average when it comes to tech-savviness, can't get their collective rear
in gear and produce decent OpenGL drivers after it's been a standard, expected
feature for MORE THAN TEN YEARS NOW, why is that the 99+% of the rest of our
problem? To base implementation decisions on problems that a small fraction of
a tiny fraction of potential users might maybe have is a textbook case of the
tail wagging the dog, and it's kind of embarrassing to see people talking that
way TBH.

Mason
Gregory Smith
2011-01-21 15:06:17 UTC
Permalink
Post by Mason Wheeler
And I've gotta agree with Rene's "Do we *still* have buggy drivers?" bit.
Anybody here who maintains a 3D game can tell you, of course we do. The
buggy drivers didn't go anywhere. Maybe there are newer versions that
aren't buggy, but that doesn't mean people have them.
Post by Mason Wheeler
People who mention this tend to mention it in conjunction with Linux.
Most Linux distributions have good drivers worked out, and for those
that don't, I really find it difficult to sympathize, especially seeing
as how desktop Linux still maintains less than 1% of market share.
If the Linux community, which is frequently regarded as being quite
above-average when it comes to tech-savviness, can't get their
collective rear in gear and produce decent OpenGL drivers after it's
been a standard, expected feature for MORE THAN TEN YEARS NOW, why is
that the 99+% of the rest of our problem?
Without a Linux port, we (Aleph One) would have missed out on many
contributions from Linux developers. The Linux port and SDL are what led
to the Windows port. End users are important, but they are not the only
important component of free software.
Post by Mason Wheeler
To base implementation decisions on problems that a small fraction of a
tiny fraction of potential users might maybe have is a textbook case of
the tail wagging the dog, and it's kind of embarrassing to see people
talking that way TBH.
I frequently think your replies would benefit from an attempt to see
things from a point of view other than your own. This one irritated me
enough to respond.

Accessibility is one of the characteristics of the free software culture.
Free software is often a refuge for those with unique problems. The fact
that that ideal should color a discussion of SDL's future isn't
embarrassing in the least.

Gregory
Ulrich von Zadow
2011-01-21 13:37:13 UTC
Permalink
In general, I think there is a place for a well-thought-out 2D rendering API.

We won't be using it, though - we're firmly in camp 2 (' just want an OpenGL context, and use OpenGL or OpenGL ES to do the job').

Would it make sense to split the rendering API into a layer above libSDL? That way, only those people who need the functionality need to pull it in.

Cheers,

Uli
Post by Sam Lantinga
I'm curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough functionality to be useful?
--
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: ***@c-base.org
Skype: uzadow
René Dudfield
2011-01-21 13:55:47 UTC
Permalink
Hi,

Currently those layers are SDL_gfx, SDL_image, SDL_mixer, SDL_ttf, etc.

cheers,
Post by Ulrich von Zadow
In general, I think there is a place for a well-thought-out 2D rendering API.
We won't be using it, though - we're firmly in camp 2 (' just want an OpenGL context, and use OpenGL or OpenGL ES to do the job').
Would it make sense to split the rendering API into a layer above libSDL? That way, only those people who need the functionality need to pull it in.
Cheers,
 Uli
Post by Sam Lantinga
I'm curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough functionality to be useful?
--
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Skype: uzadow
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Alex Barry
2011-01-21 14:14:00 UTC
Permalink
From the discussion, I think this is the best option - you can agree or
disagree:

SDL 1.2 is still alive for the many programs that use it to run. It's not
going anywhere. If SDL 1.3 branches off and breaks compatibility, many
linux distributions will still host SDL 1.2 on their repositories, and I'm
sure Sam can leave it on mercurial and people can submit patches if there
are any issue they encounter.

As far as the SDL_surface API goes, it should just be for creating and free
surfaces. The programmer will have to make their own blitting and drawing
routines. This will minimize the footprint that the software renderer
leaves, and the extra work needed to maintain it in the main branch. We
already have SDL_gfx, and the current source for blitting from the 1.2
respository - wouldn't be hard to merge blitting with SDL_gfx.

Thoughts?
-Alex
Hi,
Currently those layers are SDL_gfx, SDL_image, SDL_mixer, SDL_ttf, etc.
cheers,
Post by Ulrich von Zadow
In general, I think there is a place for a well-thought-out 2D rendering
API.
Post by Ulrich von Zadow
We won't be using it, though - we're firmly in camp 2 (' just want an
OpenGL context, and use OpenGL or OpenGL ES to do the job').
Post by Ulrich von Zadow
Would it make sense to split the rendering API into a layer above libSDL?
That way, only those people who need the functionality need to pull it in.
Post by Ulrich von Zadow
Cheers,
Uli
Post by Sam Lantinga
I'm curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough
functionality to be useful?
Post by Ulrich von Zadow
--
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Skype: uzadow
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Alex Barry
2011-01-21 14:14:22 UTC
Permalink
From the discussion, I think this is the best option - you can agree or
disagree:

SDL 1.2 is still alive for the many programs that use it to run. It's not
going anywhere. If SDL 1.3 branches off and breaks compatibility, many
linux distributions will still host SDL 1.2 on their repositories, and I'm
sure Sam can leave it on mercurial and people can submit patches if there
are any issue they encounter.

As far as the SDL_surface API goes, it should just be for creating and free
surfaces. The programmer will have to make their own blitting and drawing
routines. This will minimize the footprint that the software renderer
leaves, and the extra work needed to maintain it in the main branch. We
already have SDL_gfx, and the current source for blitting from the 1.2
respository - wouldn't be hard to merge blitting with SDL_gfx.

Thoughts?
-Alex
Hi,
Currently those layers are SDL_gfx, SDL_image, SDL_mixer, SDL_ttf, etc.
cheers,
Post by Ulrich von Zadow
In general, I think there is a place for a well-thought-out 2D rendering
API.
Post by Ulrich von Zadow
We won't be using it, though - we're firmly in camp 2 (' just want an
OpenGL context, and use OpenGL or OpenGL ES to do the job').
Post by Ulrich von Zadow
Would it make sense to split the rendering API into a layer above libSDL?
That way, only those people who need the functionality need to pull it in.
Post by Ulrich von Zadow
Cheers,
Uli
Post by Sam Lantinga
I'm curious, would people rather see the rendering API go away?
Does it increase the complexity of the API without bringing enough
functionality to be useful?
Post by Ulrich von Zadow
--
Any technology distinguishable from magic is insufficiently advanced.
Ulrich von Zadow | +49-172-7872715
Skype: uzadow
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jonathan Dearborn
2011-01-21 14:30:42 UTC
Permalink
I think Sam is on the right track. We need to look at what features are
necessary for a simple 2D graphics lib and implement those with HW
acceleration. The issue, though, is whether or not we can make it possible
to extend with fanciness. How could one rotate a SDL_Texture without SDL
doing it and without getting renderer-specific? Could I write a
line-drawing function for textures which performs as well as a built-in SDL
one? Can I use a pixel shader without SDL knowing?

Jonny D
Torsten Giebl
2011-01-22 03:56:12 UTC
Permalink
Hello !
Post by Jonathan Dearborn
I think Sam is on the right track. We need to look at what features are
necessary for a simple 2D graphics lib and implement those with HW
acceleration. The issue, though, is whether or not we can make it possible
to extend with fanciness. How could one rotate a SDL_Texture without SDL
doing it and without getting renderer-specific? Could I write a
line-drawing function for textures which performs as well as a built-in SDL
one? Can I use a pixel shader without SDL knowing?
This is exactly my point, how can somebody write an external library like SDL_rotozoom
with software- and hardware render parts.

The first part would be the software renderer :

SW_Rotozoom (....);
HW_OpenGL_Rotozoom (....);
HW_OpenGLES_Rotozoom (....);
HW_D9D_Rotozoom (....);
HW_D10D_Rotozoom (....);

Rotozoom (...);
checks if there is a hw accelerated function for the
actual renderer and if not uses SW_Rotozoom as a fallback.

SDL 1.3 needs a way to do something like this.


CU
René Dudfield
2011-01-21 09:04:15 UTC
Permalink
Hi,

Generally a software renderer is a 'safe' option. Especially with
many buggy 3d drivers on windows, linux, and osx. Please keep it.

Also Rotation is fast enough in software, if used sparingly - or when
you have an 8 core machine :) The SDL_gfx implementation can also be
sped up further with SIMD.

cu.
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing several
advanced features in a performant manner in software, I propose that SDL 1.3
should drop support for non-accelerated backends such as GDI and X11 and focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API backend
to crunch the pixels.  As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like") for
people implementing SDL on new platforms, but it should be made clear that it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Julien CLEMENT
2011-01-21 09:22:19 UTC
Permalink
Hello,

I can't be of any technical help but I can tell from experience
that knowing SDL 1.2 since years (like version 0.7 or so), when
I compared it with other libraries like Allegro, I really felt
in love with SDL for its limited function set, very well designed,
efficient, well documented, easy to compile anywhere.

When I began to get into 1.3, until now, I'm a little bit scared
about it because OpenGL came into the show. You can say, hey dude,
learn a little about how it works and all, but I think not everybody
will use SDL for doing 3D, as Sam said, it is also used for
hardware accelerated 2D.

This means that 2D games still have a long way to go, first, and
second that for platforms not having the appropriate hardware
acceleration there must be an alternative.

A platform not having hardware acceleration does not mean
necessarily an *old* machine, it can also be a Linux with
drivers which are not correctly installed (no direct rendering,
for instance). Sure, the case is rare nowadays, but why
throwing out a code which has been proved for years to be
robust, stable, and well designed ? My point is to keep it.

As a conclusion I want to emphasize the fact that 1.3 should
not become overloaded with fancy functions everywhere, and
that making a 2D game should be as SIMPLE as what it used
to be in 1.2. The idea to create a renderer is, for instance,
already very complicated compared to initializing a screen
with a resolution, bpp and flags, and most people will find
it hard to understand at first (unless RTFM).

Best,

Julien Clément.
Send SDL mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SDL digest..."
1. Re: Proposal: Drop support for software rendering in 1.3
(Sam Lantinga)
2. Re: Proposal: Drop support for software rendering in 1.3
(Nicholas Vining)
3. Re: Proposal: Drop support for software rendering in 1.3
(Damian Paz)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Jan 2011 00:39:50 -0800
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset="iso-8859-1"
I've thought a lot about this, and here's my thoughts...
1. People who just want a framebuffer and use SDL 1.2 blit and direct pixel
access to do the job.
2. People who just want an OpenGL context, and use OpenGL or OpenGL ES to do
the job.
3. People who want a hardware accelerated 2D API
For #1 and #2, the functionality was available in SDL 1.2 and the feature
set is well understood.
For #3, this is a new area that SDL 1.3 is supporting, and it's really easy
to lose the "Simple" in "Simple DirectMedia Layer"
So I think here is a good time to remember that the goal of the SDL
rendering API is simply to hardware accelerate operations that were
typically done with the SDL 1.2 API.
This is tricky, since people did lots of interesting things with direct
copying images
filling rectangles
drawing single pixel lines
drawing single pixel points
SDL 1.2 provided colorkey, alpha channels, and per-surface alpha, as well as
nearest pixel scaling.
blending for all operations
single vertex alpha for all operations
single vertex color for all operations
scaling for image copy operations
It's tempting to add functionality here, but that road lies madness.
Right now SDL provides renderers with varying levels of functionality, and
the API user has to query renderers and capabilities and so forth.
Again, in the interest of simplicity, I will be pulling out the partially
functional renderers, and requiring all renderers to be fully functional.
* software (always available, blasting pixels through the 1.2 interfaces)
* Direct3D
* OpenGL
* OpenGL ES
See ya!
Post by Mason Wheeler
After some discussion on the "Again Rotozoom" thread, I figure I may as
well
Because all platforms that SDL supports have hardware-accelerated video
available as a standard feature, and because this has been true for over a
decade, (7+ Moore cycles,) and because of the difficulty of implementing
several
advanced features in a performant manner in software, I propose that SDL
1.3
should drop support for non-accelerated backends such as GDI and X11 and
focus
on modern, hardware-accelerated APIs such as OpenGl, GLES and Direct3D.
Seb Da Rocha brought up an interesting point: the SDL software renderer is
generic and implemented entirely within SDL instead of relying on an API
backend
to crunch the pixels. As such, it could be retained as a reference
implementation ("this is what correct rendering is supposed to look like")
for
people implementing SDL on new platforms, but it should be made clear that
it's
only for use as a reference implementation and not supposed to be used to
actually build games with.
Can everyone agree on this?
Mason
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/812d2333/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 21 Jan 2011 00:53:53 -0800
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Post by Mason Wheeler
I'm not opposed to this, but I'd like to hear lots of people's
opinions before making any changes.
Count me among the opposed. I'm actually writing my first post on this
mailing list in five years (I think) to weigh in here, so I suppose
that's some measure of my opposition.
The main advantage of SDL, versus its competitors, is that SDL is a
lightweight platform that makes certain guarantees. One of these
guarantees is its software render: any application using the sprite and
blit architecture, written with SDL, is pretty much guaranteed to work.
I can sell more games this way, because SDL's GDI target means that
it'll work on hideously broken Windows XP installs with incorrect
drivers running DirectX 7, and the user will still get a good framerate.
The software renderer also guarantees that a correctly written SDL
application will, with the exception of the odd platform-specific bug,
work on multiple platforms with minimal code changes. My current project
runs just fine on Windows, OS X, and Linux, because in each case it does
the stupidest thing possible on the operating system of choice. As a
result, I can spend more time working on things that matter, and less
time trying to navigate the complicated and hideous web of bugs that
may, possibly, be related to IHV drivers, but which are made all the
more fun by the fact that all your blitting functions - the things that
you're trying to debug - are suddenly hidden in another library. SDL
insulates me from all of that. This is a Good Thing.
Why is it a good thing? Simply put, anybody who thinks that software
rendering does not have its place when trying to sell software in the
year 2011 has obviously never had the experience of shipping a
commercial game to real users. Things are somewhat better if you are
trying to sell to the hard-core PC gamer market, but that consists of
about three people in a basement in Grand Forks. Anybody who wants to
sell game software to the casual market will encounter a wide variety of
machine configurations, ranging from the somewhat normal to the
completely insane.
Here's an example: imagine, for a moment, your grandmother. Now imagine
that your grandmother wants to play your spiffy new Solitare clone. Now
imagine what is involved in telling your grandmother how to install a
new set of video drivers on her aging computer, over the phone. For
bonus points, get her to install an updated DirectX redistributable
runtime as well. I would much rather that my Solitare clone - which
doesn't need hardware accelerated rendering in the first place - uses
GDI and is done with it.
So, yes, software rendering still has a place in the world. As a further
example of that, I would point out that RAD Game Tools is still selling
Pixomatic, a ridiculously hand-optimized DirectX 7/DirectX 9 drop in
software renderer, as their solution for dealing with just this kind of
hideously broken computer. One company I know, who will not be named,
ships a product with Direct3D, OpenGL and Pixomatic rendering targets.
To their surprise, and mild horror, Pixomatic *beats* the other two
"hardware-accelerated" render targets in terms of performance on many of
their users' machine, mainly because their users are running things like
Intel Extreme 2 Integrated Graphics Accelerators, with drivers from
2001, on clapped out Dell Inspirons. You know what? These people deserve
to be able to use and buy our software too. Let them have their software
renderer.
That said, there may be a case for getting rid of a lot of the software
rendering pipeline in SDL. I would be fine, for instance, if SDL 1.3
just gave me a framebuffer and told me to fill it. Radically
streamlining the software rendering pipeline in this fashion so that
other parts of SDL 1.3 can be finished might be a good trade-off. We
could also get rid of a bunch of things, like line drawing functions,
that don't really meet the "Simple" criterion of the Simple DirectMedia
Layer.
In my mind, it is not acceptable for us to get rid of the software
renderer in exchange for a bunch of fancy, bejewelled gewgaws like
"hardware accelerated rotational blitting", whatever the heck that is.
If you want to have a game with rotating sprites, you have two sane
choices.
1. Use OpenGL (or Direct3D), and do the math yourself, in the
application, to calculate the rotated position of the four points of the
sprite. Draw a textured quad spanning those points. The math is very
simple, consisting of a 2x2 matrix rotation, and has been known since
the 17th century. It is also very easy to set OpenGL up with an
orthographic projection.
2. Do the math to calculate the rotated position of the four points of
the sprite, and then write your own texture blitter. The math is still
very simple, and you can still find an accurate depiction of the texture
mapping process in sources such as Michael Abrash's Graphics Programming
Black Book, which is still available online.
Forcing SDL to carry these burdens for you is not a sane choice, nor is
providing a thin layer of access, in a cross-platform manner, to OS
level multimedia facilities. I must confess, I'm already puzzled as to
why we have things like line drawing functions in SDL 1.3. Bresenham's
line algorithm is a fun, easy programming exercise that programmers of
all ages and skill levels can enjoy, and I don't think that it's fair to
deprive people of this pleasure.
I would encourage anybody who thinks that they have a good idea for SDL
to strongly consider what the feature they propose adds, and at what
cost. Feature creep is a very, very good way to kill projects.
Signing out for another five years,
N.
--
Nicholas Vining
Lead Programmer, Gaslamp Games
Dungeons of Dredmor, Coming in April 2011: http://www.gaslampgames.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/c9dc882b/attachment-0001.htm>
------------------------------
Message: 3
Date: Fri, 21 Jan 2011 00:59:51 -0800 (PST)
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset="us-ascii"
To be honest I've never thought about using SDL to write a game for a 386 SXL. I
just wanna have a cross platform API that will allow me to create an OpenGL
context to do something that is worth watching at with ease, having event
handling and sound management is just a bonus for me.
________________________________
Sent: Fri, January 21, 2011 5:53:53 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
I'm not opposed to this, but I'd like to hear lots of people's opinions
before making any changes.
Count me among the opposed. I'm actually writing my first post on this
mailing list in five years (I think) to weigh in here, so I suppose that's
some measure of my opposition.
The main advantage of SDL, versus its competitors, is that SDL is a
lightweight platform that makes certain guarantees. One of these guarantees
is its software render: any application using the sprite and blit
architecture, written with SDL, is pretty much guaranteed to work. I can
sell more games this way, because SDL's GDI target means that it'll work on
hideously broken Windows XP installs with incorrect drivers running DirectX
7, and the user will still get a good framerate. The software renderer also
guarantees that a correctly written SDL application will, with the exception
of the odd platform-specific bug, work on multiple platforms with minimal
code changes. My current project runs just fine on Windows, OS X, and Linux,
because in each case it does the stupidest thing possible on the operating
system of choice. As a result, I can spend more time working on things that
matter, and less time trying to navigate the complicated and hideous web of
bugs that may, possibly, be related to IHV drivers, but which are made all
the more fun by the fact that all your blitting functions - the things that
you're trying to debug - are suddenly hidden in another library. SDL
insulates me from all of that. This is a Good Thing.
Why is it a good thing? Simply put, anybody who thinks that software
rendering does not have its place when trying to sell software in the year
2011 has obviously never had the experience of shipping a commercial game to
real users. Things are somewhat better if you are trying to sell to the
hard-core PC gamer market, but that consists of about three people in a
basement in Grand Forks. Anybody who wants to sell game software to the
casual market will encounter a wide variety of machine configurations,
ranging from the somewhat normal to the completely insane.
Here's an example: imagine, for a moment, your grandmother. Now imagine that
your grandmother wants to play your spiffy new Solitare clone. Now imagine
what is involved in telling your grandmother how to install a new set of
video drivers on her aging computer, over the phone. For bonus points, get
her to install an updated DirectX redistributable runtime as well. I would
much rather that my Solitare clone - which doesn't need hardware accelerated
rendering in the first place - uses GDI and is done with it.
So, yes, software rendering still has a place in the world. As a further
example of that, I would point out that RAD Game Tools is still selling
Pixomatic, a ridiculously hand-optimized DirectX 7/DirectX 9 drop in
software renderer, as their solution for dealing with just this kind of
hideously broken computer. One company I know, who will not be named, ships
a product with Direct3D, OpenGL and Pixomatic rendering targets. To their
surprise, and mild horror, Pixomatic *beats* the other two
"hardware-accelerated" render targets in terms of performance on many of
their users' machine, mainly because their users are running things like
Intel Extreme 2 Integrated Graphics Accelerators, with drivers from 2001, on
clapped out Dell Inspirons. You know what? These people deserve to be able
to use and buy our software too. Let them have their software renderer.
That said, there may be a case for getting rid of a lot of the software
rendering pipeline in SDL. I would be fine, for instance, if SDL 1.3 just
gave me a framebuffer and told me to fill it. Radically streamlining the
software rendering pipeline in this fashion so that other parts of SDL 1.3
can be finished might be a good trade-off. We could also get rid of a bunch
of things, like line drawing functions, that don't really meet the "Simple"
criterion of the Simple DirectMedia Layer.
In my mind, it is not acceptable for us to get rid of the software renderer
in exchange for a bunch of fancy, bejewelled gewgaws like "hardware
accelerated rotational blitting", whatever the heck that is. If you want to
have a game with rotating sprites, you have two sane choices.
1. Use OpenGL (or Direct3D), and do the math yourself, in the application,
to calculate the rotated position of the four points of the sprite. Draw a
textured quad spanning those points. The math is very simple, consisting of
a 2x2 matrix rotation, and has been known since the 17th century. It is also
very easy to set OpenGL up with an orthographic projection.
2. Do the math to calculate the rotated position of the four points of the
sprite, and then write your own texture blitter. The math is still very
simple, and you can still find an accurate depiction of the texture mapping
process in sources such as Michael Abrash's Graphics Programming Black Book,
which is still available online.
Forcing SDL to carry these burdens for you is not a sane choice, nor is it a
choice that is compatible with the library's designated purpose: providing a
thin layer of access, in a cross-platform manner, to OS level multimedia
facilities. I must confess, I'm already puzzled as to why we have things
like line drawing functions in SDL 1.3. Bresenham's line algorithm is a fun,
easy programming exercise that programmers of all ages and skill levels can
enjoy, and I don't think that it's fair to deprive people of this pleasure.
I would encourage anybody who thinks that they have a good idea for SDL to
strongly consider what the feature they propose adds, and at what cost.
Feature creep is a very, very good way to kill projects.
Signing out for another five years,
N.
--
Nicholas Vining
Lead Programmer, Gaslamp Games
Dungeons of Dredmor, Coming in April 2011: http://www.gaslampgames.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/a25a6427/attachment.htm>
------------------------------
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
End of SDL Digest, Vol 49, Issue 105
************************************
Julien CLEMENT
***@yahoo.fr
Neil White
2011-01-21 10:02:41 UTC
Permalink
rename to

smcdl

slightly more complicated direct media layer

;) classic linux naming
Damian Paz
2011-01-21 10:08:25 UTC
Permalink
What's "direct" about this library after all?



________________________________
From: Neil White <***@cloudsprinter.com>
To: SDL Development List <***@lists.libsdl.org>
Sent: Fri, January 21, 2011 7:02:41 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3


rename to

smcdl

slightly more complicated direct media layer

;) classic linux naming
Jcw87
2011-01-21 10:53:29 UTC
Permalink
I think that it is important to add some newer features, such as clipping and render-to-texture. I had to start learning OpenGL because these things were missing from the render API. At the same time, it is also important to have a fallback renderer, in case a hardware accelerated renderer could not be created for whatever reason. I think it would be best to keep the software renderer, adding new features to it as needed, even if they turn out to be really slow.
PoV
2011-01-21 11:13:51 UTC
Permalink
I'm for.
Post by Nathaniel J Fries
SDL 1.2 is stable enough for most purposes, and SDL 1.3 is so vastly different that anybody using it isn't using it to get SDL 1.2's features.
I ran in to compatibility issues with 1.2 crashing on the latest slim Macbook Air's, so I ported my code over 1.3 just to fix the crash. I use SDL as an OpenGL host though, so back-compat isn't necessary.
Post by Nathaniel J Fries
lots of people running linux may not have gl installed, and on some systems, low grade intel gfx, it is an ass
I'm actually quite happy with Intel's low end GMA graphics chipsets (945/950). I've been doing a bunch of work for them, targeting Netbooks and whatnot, and found them to be a surprisingly reliable Fixed Function OpenGL card. Not to mention, cheap -- Full computers for merely $200!? I'd expect the Cube/Wii's Fixed function guts to be far featured filled, but for straightforward T&L they get the job done. Keep your textures under 2MB, and they fly.

My dated dual core Intel Mac Mini with a GMA 945 drives my game on a 1920x1200 monitor with ease, and using only 10% of the CPU (in a release build). Netbooks with Intel Atom's work fine but take more of a CPU hit (since they have less gusto than the core2), but it's still a full computer with screen, memory and storage for just 2 bills. Sorry for thinking about my wallet, but if a customer isn't willing to throw down 2 bills for a capable computer made in the past 6 years, they're not a customer.

These next few years are about to get really wild, with Windows coming to ARM, and x86/ARM targeted Linux projects like Meego gaining speed. Oh, and all those mobile devices. Give Grandma a new hand-me-down if she can't run your game.

It's 2011 -- Everything has a GPU.
Post by Nathaniel J Fries
It's tempting to add functionality here, but that road lies madness.
Indeed. I stopped using Allegro several years ago, and refused to get involved in the mystical 5.0 rewrite because it tries to be too much. Allegro had one of the best software renderers, and for the longest time preferred it over SDL due to the raw performance I could get. Now that I don't care about CPU blitters, I'm after something to make me little boxes I can draw GPU accelerated pretty pictures on, and I speak GPU.
Post by Nathaniel J Fries
Generally a software renderer is a 'safe' option. Especially with many buggy 3d drivers on windows, linux, and osx. Please keep it.
Hi. Do we still have buggy drivers? All the latest Linux distros ship with updated drivers from the big 3, and Ubuntu grabs the latest once you let it. And the "Linux buying" community are usually people that keep their distros recent (otherwise, would you have the confidence to buy something)? OSX, buggy drivers only stick around for a few weeks max, since Apple auto-updates actually work right. Windows, can anyone remember the last time a video driver problem wasn't some obscure feature only used the latest and greatest nextgen-graphics PC FPS of the year... a ridiculous cycle that seemed to finally end with Crysis I might add.

------------------------
| Mike Kasprzak | Sykhronics Entertainment (http://www.sykhronics.com) | Blog (http://www.toonormal.com) | Twitter (http://www.twitter.com/mikekasprzak) |
René Dudfield
2011-01-21 11:37:20 UTC
Permalink
Generally a software renderer is a 'safe' option. Especially with many
buggy 3d drivers on windows, linux, and osx. Please keep it.
Hi. Do we still have buggy drivers? All the latest Linux distros ship with
updated drivers from the big 3, and Ubuntu grabs the latest once you let it.
And the "Linux buying" community are usually people that keep their distros
recent (otherwise, would you have the confidence to buy something)? OSX,
buggy drivers only stick around for a few weeks max, since Apple
auto-updates actually work right. Windows, can anyone remember the last time
a video driver problem wasn't some obscure feature only used the latest and
greatest nextgen-graphics PC FPS of the year... a ridiculous cycle that
seemed to finally end with Crysis I might add.
hi,

yeah, of course we still have buggy drivers. That is a hardware driver
constant. Even on OSX with very modern hardware I found many different bugs
in my opengl coding. You should see the amount of effort going into the web
browsers that are trying to get hardware acceleration for a fairly minimal
feature set.

I know you probably don't care about software - but other people have
different priorities. For me, the software renderer is the main feature of
SDL. I still run into people who choose to use pygame because GPU based
Engine X does not work on their computer.

By the way, SDL in 2D mode is often the fastest way to get video displayed.
Especially on PC where 50% of windows users still use XP (and around 25/25
vista/7). So for these applications where you don't do blending - SDL 1.2
is optimal.

Also avoiding 3D hardware has nice battery benefits on some laptops.

Those are the arguments for keeping software... but of course I like the 3d
hardware rendering API :) Also on many configurations using the 3D apis
makes the most sense :)


For a hardware API, scaling and rotation would be nice - and I think
expected for a modern 2D API. Also various blend modes are expected. All
of these can and are being done in software already.

cheers!
Rainer Deyke
2011-01-21 20:40:48 UTC
Permalink
Post by Jcw87
I think that it is important to add some newer features, such as
clipping and render-to-texture. I had to start learning OpenGL
because these things were missing from the render API. At the same
time, it is also important to have a fallback renderer, in case a
hardware accelerated renderer could not be created for whatever
reason. I think it would be best to keep the software renderer,
adding new features to it as needed, even if they turn out to be
really slow.
There is never going to be a general consensus as to which features are
necessary for a 2D rendering API. You can keep adding features, all of
them useful features that somebody need, and soon you've exposed the
whole OpenGL API.

I'm strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL's main purpose is to act as a cross-platform compatibility layer.
Let's not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
--
Rainer Deyke - ***@eldwood.com
Mason Wheeler
2011-01-21 21:13:13 UTC
Permalink
----- Original Message ----
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
I'm strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL's main purpose is to act as a cross-platform compatibility layer.
Let's not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
Jonathan Dearborn
2011-01-21 21:16:35 UTC
Permalink
They could be exposed... Then these features could be lifted to an
additional library instead of bothering everyone who feels affected.

Jonny D
Post by Mason Wheeler
----- Original Message ----
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
I'm strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL's main purpose is to act as a cross-platform compatibility layer.
Let's not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Rainer Deyke
2011-01-21 21:43:54 UTC
Permalink
Post by Mason Wheeler
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL's 2D
rendering API.

The situation you're describing is exactly why it's a bad idea to add
too many features to SDL's 2D rendering API. SDL's 2D rendering API is
not extensible. Therefore, if you're doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL's 2D rendering API can only delay this
transition, thereby making the transition all the more painful.

The only API that exposes the full power of OpenGL is OpenGL itself.
--
Rainer Deyke - ***@eldwood.com
Shawn Walker
2011-01-22 06:37:09 UTC
Permalink
Post by Rainer Deyke
Post by Mason Wheeler
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL's 2D
rendering API.
The situation you're describing is exactly why it's a bad idea to add
too many features to SDL's 2D rendering API. SDL's 2D rendering API is
not extensible. Therefore, if you're doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL's 2D rendering API can only delay this
transition, thereby making the transition all the more painful.
The only API that exposes the full power of OpenGL is OpenGL itself.
But, as many others have pointed out, there are a number of not insignificant platforms that have poor or no OpenGL support, even in this "modern era".

My personal belief is that there is significant value in SDL retaining a software-only rendering backend for now, and in the sort of functionality SDL 1.3 is attempting to provide.

-Shawn
Alex Barry
2011-01-22 18:00:57 UTC
Permalink
Making software/hardware support as a compiler flag seems convenient from a
developer standpoint, but is completely impractical from an end-user
perspective. Think, for instance, you are developing software for Mac OS X
(10.6), and are distributing binaries - if the binary is build against
hardware support but the users' SDL library is build without hardware
support, there could be some linking issues. I don't know for sure if
that's true, but it would be something that should be taken into account.

-Oz
Post by Shawn Walker
Post by Rainer Deyke
Post by Mason Wheeler
Sure, except there's one little problem with that: it won't work, at
least
Post by Rainer Deyke
Post by Mason Wheeler
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection
away
Post by Rainer Deyke
Post by Mason Wheeler
from the data you would need to implement any new image manipulation
or rendering features externally.
The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL's 2D
rendering API.
The situation you're describing is exactly why it's a bad idea to add
too many features to SDL's 2D rendering API. SDL's 2D rendering API is
not extensible. Therefore, if you're doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL's 2D rendering API can only delay this
transition, thereby making the transition all the more painful.
The only API that exposes the full power of OpenGL is OpenGL itself.
But, as many others have pointed out, there are a number of not
insignificant platforms that have poor or no OpenGL support, even in this
"modern era".
My personal belief is that there is significant value in SDL retaining a
software-only rendering backend for now, and in the sort of functionality
SDL 1.3 is attempting to provide.
-Shawn
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Rainer Deyke
2011-01-22 22:46:06 UTC
Permalink
Post by Alex Barry
Making software/hardware support as a compiler flag seems convenient from a
developer standpoint, but is completely impractical from an end-user
perspective. Think, for instance, you are developing software for Mac OS X
(10.6), and are distributing binaries - if the binary is build against
hardware support but the users' SDL library is build without hardware
support, there could be some linking issues. I don't know for sure if
that's true, but it would be something that should be taken into account.
Usually you would distribute your own copy of SDL along with your
application, at least on OS X and Windows.

That said, I am also opposed to the idea of making the software renderer
optional. The software renderer is small, and it's always useful to
have a working fallback in case hardware rendering fails.
--
Rainer Deyke - ***@eldwood.com
PoV
2011-01-21 13:04:32 UTC
Permalink
Post by René Dudfield
Also avoiding 3D hardware has nice battery benefits on some laptops.
I'm not sure this point is particularly true anymore (since CPU work tends to be harder on the CPU than GPU work in on a GPU, like how if you're not using SIMD its performance that just goes to waste), but I will definitely concede that having a way to display a purely software framebuffer isn't a bad thing. Specific draw operations though, especially if unaccelerated, I do wonder if they belong at the SDL level.

Admittedly, I've not looked at the actual code being nominated for chopping. But when I recently ported from 1.2 to 1.3, I did have a "why are there all these unaccelerated blendy function here?" moment.

------------------------
| Mike Kasprzak | Sykhronics Entertainment (http://www.sykhronics.com) | Blog (http://www.toonormal.com) | Twitter (http://www.twitter.com/mikekasprzak) |
Nathaniel J Fries
2011-01-21 14:50:00 UTC
Permalink
After reading I've come to a conclusion that should make everyone happy.

Just add these features, even if they're slow on the software renderer.

The people who use the software renderer now won't use these features, anyway.
The software renderer will make it easy to see "how it should look" if you're implementing your own rendering backend.
It can be useful (and maybe optimized -- if each software rendering operation had a surface-level implementation too, a programmer can intelligently craft a method to use the features so that it doesn't kill performance).

That's what it seems from what I've read.

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Paulo Pinto
2011-01-21 15:24:36 UTC
Permalink
If we happen to keep software rendering around, maybe some more effort could
be spent using processor
vector extensions to accelerate it more then.

Please excuse me if this is already being done, it is been a while since I
look into SDL source code.

--
Paulo
Post by Nathaniel J Fries
After reading I've come to a conclusion that should make everyone happy.
Just add these features, even if they're slow on the software renderer.
The people who use the software renderer now won't use these features, anyway.
The software renderer will make it easy to see "how it should look" if
you're implementing your own rendering backend.
It can be useful (and maybe optimized -- if each software rendering
operation had a surface-level implementation too, a programmer can
intelligently craft a method to use the features so that it doesn't kill
performance).
That's what it seems from what I've read.
------------------------------
EM3 Nathaniel Fries, U.S. Navy
http://natefries.net/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
René Dudfield
2011-01-21 18:01:31 UTC
Permalink
Hi,

Yes, SDL uses vector SIMD instructions for a few platforms already.

There are not multi core blitters in SDL core. There are some that
have been written for SDL in separate libraries though. Multi core
vector operations can speed things up towards memory bandwidth.
Things like MKL support transparent multi core operation - and are
often used in scientific computing. SDL on a modern desktop
machine(2008+) can easily do video 1920x1080x32bit at 60fps in
software with plenty of cpu left over.

cu,
Post by Paulo Pinto
If we happen to keep software rendering around, maybe some more effort could
be spent using processor
vector extensions to accelerate it more then.
Please excuse me if this is already being done, it is been a while since I
look into SDL source code.
--
Paulo
Post by Nathaniel J Fries
After reading I've come to a conclusion that should make everyone happy.
Just add these features, even if they're slow on the software renderer.
The people who use the software renderer now won't use these features, anyway.
The software renderer will make it easy to see "how it should look" if
you're implementing your own rendering backend.
It can be useful (and maybe optimized -- if each software rendering
operation had a surface-level implementation too, a programmer can
intelligently craft a method to use the features so that it doesn't kill
performance).
That's what it seems from what I've read.
________________________________
EM3 Nathaniel Fries, U.S. Navy
http://natefries.net/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jonathan Dearborn
2011-01-21 19:13:37 UTC
Permalink
I don't know about MKL or its portability, but OpenMP is pretty easy to
integrate on its own anyhow.

Jonny D
Post by René Dudfield
Hi,
Yes, SDL uses vector SIMD instructions for a few platforms already.
There are not multi core blitters in SDL core. There are some that
have been written for SDL in separate libraries though. Multi core
vector operations can speed things up towards memory bandwidth.
Things like MKL support transparent multi core operation - and are
often used in scientific computing. SDL on a modern desktop
machine(2008+) can easily do video 1920x1080x32bit at 60fps in
software with plenty of cpu left over.
cu,
Post by Paulo Pinto
If we happen to keep software rendering around, maybe some more effort
could
Post by Paulo Pinto
be spent using processor
vector extensions to accelerate it more then.
Please excuse me if this is already being done, it is been a while since
I
Post by Paulo Pinto
look into SDL source code.
--
Paulo
Post by Nathaniel J Fries
After reading I've come to a conclusion that should make everyone happy.
Just add these features, even if they're slow on the software renderer.
The people who use the software renderer now won't use these features, anyway.
The software renderer will make it easy to see "how it should look" if
you're implementing your own rendering backend.
It can be useful (and maybe optimized -- if each software rendering
operation had a surface-level implementation too, a programmer can
intelligently craft a method to use the features so that it doesn't kill
performance).
That's what it seems from what I've read.
________________________________
EM3 Nathaniel Fries, U.S. Navy
http://natefries.net/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Marcus von Appen
2011-01-21 19:22:34 UTC
Permalink
Post by René Dudfield
Hi,
Yes, SDL uses vector SIMD instructions for a few platforms already.
There are not multi core blitters in SDL core. There are some that
have been written for SDL in separate libraries though. Multi core
vector operations can speed things up towards memory bandwidth.
Things like MKL support transparent multi core operation - and are
often used in scientific computing. SDL on a modern desktop
machine(2008+) can easily do video 1920x1080x32bit at 60fps in
software with plenty of cpu left over.
On a side note we also have made a good experience with using
multiprocessing and multiprocessor extensions for software rendering
(blits, pixel copies, blending) within pygame (using OpenMP).

Best
Marcus
BenoitRen
2011-01-21 16:34:06 UTC
Permalink
Post by Damian Paz
To be honest I've never thought about using SDL to write a game for a 386 SXL.
I see someone has a problem with reading comprehension. It's as if you haven't done anything more than skimming the message you replied to. This kind of ignorance is infuriating.
BenoitRen
2011-01-21 16:56:52 UTC
Permalink
If anyone is still doubting that Linux has crappy graphics drivers, I invite them to read this Slashdot thread (http://news.slashdot.org/story/11/01/16/0657240/Why-Linux-Loses-Out-On-Hardware-Acceleration-In-Firefox) (and maybe the article). In short:
nVidia's closed-source drivers rock

ATI's open-source drivers suck

developers that have expertise with 3D graphics drivers are few so most 3D graphics drivers for Linux are buggy and not well maintained
Torsten Giebl
2011-01-22 04:44:11 UTC
Permalink
Hello !
Post by BenoitRen
If anyone is still doubting that Linux has crappy graphics drivers,
I invite them to read this Slashdot thread
(http://news.slashdot.org/story/11/01/16/0657240/Why-Linux-Loses-Out-On-Hardware-Acceleration-In-Firefox)
nVidia's closed-source drivers rock
ATI's open-source drivers suck
developers that have expertise with 3D graphics drivers are few so
most 3D graphics drivers for Linux are buggy and not well maintained
I know it is offtopic for this discussion, but personally think
that there are important reasons for that :

1. Look on the kernel.org mailinglist, most of the people
there that do kernel work, are hired by companies, that
are interested in servers. Their interest lies in filesystems,
better network performance, better kernel scheduling and basically
everything else without sound and grafix.

If linux on a server is able to get a basic 2d framebuffer up,
the server company is happy.

2. There are only three major gfx card producers out there,
ATI / AMD, NVIDIA and Intel. Intel helps in making the open source
drivers better for their gfx chips, but they are designed for low energy
use cases and for real hardcore 3d games basically suck.

3. Nvidia is not willing to release infos about their gfx cards, to enable
coders to write good open source drivers for their cards.

4. ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.


CU
Shawn Walker
2011-01-22 06:33:50 UTC
Permalink
Post by Torsten Giebl
4. ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.
That's simply not true. ATi / AMD has released thousands of pages of specifications, microcode for almost all Radeon GPUs, tens of thousands of lines of sample source code, and more.

The reality is that writing drivers is hard work, and writing accelerated 2D/3D drivers is even harder.

It's not something that the casual hacker can accomplish quickly, and it takes years of dedication, specialized knowledge, and (realistically) significant financial sponsorship.

-Shawn
ICH1994
2011-01-21 15:27:30 UTC
Permalink
Ahhh..
I wanted a clear answer but how i see Sam doesnt know it too.
Nathaniel J Fries
2011-01-21 21:35:03 UTC
Permalink
Post by Mason Wheeler
----- Original Message ----
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
I'm strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL's main purpose is to act as a cross-platform compatibility layer.
Let's not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
I am in agreement here. If they were to be moved to a separate library, SDL as it is would need to be restructured to expose these things; and then there'd probably still be a ton of code duplication and such in the new library anyway. It makes sense to put it into SDL if it's something like this; even if it won't be used by everyone who uses SDL. The library could be reliably modularized much easier than opaque structures can be readily exposed and reliably modified in a cross-platform manner.

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
michelleC
2011-01-21 21:49:00 UTC
Permalink
i t
but, saying that, the 'just use sdl1.2' is the best and sdl1.3 should move to reflect modern technologies rather than keep a minority of users and developers happy,
perhaps even make a sure of distinguishing the difference between sdl1.2 and sdl1.3 by upon release calling it something else, like sdml or something, that would also mean less headache when having both new sdl and old sdl on the same system ( esp linux )
I will make this short and sweet because I think this is a bad suggestion.

1) We do advanced video processing on mobile devices and set-top boxes. (Do you really call that legacy)

2) We use yuv12 rendering , many of these platfroms use open gl es 1.0 which does not support yuv12, sdl is meant to be a cross platform compatibility layer sometimes that is true others times it falls short of that , however it is very good at bridging the gap between legacy pre open gl linux platforms, newer windows and mac platforms and iphones , android and set-top boxes. We use it to great extent in those later areas.

3) aside from the yuv12 rendering capabilities we utilize many advanced open gl capabilities. For those of you who have attempted to use rotozoom on the iphone platform you know that it pails in comparison to open gl code.

4) SDL 1.2 DOES NOT meet our needs

I strongly vote no on any such proposal.
ICH1994
2011-01-21 22:24:12 UTC
Permalink
Why dont make a extra lib for the Hardwareaccelerated Stuff? -> Everyone is happy.

Thos Guys who wnat that just add the lib those who dont just use only SDL
michelleC
2011-01-21 22:32:58 UTC
Permalink
No everyone would not be happy.

more libs causes additional resource allocation that many embedded systems can't afford.

Do you know for instance your typical Android app has about 100 mb of usable memory space available to it.
Post by ICH1994
Why dont make a extra lib for the Hardwareaccelerated Stuff? -> Everyone is happy.
Thos Guys who wnat that just add the lib those who dont just use only SDL
Ulrich von Zadow
2011-01-22 00:01:46 UTC
Permalink
Sorry, I don't understand.

Splitting the library would allow users to install only those parts they need, which would cause less memory usage for the majority of users. In contrast, loading two libraries instead of one library (that contains both libraries' code) should make almost no difference at all in memory consumption. Probably none at all if we are talking about static libraries.

Regards,

Uli
Post by michelleC
No everyone would not be happy.
more libs causes additional resource allocation that many embedded systems can't afford.
Do you know for instance your typical Android app has about 100 mb of usable memory space available to it.
Why dont make a extra lib for the Hardwareaccelerated Stuff? -> Everyone is happy.
Thos Guys who wnat that just add the lib those who dont just use only SDL
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: ***@c-base.org
Skype: uzadow
Nathaniel J Fries
2011-01-22 01:37:41 UTC
Permalink
Post by Ulrich von Zadow
Sorry, I don't understand.
Splitting the library would allow users to install only those parts they need, which would cause less memory usage for the majority of users. In contrast, loading two libraries instead of one library (that contains both libraries' code) should make almost no difference at all in memory consumption. Probably none at all if we are talking about static libraries.
You are correct; but even more effective would be to require certain macros to be defined when compiling the library to use that feature of the library.
For example, SDL_BUILD_DISPLAY would be required to build windows and displays, SDL_BUILD_OPENGL would be required to build GL context support, SDL_BUILD_SOFTWARE_RENDERER would be required to build the software renderer, and SDL_BUILD_*_RENDERER would be required to build a specific rendering backend (IE, D3D or GL or GLES).

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Ken Rogoway
2011-01-22 02:00:55 UTC
Permalink
Is the size of SDL really that big a deal on most platforms? At least for
Windows, Mac, Linux, iPhone and Android the size of the SDL library (or DLL)
is insignificant compared to the application and its data.



I realize that on some other less popular or embedded platforms the size may
matter, but what percentage of SDL use is targeted for those platforms? I'd
hate to see a LOT of rework and restructuring happen to SDL to cater to a
couple of platforms that aren't that popular. That being said, if there was
a way to handle this by defining or undefining certain macros, that seems
like a good solution that should work for everyone.



Ken



From: sdl-***@lists.libsdl.org [mailto:sdl-***@lists.libsdl.org] On
Behalf Of Nathaniel J Fries
Sent: Friday, January 21, 2011 7:38 PM
To: ***@lists.libsdl.org
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3






Ulrich von Zadow wrote:







Sorry, I don't understand.


Splitting the library would allow users to install only those parts they
need, which would cause less memory usage for the majority of users. In
contrast, loading two libraries instead of one library (that contains both
libraries' code) should make almost no difference at all in memory
consumption. Probably none at all if we are talking about static libraries.






You are correct; but even more effective would be to require certain macros
to be defined when compiling the library to use that feature of the library.
For example, SDL_BUILD_DISPLAY would be required to build windows and
displays, SDL_BUILD_OPENGL would be required to build GL context support,
SDL_BUILD_SOFTWARE_RENDERER would be required to build the software
renderer, and SDL_BUILD_*_RENDERER would be required to build a specific
rendering backend (IE, D3D or GL or GLES).



_____


EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Jared Maddox
2011-01-22 06:18:10 UTC
Permalink
SDL Digest, Vol 49, Issue 113
Message: 1
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
There is never going to be a general consensus as to which features are
necessary for a 2D rendering API. You can keep adding features, all of
them useful features that somebody need, and soon you've exposed the
whole OpenGL API.
I'm strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL's main purpose is to act as a cross-platform compatibility layer.
Let's not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
Message: 2
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
Message: 3
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
They could be exposed... Then these features could be lifted to an
additional library instead of bothering everyone who feels affected.
Yes, this can be done. I've done something somewhat similar in SDLCP,
with the thread class's native_handle() function. The trick is that it
can't be done in a completely hardware-independant way. You design the
api something like this:

SDL_TextureBacking
{
Uint32 type;
};
SDL_TextureBacking* SDL_CreateBacking( SDL_Texture* );
void SDL_FreeBacking( SDL_TextureBacking* );

In the real word you won't ever recieve an actual SDL_TextureBacking
instance, instead you'll recieve a pointer to a SDL_TextureBacking
that's embedded inside another, larger structure, in OO-style C. The
value of ->type actually identifies this larger structure, so that the
code calling these two functions can figure out if it can handle that
particular structure type, and if so make the appropriate cast(s). If
it can't, then it releases the structure and returns an error message
of some sort. The actual structure that you recieve will, however, be
very platform-specific, which raises the question: is it worthwhile to
do this?
Nathaniel J Fries
2011-01-22 06:45:01 UTC
Permalink
Post by Jared Maddox
Yes, this can be done. I've done something somewhat similar in SDLCP,
with the thread class's native_handle() function. The trick is that it
can't be done in a completely hardware-independant way. You design the
SDL_TextureBacking
{
Uint32 type;
};
SDL_TextureBacking* SDL_CreateBacking( SDL_Texture* );
void SDL_FreeBacking( SDL_TextureBacking* );
In the real word you won't ever recieve an actual SDL_TextureBacking
instance, instead you'll recieve a pointer to a SDL_TextureBacking
that's embedded inside another, larger structure, in OO-style C. The
value of ->type actually identifies this larger structure, so that the
code calling these two functions can figure out if it can handle that
particular structure type, and if so make the appropriate cast(s). If
it can't, then it releases the structure and returns an error message
of some sort. The actual structure that you recieve will, however, be
very platform-specific, which raises the question: is it worthwhile to
do this?
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
What *could* be done is to make a vertex rendering function:

Code:

int SDL_RenderCopyVertices(SDL_Texture* texture, SDL_Point* srcpts, SDL_Point* dstpts, int count);



that will take care of *some* of the features desired (SDL_RenderCopy could literally just be a translation to this) and can be done easily with at least D3D and OGL.
it can just return on error "Not supported" on rendering backends that don't support it.

Render targets is more complicated. They became core in OpenGL 3 and I believe they've always been a part of Direct3D9; they're easily done in software and IIRC GDI can do it as well.
But if SDL can't get an OpenGL 3.x context, it'll need to emulate it in software (or maybe through a mix of SDL_UpdateTexture and software?).

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Julien CLEMENT
2011-01-22 11:05:35 UTC
Permalink
Yes, I agree to make it a compilation option. Why not
have something like a configure option --enable-hwaccel
or --enable-swrenderer (with at least one of the enabled).
SW renderer could also be always compiled, and triggered
in case HW acceleration cannot be performed for some reason,
so that the rendering is done anyway, but with warnings
logged somewhere.

Of course it overloads the configuration and compilation
process but at the end the user is happy to have a
fine tuned SDL library instead of a big packet of things
which may never be used (so less memory used, more clarity).

I'm also aware it means more work in the side of the SDL
developers !

Julien Clément.
Send SDL mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of SDL digest..."
1. Re: problem with SDL_SetGammaRamp on SDL 1.2.14 on Windows
(Nathaniel J Fries)
2. Re: Build errors in Visual Studio 2008 Professional
(Nathaniel J Fries)
3. Re: Proposal: Drop support for software rendering in 1.3
(Torsten Giebl)
4. Re: [1.2+OGL]-"LettersFall 3" Game-Please Help Test On (Ananth A)
5. Re: Proposal: Drop support for software rendering in 1.3
(Jared Maddox)
6. [off-topic] was Re: Proposal: Drop support for software
rendering in 1.3 (Shawn Walker)
7. Re: Proposal: Drop support for software rendering in 1.3
(Shawn Walker)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Jan 2011 20:29:38 -0800
Subject: Re: [SDL] problem with SDL_SetGammaRamp on SDL 1.2.14 on
Windows
Content-Type: text/plain; charset="iso-8859-1"
the issue with the HG repository is known, and Sam has contacted someone to fix it.
Try the snapshot from the site's download page instead. It's probably the exact same code.
as for the actual SDL bug; that is a mystery to me.
------------------------
EM3 Nathaniel Fries, U.S. Navy
http://natefries.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/78da77bc/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 21 Jan 2011 20:31:59 -0800
Subject: Re: [SDL] Build errors in Visual Studio 2008 Professional
Content-Type: text/plain; charset="iso-8859-1"
those errors are concerning, and unfortunely I don't use MSVC and thus can't help.
However, I can tell you that SDL 1.3 uses a very different API from SDL1.2 and all SDL 1.2 compatibility functions are in SDL_compat.h instead of their normal headers.
See if that doesn't fix most of your non-totally-bizarre errors.
------------------------
EM3 Nathaniel Fries, U.S. Navy
http://natefries.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/74a05c75/attachment-0001.htm>
------------------------------
Message: 3
Date: Sat, 22 Jan 2011 05:44:11 +0100
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello !
Post by BenoitRen
If anyone is still doubting that Linux has crappy graphics drivers,
I invite them to read this Slashdot thread
(http://news.slashdot.org/story/11/01/16/0657240/Why-Linux-Loses-Out-On-Hardware-Acceleration-In-Firefox)
nVidia's closed-source drivers rock
ATI's open-source drivers suck
developers that have expertise with 3D graphics drivers are few so
most 3D graphics drivers for Linux are buggy and not well maintained
I know it is offtopic for this discussion, but personally think
1. Look on the kernel.org mailinglist, most of the people
there that do kernel work, are hired by companies, that
are interested in servers. Their interest lies in filesystems,
better network performance, better kernel scheduling and basically
everything else without sound and grafix.
If linux on a server is able to get a basic 2d framebuffer up,
the server company is happy.
2. There are only three major gfx card producers out there,
ATI / AMD, NVIDIA and Intel. Intel helps in making the open source
drivers better for their gfx chips, but they are designed for low energy
use cases and for real hardcore 3d games basically suck.
3. Nvidia is not willing to release infos about their gfx cards, to enable
coders to write good open source drivers for their cards.
4. ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.
CU
------------------------------
Message: 4
Date: Fri, 21 Jan 2011 23:49:07 -0500
Subject: Re: [SDL] [1.2+OGL]-"LettersFall 3" Game-Please Help Test On
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I tried your game under win7 64bit. Unfortunately, i was not able to
play the game. the arrow keys (left/right/down) did nothing. I have a
usb keyboard. Also, the next character just randomly flickers and cant
read anything.....
also, in the how to play, you have written help for "down arrow" twice.
Good luck.
Regards,
Ananth
Post by BenoitRen
Hi,
I added new high score name input!
This will be the last alpha version before the officially released beta...
Please download and help test it!
The people on the list/IRC that already helped
now have their name in the game's [About] staff credits!!!
Linux 32bit/64bit
http://16bitsoft.com/files/LF3/SOURCE/lettersfall-src_alpha2.98.zip
Microsoft(R) Windows(R) XP/Vista/7 32bit/64Bit
http://16bitsoft.com/files/LF3/Win32-64/LF3-Win32_Alpha2.98.zip
PS- Anyone wish to port this to Apple's iOS (iPhone/iPod Touch/iPad) ???
(let me know - I would share generously any profits on the Apple App Store)
------------------------
JeZ+Lee
16BitSoft(R)
Video Game Design Studio
www.16BitSoft.com
------------------------------
Message: 5
Date: Sat, 22 Jan 2011 00:18:10 -0600
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset=ISO-8859-1
Post by BenoitRen
SDL Digest, Vol 49, Issue 113
Message: 1
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
There is never going to be a general consensus as to which features are
necessary for a 2D rendering API. You can keep adding features, all of
them useful features that somebody need, and soon you've exposed the
whole OpenGL API.
I'm strongly in favor of keeping the rendering API minimal, and writing
more sophisticated rendering APIs as a separate layer on top of SDL.
SDL's main purpose is to act as a cross-platform compatibility layer.
Let's not confuse this purpose by adding features that could easily be
implemented in a platform-independent manner on top of SDL.
Message: 2
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
Message: 3
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
They could be exposed... Then these features could be lifted to an
additional library instead of bothering everyone who feels affected.
Yes, this can be done. I've done something somewhat similar in SDLCP,
with the thread class's native_handle() function. The trick is that it
can't be done in a completely hardware-independant way. You design the
SDL_TextureBacking
{
Uint32 type;
};
SDL_TextureBacking* SDL_CreateBacking( SDL_Texture* );
void SDL_FreeBacking( SDL_TextureBacking* );
In the real word you won't ever recieve an actual SDL_TextureBacking
instance, instead you'll recieve a pointer to a SDL_TextureBacking
that's embedded inside another, larger structure, in OO-style C. The
value of ->type actually identifies this larger structure, so that the
code calling these two functions can figure out if it can handle that
particular structure type, and if so make the appropriate cast(s). If
it can't, then it releases the structure and returns an error message
of some sort. The actual structure that you recieve will, however, be
very platform-specific, which raises the question: is it worthwhile to
do this?
------------------------------
Message: 6
Date: Fri, 21 Jan 2011 22:33:50 -0800
Subject: [SDL] [off-topic] was Re: Proposal: Drop support for software
rendering in 1.3
Content-Type: text/plain; charset=us-ascii
Post by BenoitRen
4. ATI / AMD has released some information about some cards, but maybe not enough
to really get a complete driver going for their cards.
That's simply not true. ATi / AMD has released thousands of pages of specifications, microcode for almost all Radeon GPUs, tens of thousands of lines of sample source code, and more.
The reality is that writing drivers is hard work, and writing accelerated 2D/3D drivers is even harder.
It's not something that the casual hacker can accomplish quickly, and it takes years of dedication, specialized knowledge, and (realistically) significant financial sponsorship.
-Shawn
------------------------------
Message: 7
Date: Fri, 21 Jan 2011 22:37:09 -0800
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Content-Type: text/plain; charset=us-ascii
Post by BenoitRen
Post by Mason Wheeler
Sure, except there's one little problem with that: it won't work, at least
not the way SDL 1.3 is currently architected. SDL_Textures are opaque
pointers to platform-independent structs containing opaque pointers
to platform-specific structs. That's two missing levels of indirection away
from the data you would need to implement any new image manipulation
or rendering features externally.
The renderer would of course be implemented on top of OpenGL (or the
frame buffer interface for software rendering), not on top of SDL's 2D
rendering API.
The situation you're describing is exactly why it's a bad idea to add
too many features to SDL's 2D rendering API. SDL's 2D rendering API is
not extensible. Therefore, if you're doing any sophisticated rendering,
you will eventually be forced to drop the 2D rendering API and switch to
OpenGL. Adding features to SDL's 2D rendering API can only delay this
transition, thereby making the transition all the more painful.
The only API that exposes the full power of OpenGL is OpenGL itself.
But, as many others have pointed out, there are a number of not insignificant platforms that have poor or no OpenGL support, even in this "modern era".
My personal belief is that there is significant value in SDL retaining a software-only rendering backend for now, and in the sort of functionality SDL 1.3 is attempting to provide.
-Shawn
------------------------------
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
End of SDL Digest, Vol 49, Issue 117
************************************
Julien CLEMENT
***@yahoo.fr
ICH1994
2011-01-22 17:09:37 UTC
Permalink
[quote="Julien CLEMENT"]Yes, I agree to make it a compilation option. Why not
have something like a configure option --enable-hwaccel
or --enable-swrenderer (with at least one of the enabled).
SW renderer could also be always compiled, and triggered
in case HW acceleration cannot be performed for some reason,
so that the rendering is done anyway, but with warnings
logged somewhere.

Of course it overloads the configuration and compilation
process but at the end the user is happy to have a
fine tuned SDL library instead of a big packet of things
which may never be used (so less memory used, more clarity).

I'm also aware it means more work in the side of the SDL
developers !

Julien Clément.

Le 22 janv. 2011 à 07:47, sdl-***@lists.libsdl.org a écrit :

[\quote]

( y )
Eric Wing
2011-01-24 01:04:54 UTC
Permalink
Post by ICH1994
[quote="Julien CLEMENT"]Yes, I agree to make it a compilation option. Why not
have something like a configure option --enable-hwaccel
or --enable-swrenderer (with at least one of the enabled).
SW renderer could also be always compiled, and triggered
in case HW acceleration cannot be performed for some reason,
so that the rendering is done anyway, but with warnings
logged somewhere.
Of course it overloads the configuration and compilation
process but at the end the user is happy to have a
fine tuned SDL library instead of a big packet of things
which may never be used (so less memory used, more clarity).
I'm also aware it means more work in the side of the SDL
developers !
Julien Clément.
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.

Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.

Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.


- Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Will Langford
2011-01-24 04:16:23 UTC
Permalink
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
- Eric
I agree.

For the love of God, do NOT start splintering SDL into different
library-compile-time-build versionings. This will fragment the hell out of
things. If you think dependency hell with "1.2.9 vs 1.2.13" can be a big
deal... just wait until everyone and their uncle builds an SDL library with
what they think are preferred options.

If someone distributes game X with custom built libsdl using custom compile
flags.... and if that libsdl doesn't work on my system... what do I do then
? I can't necessarily just delete it and my system wide libsdl can do its
thing. Recompiling a libsdl to match the custom one is also going to be
guess work.

Keep it SIMPLE guys.

-Will
pk
2011-01-24 04:24:38 UTC
Permalink
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...

If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?

Best regards

Peter K
Eric Wing
2011-01-24 07:00:13 UTC
Permalink
Post by pk
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Post by pk
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Post by pk
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...
If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?
Best regards
Peter K
Because I've been with SDL for almost a decade now. I have contributed
code, implemented/maintained a build system, written documentation,
and done binary distributions. If somebody reports a crash using my
packages and/or on my platforms, there is a chance I might be the one
debugging the SDL code.

-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Ken Rogoway
2011-01-24 07:15:11 UTC
Permalink
The *only* reason to continue supporting software rendering IMHO, is as a
fallback on machines that don't support the hardware rendering. This was a
great reason to use SDL in years past because a LOT of casual game players
have older machines (the typical casual gamer is 50+ and female).

My vote is to keep software rendering as a fallback, or as a runtime
selectable option. If this is a big maintenance issue with SDL 1.3, then I
would understand doing away with it. I can always use SDL 1.2.x if I am
targeting older machines.

Ken

-----Original Message-----
From: sdl-***@lists.libsdl.org [mailto:sdl-***@lists.libsdl.org] On
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
To: ***@min-epost.net; SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Post by pk
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Post by pk
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Post by pk
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...
If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?
Best regards
Peter K
Because I've been with SDL for almost a decade now. I have contributed
code, implemented/maintained a build system, written documentation,
and done binary distributions. If somebody reports a crash using my
packages and/or on my platforms, there is a chance I might be the one
debugging the SDL code.

-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Alex Barry
2011-01-24 13:52:18 UTC
Permalink
So, is the official majority consensus is to keep the software renderer?
Like people have suggested, if you're porting to a memory limited embedded
system, people are able to get the source and preprocessor/comment undesired
code out, or just use SDL 1.2 (which will still be maintained, especially
with SDL 1.3's API changes).
It would be nice to look at what (reasonable) optimization options we do
have for the software renderer; my experience has been that the software
renderer has been fast, but if there are options for (automatic?) multi-core
software rendering, that may be a good place to start.

As far as the software/hardware rendering is concerned, because in the past,
people have tried to use the SDL_HWACCEL flag - if there is a away to reuse
that, that will be good for compatibility (is that even considered
compatible?)

The other option, as Ken is suggesting (if there be no other alternative),
is to get rid of software rendering support in SDL 1.3, and if people want
to create programs with software support, SDL 1.2 is quite stable and will
still be available.

-Oz
Post by Ken Rogoway
The *only* reason to continue supporting software rendering IMHO, is as a
fallback on machines that don't support the hardware rendering. This was a
great reason to use SDL in years past because a LOT of casual game players
have older machines (the typical casual gamer is 50+ and female).
My vote is to keep software rendering as a fallback, or as a runtime
selectable option. If this is a big maintenance issue with SDL 1.3, then I
would understand doing away with it. I can always use SDL 1.2.x if I am
targeting older machines.
Ken
-----Original Message-----
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Post by pk
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Post by pk
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Post by pk
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...
If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?
Best regards
Peter K
Because I've been with SDL for almost a decade now. I have contributed
code, implemented/maintained a build system, written documentation,
and done binary distributions. If somebody reports a crash using my
packages and/or on my platforms, there is a chance I might be the one
debugging the SDL code.
-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Jeff Post
2011-01-24 14:48:16 UTC
Permalink
Post by Alex Barry
The other option, as Ken is suggesting (if there be no other alternative),
is to get rid of software rendering support in SDL 1.3, and if people want
to create programs with software support, SDL 1.2 is quite stable and will
still be available.
Except that 1.2 lacks support for multiple windows. Any chance that might be
added to 1.2 at some time? A work around is to spawn child processes to do
additional windows, but it would be better if we could do it without multiple
processes.

Jeff
Sam Lantinga
2011-01-24 19:15:53 UTC
Permalink
Yep, we're keeping the software renderer. :)
Post by Alex Barry
So, is the official majority consensus is to keep the software renderer?
Like people have suggested, if you're porting to a memory limited embedded
system, people are able to get the source and preprocessor/comment undesired
code out, or just use SDL 1.2 (which will still be maintained, especially
with SDL 1.3's API changes).
It would be nice to look at what (reasonable) optimization options we do
have for the software renderer; my experience has been that the software
renderer has been fast, but if there are options for (automatic?) multi-core
software rendering, that may be a good place to start.
As far as the software/hardware rendering is concerned, because in the
past, people have tried to use the SDL_HWACCEL flag - if there is a away to
reuse that, that will be good for compatibility (is that even considered
compatible?)
The other option, as Ken is suggesting (if there be no other alternative),
is to get rid of software rendering support in SDL 1.3, and if people want
to create programs with software support, SDL 1.2 is quite stable and will
still be available.
-Oz
Post by Ken Rogoway
The *only* reason to continue supporting software rendering IMHO, is as a
fallback on machines that don't support the hardware rendering. This was a
great reason to use SDL in years past because a LOT of casual game players
have older machines (the typical casual gamer is 50+ and female).
My vote is to keep software rendering as a fallback, or as a runtime
selectable option. If this is a big maintenance issue with SDL 1.3, then I
would understand doing away with it. I can always use SDL 1.2.x if I am
targeting older machines.
Ken
-----Original Message-----
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Post by pk
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Post by pk
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Post by pk
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...
If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?
Best regards
Peter K
Because I've been with SDL for almost a decade now. I have contributed
code, implemented/maintained a build system, written documentation,
and done binary distributions. If somebody reports a crash using my
packages and/or on my platforms, there is a chance I might be the one
debugging the SDL code.
-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Mason Wheeler
2011-01-24 19:24:21 UTC
Permalink
I probably should have named this differently when I started the thread. In my
original post I pointed out that there's a good reason to keep the software
renderer. What I wanted to drop was the software-based (non-accelerated)
system-specific rendering backends such as X11 and GDI, and I think most people
here can agree that *that* is a good idea, right?

Mason




________________________________
From: Sam Lantinga <***@libsdl.org>
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

Yep, we're keeping the software renderer. :)


On Mon, Jan 24, 2011 at 5:52 AM, Alex Barry <***@gmail.com> wrote:

So, is the official majority consensus is to keep the software renderer? Like
people have suggested, if you're porting to a memory limited embedded system,
people are able to get the source and preprocessor/comment undesired code out,
or just use SDL 1.2 (which will still be maintained, especially with SDL 1.3's
API changes).
It would be nice to look at what (reasonable) optimization options we do have
for the software renderer; my experience has been that the software renderer has
been fast, but if there are options for (automatic?) multi-core software
rendering, that may be a good place to start.
As far as the software/hardware rendering is concerned, because in the past,
people have tried to use the SDL_HWACCEL flag - if there is a away to reuse
that, that will be good for compatibility (is that even considered compatible?)
The other option, as Ken is suggesting (if there be no other alternative), is to
get rid of software rendering support in SDL 1.3, and if people want to create
programs with software support, SDL 1.2 is quite stable and will still be
available.
-Oz
The *only* reason to continue supporting software rendering IMHO, is as a
Post by Ken Rogoway
fallback on machines that don't support the hardware rendering. This was a
great reason to use SDL in years past because a LOT of casual game players
have older machines (the typical casual gamer is 50+ and female).
My vote is to keep software rendering as a fallback, or as a runtime
selectable option. If this is a big maintenance issue with SDL 1.3, then I
would understand doing away with it. I can always use SDL 1.2.x if I am
targeting older machines.
Ken
-----Original Message-----
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Post by pk
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Post by pk
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Post by pk
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...
If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?
Best regards
Peter K
Because I've been with SDL for almost a decade now. I have contributed
code, implemented/maintained a build system, written documentation,
and done binary distributions. If somebody reports a crash using my
packages and/or on my platforms, there is a chance I might be the one
debugging the SDL code.
-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Sam Lantinga
2011-01-24 21:11:46 UTC
Permalink
Yep. :)
Post by Mason Wheeler
I probably should have named this differently when I started the thread.
In my original post I pointed out that there's a good reason to keep the
software renderer. What I wanted to drop was the software-based
(non-accelerated) system-specific rendering backends such as X11 and GDI,
and I think most people here can agree that *that* is a good idea, right?
Mason
------------------------------
**
*Subject:* Re: [SDL] Proposal: Drop support for software rendering in 1.3
Yep, we're keeping the software renderer. :)
Post by Alex Barry
So, is the official majority consensus is to keep the software renderer?
Like people have suggested, if you're porting to a memory limited embedded
system, people are able to get the source and preprocessor/comment undesired
code out, or just use SDL 1.2 (which will still be maintained, especially
with SDL 1.3's API changes).
It would be nice to look at what (reasonable) optimization options we do
have for the software renderer; my experience has been that the software
renderer has been fast, but if there are options for (automatic?) multi-core
software rendering, that may be a good place to start.
As far as the software/hardware rendering is concerned, because in the
past, people have tried to use the SDL_HWACCEL flag - if there is a away to
reuse that, that will be good for compatibility (is that even considered
compatible?)
The other option, as Ken is suggesting (if there be no other alternative),
is to get rid of software rendering support in SDL 1.3, and if people want
to create programs with software support, SDL 1.2 is quite stable and will
still be available.
-Oz
Post by Ken Rogoway
The *only* reason to continue supporting software rendering IMHO, is as a
fallback on machines that don't support the hardware rendering. This was a
great reason to use SDL in years past because a LOT of casual game players
have older machines (the typical casual gamer is 50+ and female).
My vote is to keep software rendering as a fallback, or as a runtime
selectable option. If this is a big maintenance issue with SDL 1.3, then I
would understand doing away with it. I can always use SDL 1.2.x if I am
targeting older machines.
Ken
-----Original Message-----
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Post by pk
Post by Eric Wing
Speaking from a package maintainer and distribution stand point,
compile time switches suck. Please don't do this.
I assume you are responsible for a binary distro... then I wonder how
would a compile time switch be a problem? I assume you are enabling
everything... For a source "distro" like Gentoo it's fine or even
preferable to do it this way.
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Post by pk
Post by Eric Wing
Speaking from a documentation writer stand point, this sucks too.
Barely anybody reads the documentation as it is. This will be a
terrible gotcha.
Does being a documentation writer suck because barely anybody reads it
or how should I interpret what you say?
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Post by pk
Post by Eric Wing
Speaking from a Q/A standpoint, this sucks for similar reasons as
documentation. For diagnosis, we now have to have more knowledge about
how SDL was specifically compiled. Most users won't tell us and will
be confused when asked.
QA sucks, period. Or rather, binary distro QA suck generally just
because they enable/compile in "kitchen&sink" (more code means more
potential bugs)...
If you are a binary distro maintainer why would you support user
compiled code (unless the problem lies in a distro supplied library)?
Best regards
Peter K
Because I've been with SDL for almost a decade now. I have contributed
code, implemented/maintained a build system, written documentation,
and done binary distributions. If somebody reports a crash using my
packages and/or on my platforms, there is a chance I might be the one
debugging the SDL code.
-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Rainer Deyke
2011-01-24 22:25:54 UTC
Permalink
Post by Mason Wheeler
I probably should have named this differently when I started the thread. In my
original post I pointed out that there's a good reason to keep the software
renderer. What I wanted to drop was the software-based (non-accelerated)
system-specific rendering backends such as X11 and GDI, and I think most people
here can agree that *that* is a good idea, right?
Absolutely not. Like I said, I don't care about renderers so long as I
can get a simple frame buffer. I do care about getting that simple
frame buffer even on computers with no hardware acceleration, because
computers with no hardware acceleration or broken hardware acceleration
are still common.
--
Rainer Deyke - ***@eldwood.com
Mason Wheeler
2011-01-24 22:38:07 UTC
Permalink
No such computer has been sold since the 90s on any platform that SDL
supports. Seems to me you've got a *very* odd definition of "common".
How many people are still running on 90s-era video cards today?
----- Original Message ----
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
Post by Mason Wheeler
I probably should have named this differently when I started the thread. In my
original post I pointed out that there's a good reason to keep the software
renderer. What I wanted to drop was the software-based (non-accelerated)
system-specific rendering backends such as X11 and GDI, and I think most people
here can agree that *that* is a good idea, right?
Absolutely not. Like I said, I don't care about renderers so long as I
can get a simple frame buffer. I do care about getting that simple
frame buffer even on computers with no hardware acceleration, because
computers with no hardware acceleration or broken hardware acceleration
are still common.
pk
2011-01-24 19:09:51 UTC
Permalink
Post by Eric Wing
The argument for a compile time switch means somebody must make a hard
decision about whether they want a software or hardware renderer. That
means a package maintainer may be placed in the uncomfortable position
of making a decision. And everybody using the package depends on the
maintainer doing the 'right' thing. I've been around long enough and
seen enough show-stopping bugs that break a huge portion of the user
base. And changing something will break the rest of the user base.
(And I have seen enough graphic driver specific bugs that I know there
is a high likely hood this will become a problem if not multiple
times. And supporting two separate binaries is also painful.)
Hm... from what I understood there were proposed only two switches one
for enabling hardware rendering and one for software. I assumed as a
(binary) package maintainer you would enable both (and I also assume
since both are enabled that software would be triggered if hardware
support isn't available). Would that be unreasonable?
Post by Eric Wing
The problem is that with every nuance you add to documentation, you
overwhelm readers with too much information they won't remember what
they read. But more likely, they won't read long documentation at all.
The trick is to keep things simple and straightforward. Then readers
will actually pay attention to the (few) really important things you
do need to tell them. Compiler switches usually fall under the
information overload category.
Hm... oh well, ok. There's always the lowest common denominator I guess...

Best regards

Peter K
Nathaniel J Fries
2011-01-22 18:28:49 UTC
Permalink
Making software/hardware support as a compiler flag seems convenient from a developer standpoint, but is completely impractical from an end-user perspective.  Think, for instance, you are developing software for Mac OS X (10.6), and are distributing binaries - if the binary is build against hardware support but the users' SDL library is build without hardware support, there could be some linking issues.  I don't know for sure if that's true, but it would be something that should be taken into account.
Only if the user's binary is compiled without flags that yours is compiled with; which is highly unlikely and realistically unless you're statically linking to SDL (or using it on Android) you should use a fully-featured build. This is especially true for any non-embedded system; you shouldn't bother. The only real reason to do it is to decrease the disk size and memory use for the code (which a stripped (-s) SDL 1.3 on Windows compiles to roughly 900kb anyway; so it won't have THAT much of an effect on any system).

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Eric Wing
2011-01-24 00:01:51 UTC
Permalink
Just another angle on the issue which comes from SDL 1.2.

There is this flag, SDL_HWSURFACE that has become an anachronism that
newbies keep insisting on using thinking it will give them more
performance while in fact that it now does quite the opposite.

So 10 years from now, will we find that the current hardware renderers
are obsolete and useless while the software renderer becomes the most
reliable and fastest implementation?

-Eric
Gabriele Greco
2011-01-24 14:18:18 UTC
Permalink
Just telling my opinion.

I'm a SDL developer since 1997 and in the past I've been the author of three
different SDL ports (AmigaOS, MorphOS, AROS).

In the past years I've used it with success also in some commercial game
ports (Linux/OSX) that I wrote for RuneSoft (Robin Hood, Ankh, Ankh2, Jack
Keane).

I've brought also SDL to the company where I actually work, here we do
mostly video survelliance stuff, and our video players, and multiviewer (a
box that gets N IP video inputs and show them simultaneously in a large
video wall) all use SDL apis.

I think the SDL software renderer it's quite important for new platforms
support (there are some niche operating systems that have some software just
because thanks to SDL they can run doom, tuxpaint, and other great SDL based
free sofware).

It's quite common to find linux boxes with not working opengl configuration.
The most common problem with RuneSoft games in linux were about hardware
acceleration not present at all because of 2d only drivers, or graphics card
too old to be accelerated with current drivers (this is the problem with old
NVIDIA/ATI chipsets that have a decent GPU power but are not accelerated by
the recent proprietary drivers, this problem in future will be worse). Many
OSX boxes that do not came from apple (osx86) do not have hardware
acceleration at all.

Many programmers use SDL also as a fast framebuffer to try graphics effect
done at pixel level in small prototypes, no other toolkit is as fast as SDL
for this kind of work, and the D of SDL is for "direct" as many already
pointed :)

Since SDL can be found almost everywhere, almost every video decoding
framework use SDL as target of his output example, *SDL_YV12* and the
overlay API are really needed, both in hardware accelerated/software mode.

In 3/5 years after the release of SDL 2.0, 1.2 will disappear from linux
distro, and in "major" SDL ports, a few of them that use direct access will
have to switch to other toolkits...

So I vote NO to remove the software renderer from SDL, but I think there is
room to improve the Renderer APIs, with rotation functions and a texture to
texture blit function for instance. With software fallback if the operations
cannot be done by HW...
--
Ing. Gabriele Greco, DARTS Engineering
Tel: +39-0105761240 Fax: +39-0105760224
s-mail: Via G.T. Invrea 14 - 16129 GENOVA (ITALY)
Nathaniel J Fries
2011-01-24 03:56:03 UTC
Permalink
I also have a proposal to improve performance of SDL's software renderer on systems with multiple cores.
Simply; just make a dedicated blitter thread per processor. If you can't get the number of processors, the system doesn't support multiple threads (IE, Minix3), or it's single core; rely on the current method.
The threads will be started by SDL_CreateRenderer or the first call to SDL_SetVideoMode, and receive blit requests from a thread-safe queue. SDL_Flip and SDL_RenderPresent will wait on worker threads to finish (use a semaphore).
You'll need to implement a regional/rectangular lock on the screen surface, but that's not terribly difficult to implement... just check for an intersection of the destination rectangle against all "locked rectangles" stored in a resizable array or linked list. I should be able to do this for Windows and POSIX if you guys think it'll be too hard for yourselves, but I am a bit strapped on time recently.
In addition these worker threads could perform rotations and stretches, keeping the main thread free to continue sending requests.

What do you think?

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Nathaniel J Fries
2011-01-24 04:23:01 UTC
Permalink
Post by Jonathan Dearborn
I agree.
For the love of God, do NOT start splintering SDL into different library-compile-time-build versionings.  This will fragment the hell out of things.  If you think dependency hell with "1.2.9 vs 1.2.13" can be a big deal... just wait until everyone and their uncle builds an SDL library with what they think are preferred options.
If someone distributes game X with custom built libsdl using custom compile flags.... and if that libsdl doesn't work on my system... what do I do then ?  I can't necessarily just delete it and my system wide libsdl can do its thing.  Recompiling a libsdl to match the custom one is also going to be guess work.
Keep it SIMPLE guys.
-Will 
Perhaps instead, modularize SDL itself into several smaller libraries? SFML does something like this.
For example, SDL_core (SDL's standard c subset), SDL_system (threads, OS version, CPU features; depends on SDL_core), SDL_surface (SDL_Surface-based structures; depends on SDL_core and SDL_system for fast blitting), SDL_windows (SDL_CreateWindow*, SDL_Event), SDL_render (SDL_CreateRenderer, etc; this CAN be safely fragmented as was suggested before, since the public API is still the same)

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Will Langford
2011-01-24 04:49:11 UTC
Permalink
Post by Nathaniel J Fries
Perhaps instead, modularize SDL itself into several smaller libraries? SFML
does something like this.
For example, SDL_core (SDL's standard c subset), SDL_system (threads, OS
version, CPU features; depends on SDL_core), SDL_surface (SDL_Surface-based
structures; depends on SDL_core and SDL_system for fast blitting),
SDL_windows (SDL_CreateWindow*, SDL_Event), SDL_render (SDL_CreateRenderer,
etc; this CAN be safely fragmented as was suggested before, since the public
API is still the same)
I've... followed this and the accompanying thread a little.

What I don't understand is the desire to try to optimize away the outter
wrapper of these different SDL calls.

This would be akin to:

FlipScreen1()
{
memcpy();
}

FlipScreen2()
{
hardware_flip();
}

FlipScreen3()
{
depants_your_neighbor();
}

FlipScreen()
{
choose which 1/2/3 to call and do it
}

.... Optimizing FlipScreen() to instead be hard wired into 1/2/3() doesn't
improve much.

Similarly, for those who argue about space / foot print --- on typical
computers you have got to be joking. A MB or 2 of total space taken up in
the world of terabyte drives and GB's of memory ? And if you're in the
embedded world and truly concerned about this stuff, you'd just comment /
preprocessor the unwanted stuff out manually anyway.

I truly think a library compile time option to enable / disable software
renderer is a mistake and leads down a dangerous path.

In regards to splitting SDL up into smaller codependent libraries....
I'm.... somewhat against that as well. I really do like the *S* part of SDL
:). I just honestly think it's not the way to go. I can understand and
respect the desire to do that, I just don't agree.

-----

As far as removal of the software renderer... I'm almost inclined to agree
with the use '1.2' mentality. I'm all about 'the lowest common
denominator', and it is probably nearing time that the 2D engine is about
dead. Microsoft abstracted ddraw through d3d how long ago ? Anyhoo, that's
my worthless $0.02 thrown into the pot :)

-Will
Ken Rogoway
2011-01-24 06:15:12 UTC
Permalink
Somehow this thread (Drop support for software rendering in 1.3) has
digressed into multiple topics. All pertain to different ideas on
restructuring SDL, but they do not pertain specifically to the thread topic.



If people want to discuss splitting up SDL, or building different flavors
using compiler flags then those should probably be started as different
topics.



That being said, I'd like to add that BEFORE we worry about any type of
restructure of SDL 1.3 (graphic or otherwise), wouldn't it be a good idea to
get a stable release out? SDL 1.3 is very much still a beta, and on almost
a daily basis there are commits that break the build for one platform or
another.



This doesn't mean we cannot discuss topics like restructuring, but I'd like
to see a stable release before any of those ideas comes to fruition.



Ken



From: sdl-***@lists.libsdl.org [mailto:sdl-***@lists.libsdl.org] On
Behalf Of Will Langford
Sent: Sunday, January 23, 2011 10:49 PM
To: ***@lists.libsdl.org
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3





On Sun, Jan 23, 2011 at 10:23 PM, Nathaniel J Fries <***@yahoo.com>
wrote:



Perhaps instead, modularize SDL itself into several smaller libraries? SFML
does something like this.
For example, SDL_core (SDL's standard c subset), SDL_system (threads, OS
version, CPU features; depends on SDL_core), SDL_surface (SDL_Surface-based
structures; depends on SDL_core and SDL_system for fast blitting),
SDL_windows (SDL_CreateWindow*, SDL_Event), SDL_render (SDL_CreateRenderer,
etc; this CAN be safely fragmented as was suggested before, since the public
API is still the same)





I've... followed this and the accompanying thread a little.



What I don't understand is the desire to try to optimize away the outter
wrapper of these different SDL calls.



This would be akin to:



FlipScreen1()

{

memcpy();

}



FlipScreen2()

{

hardware_flip();

}



FlipScreen3()

{

depants_your_neighbor();

}



FlipScreen()

{

choose which 1/2/3 to call and do it

}



.... Optimizing FlipScreen() to instead be hard wired into 1/2/3() doesn't
improve much.



Similarly, for those who argue about space / foot print --- on typical
computers you have got to be joking. A MB or 2 of total space taken up in
the world of terabyte drives and GB's of memory ? And if you're in the
embedded world and truly concerned about this stuff, you'd just comment /
preprocessor the unwanted stuff out manually anyway.



I truly think a library compile time option to enable / disable software
renderer is a mistake and leads down a dangerous path.



In regards to splitting SDL up into smaller codependent libraries....
I'm.... somewhat against that as well. I really do like the *S* part of SDL
:). I just honestly think it's not the way to go. I can understand and
respect the desire to do that, I just don't agree.



-----



As far as removal of the software renderer... I'm almost inclined to agree
with the use '1.2' mentality. I'm all about 'the lowest common
denominator', and it is probably nearing time that the 2D engine is about
dead. Microsoft abstracted ddraw through d3d how long ago ? Anyhoo, that's
my worthless $0.02 thrown into the pot :)



-Will
Sam Lantinga
2011-01-24 06:20:53 UTC
Permalink
FYI, at the moment, I'm not planning any of the restructuring that has been
proposed in this thread.

As Ken said, stability first! :)
Post by Ken Rogoway
Somehow this thread (Drop support for software rendering in 1.3) has
digressed into multiple topics. All pertain to different ideas on
restructuring SDL, but they do not pertain specifically to the thread topic.
If people want to discuss splitting up SDL, or building different flavors
using compiler flags then those should probably be started as different
topics.
That being said, I’d like to add that BEFORE we worry about any type of
restructure of SDL 1.3 (graphic or otherwise), wouldn’t it be a good idea to
get a stable release out? SDL 1.3 is very much still a beta, and on almost
a daily basis there are commits that break the build for one platform or
another.
This doesn’t mean we cannot discuss topics like restructuring, but I’d like
to see a stable release before any of those ideas comes to fruition.
Ken
*On Behalf Of *Will Langford
*Sent:* Sunday, January 23, 2011 10:49 PM
*Subject:* Re: [SDL] Proposal: Drop support for software rendering in 1.3
Perhaps instead, modularize SDL itself into several smaller libraries? SFML
does something like this.
For example, SDL_core (SDL's standard c subset), SDL_system (threads, OS
version, CPU features; depends on SDL_core), SDL_surface (SDL_Surface-based
structures; depends on SDL_core and SDL_system for fast blitting),
SDL_windows (SDL_CreateWindow*, SDL_Event), SDL_render (SDL_CreateRenderer,
etc; this CAN be safely fragmented as was suggested before, since the public
API is still the same)
I've... followed this and the accompanying thread a little.
What I don't understand is the desire to try to optimize away the outter
wrapper of these different SDL calls.
FlipScreen1()
{
memcpy();
}
FlipScreen2()
{
hardware_flip();
}
FlipScreen3()
{
depants_your_neighbor();
}
FlipScreen()
{
choose which 1/2/3 to call and do it
}
.... Optimizing FlipScreen() to instead be hard wired into 1/2/3() doesn't
improve much.
Similarly, for those who argue about space / foot print --- on typical
computers you have got to be joking. A MB or 2 of total space taken up in
the world of terabyte drives and GB's of memory ? And if you're in the
embedded world and truly concerned about this stuff, you'd just comment /
preprocessor the unwanted stuff out manually anyway.
I truly think a library compile time option to enable / disable software
renderer is a mistake and leads down a dangerous path.
In regards to splitting SDL up into smaller codependent libraries....
I'm.... somewhat against that as well. I really do like the *S* part of SDL
:). I just honestly think it's not the way to go. I can understand and
respect the desire to do that, I just don't agree.
-----
As far as removal of the software renderer... I'm almost inclined to agree
with the use '1.2' mentality. I'm all about 'the lowest common
denominator', and it is probably nearing time that the 2D engine is about
dead. Microsoft abstracted ddraw through d3d how long ago ? Anyhoo, that's
my worthless $0.02 thrown into the pot :)
-Will
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
--
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Nathaniel J Fries
2011-01-24 06:48:13 UTC
Permalink
What I don't understand is the desire to try to optimize away the outter wrapper of these different SDL calls.
FlipScreen1()
{
   memcpy();
}
FlipScreen2()
{
  hardware_flip();
}
FlipScreen3()
{
  depants_your_neighbor();
}
FlipScreen()
{
  choose which 1/2/3 to call and do it
}
I think you're misunderstanding that.
We don't want a
FlipScreen()
{
#ifdef COMPILE_GL
GLFlipScreen();
#elif defined(COMPILE_D3D) && defined(WIN32)
D3DFlipScreen();
#else
SWFlipScreen();
#endif
}
AT ALL!

What we want is to choose what features are compiled into SDL to optimize CODE SIZE (both in memory and on the disk). I think doing so is relatively pointless, but there do still exist platforms with less than 50mb of memory available to an application at most times; and on those platforms, stripping off 100kb might be necessary. However in that case I would think that you'd save much more memory by simply WRITING IT IN NATIVE CODE, and usually if you're developing for such a platform YOU REALLY SHOULD BE DOING THAT ANYWAY (caps are for emphasis, not for yelling). There is of course the case of handhelds which sometimes incur restrictions on package size (I've heard that Apple likes to restrict iOS apps to 20mb); and in those cases skimming a bit off SDL might be just enough to bring you w
ithin that spec. But usually you could just use zlib or a similar compression library to compress your data files and get the same effect. I don't think that the types of applications writte
n for iOS and Android really need to worry too much about the memory limitation -- I don't think I've EVER exceed 40mb of memory in any of my PC programs; and if I were to optimize knowing I'm going to a low-memory system, I could probably cut it notably more (storing rarely accessed data in a file or compressing it in memory, always making sure I'm using the minimum sized types possible, stuff like this is fairly easy to do, requires simple code changes, and can save big on memory).
Similarly, for those who argue about space / foot print --- on typical computers you have got to be joking.  A MB or 2 of total space taken up in the world of terabyte drives and GB's of memory ?  And if you're in the embedded world and truly concerned about this stuff, you'd just comment / preprocessor the unwanted stuff out manually anyway.
See above.
I truly think a library compile time option to enable / disable software renderer is a mistake and leads down a dangerous path.
I'm not sure I'm with you. It's quite a simple bug to catch and fix. "Hey, I'm getting an error that says SDL can't make a renderer"
"Oh, okay, I guess I should enable software rendering afterall and re-release."
Really, very simple. All you need is a way to report bugs to the user in a way they can understand and report back to you!
I guess there's probably a select handful of programming/CS newbies who use SDL and may be stumped by this... but one post here will fix them quick.
In regards to splitting SDL up into smaller codependent libraries.... I'm.... somewhat against that as well.  I really do like the *S* part of SDL :).  I just honestly think it's not the way to go. I can understand and respect the desire to do that, I just don't agree.
This will only make building and linking to SDL slightly more complicated. A really well planned configuration and/or build script could smooth that first complication to effectively non-existence. and the second complication isn't really a big deal -- so you need to link to 5 libraries to get the same functionality; oh well.
As far as removal of the software renderer... I'm almost inclined to agree with the use '1.2' mentality.  I'm all about 'the lowest common denominator', and it is probably nearing time that the 2D engine is about dead.  Microsoft abstracted ddraw through d3d how long ago ?  Anyhoo, that's my worthless $0.02 thrown into the pot :)
If you're saying that 2D acceleration hardware is dead... it's been dead for even longer than that. A relic of the early/mid-nineties.
If you're saying that 2D games or 2D software rendering models are dead, I disagree completely.

Here's yet-another-thought on the matter. What if only the software renderer were removed from SDL core, and made into a utility library (SDL_swframebuffer or something), and of course have that include the 1.2 compatibility layer too. Would this make everyone happy?

------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/
Mason Wheeler
2011-01-24 14:57:21 UTC
Permalink
It's also important to remember that the handheld platforms SDL supports (iOS
and Android) all have hardware-accelerated OpenGL ES support built in, so they
have no need of software rendering either.




________________________________
From: Nathaniel J Fries <***@yahoo.com>
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

There is of course the case of handhelds which sometimes incur restrictions on
package size (I've heard that Apple likes to restrict iOS apps to 20mb); and in
those cases skimming a bit off SDL might be just enough to bring you within that
spec. But usually you could just use zlib or a similar compression library to
compress your data files and get the same effect. I don't think that the types
of applications written for iOS and Android really need to worry too much about
the memory limitation -- I don't think I've EVER exceed 40mb of memory in any of
my PC programs; and if I were to optimize knowing I'm going to a low-memory
system, I could probably cut it notably more (storing rarely accessed data in a
file or compressing it in memory, always making sure I'm using the minimum sized
types possible, stuff like this is fairly easy to do, requires simple code
changes, and can save big on memory).
michelleC
2011-01-24 15:52:27 UTC
Permalink
It's also important to remember that the handheld platforms SDL supports (iOS and Android) all have hardware-accelerated OpenGL ES support built in, so they have no need of software rendering either.



Your basing that on what.

I have been a mobile developer for almost 4 years and without giving you too much detail on the projects I am involved with, let me tell you we are indeed using software yuv12 rendering.
michelleC
2011-01-24 15:55:35 UTC
Permalink
Post by michelleC
It's also important to remember that the handheld platforms SDL supports (iOS and Android) all have hardware-accelerated OpenGL ES support built in, so they have no need of software rendering either.
Your basing that on what.
I have been a mobile developer for almost 4 years and without giving you too much detail on the projects I am involved with, let me tell you we are indeed using software yuv12 rendering.
I don't think that the types of applications written for iOS and Android really need to worry too much about the memory limitation -- I don't think I've EVER exceed 40mb of memory in any of my PC programs; and if I were to optimize knowing I'm going to a low-memory system, I could probably cut it notably more (storing rarely accessed data in a file or compressing it in memory, always making sure I'm using the minimum sized types possible, stuff like this is fairly easy to do, requires simple code changes, and can save big on memory).


you are either :

1) joking
2) don't have the foggiest notion of IOS and especially android native programming
3) not really done anything other than simple to-do lists or games.
michelleC
2011-01-24 15:57:19 UTC
Permalink
Post by michelleC
It's also important to remember that the handheld platforms SDL supports (iOS and Android) all have hardware-accelerated OpenGL ES support built in, so they have no need of software rendering either.
Your basing that on what.
I have been a mobile developer for almost 4 years and without giving you too much detail on the projects I am involved with, let me tell you we are indeed using software yuv12 rendering.
don't think that the types of applications written for iOS and Android really need to worry too much about the memory limitation -- I don't think I've EVER exceed 40mb of memory in any of my PC programs; and if I were to optimize knowing I'm going to a low-memory system, I could probably cut it notably more (storing rarely accessed data in a file or compressing it in memory, always making sure I'm using the minimum sized types possible, stuff like this is fairly easy to do, requires simple code changes, and can save big on memory).


you are either :

1) joking
2) don't have the foggiest notion of IOS and especially android native programming
3) not really done anything other than simple to-do lists or games.
Continue reading on narkive:
Loading...