Proposal: Drop support for software rendering in 1.3

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

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/

Ugh. I like having a fallback and assurance that SDL 1.3 would work on odd
platforms, but I feel like I agree… :frowning:

Jonny DOn Thu, Jan 20, 2011 at 5:41 PM, Mason Wheeler wrote:

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


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

Quoth Mason Wheeler , on 2011-01-20 14:41:48 -0800:

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

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.On Thu, Jan 20, 2011 at 2:41 PM, Mason Wheeler wrote:

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


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


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Sam Lantinga wrote:

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

Sam Lantinga wrote:

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

  • 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…>From: Sam Lantinga

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.

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?

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

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

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.

  • 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.On Thu, Jan 20, 2011 at 17:42, Sam Lantinga wrote:


Do what you can, where you are, with what you have. - T. Roosevelt

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…On 01/20/2011 05:29 PM, Neil White wrote:

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 )

No, it will be bumped to 2.0 before release. 1.3 is the in-progress
version.On Thu, Jan 20, 2011 at 4:48 PM, jon <jon.rafkind at gmail.com> wrote:

On 01/20/2011 05:29 PM, Neil White wrote:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

jon wrote:> On 01/20/2011 05:29 PM, Neil White wrote:

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
SDL at lists.libsdl.org
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. :stuck_out_tongue:


EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

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.On 1/20/2011 16:42, Sam Lantinga wrote:

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


Rainer Deyke - rainerd at eldwood.com

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

-OzOn Thu, Jan 20, 2011 at 10:23 PM, Rainer Deyke wrote:

On 1/20/2011 16:42, Sam Lantinga wrote:

  • 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 - rainerd at eldwood.com


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

Hello !

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.

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 …

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

If X11 support were dropped, that means I’d have to find some other GUI
library to use, and dammit, I like SDL!

JeffOn Thursday 20 January 2011 19:39, Torsten Giebl wrote:

I would personally be against dropping X11, GDI and those non accelerated
backends.

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.On 1/20/2011 15:41, Mason Wheeler wrote:

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?


Rainer Deyke - rainerd at eldwood.com

Drop software rendering? I think that’s ridiculous.

Hello !

  • 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

Hello !

  • 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.>----- Original Message ----

From: Torsten Giebl
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3