Proposal: Drop support for software rendering in 1.3

[Torsten_Giebl]

Hello !

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.

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]

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

----- Original Message ----

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

[Rainer_Deyke]

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.

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).On 1/20/2011 21:49, Mason Wheeler wrote:

–
Rainer Deyke - rainerd at eldwood.com

[Jared_Maddox]

SDL Digest, Vol 49, Issue 98

Message: 4
1.3
Message-ID:
<AANLkTimCn2aRRpJgRourTyYedE+fNe6ESRFkjiZUPyxJ at mail.gmail.com>
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.

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.
  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?> Date: Thu, 20 Jan 2011 15:42:37 -0800
  From: Sam Lantinga
  To: SDL Development List
  Subject: Re: [SDL] Proposal: Drop support for software rendering in

SDL Digest, Vol 49, Issue 99

Message: 6
Date: Thu, 20 Jan 2011 17:14:12 -0800
From: Sam Lantinga
To: SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID:
<AANLkTikp3EnCv=HJKHN8bPjw_DfyNddPYJZ3G95=Aa1A at mail.gmail.com>
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
From: Alex Barry <alex.barry at gmail.com>
To: SDL Development List
Cc: sdl at libsdl.org
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID:
<AANLkTimrMRMqJPUTvXtMjcXUgDtn+V7thNAcM=YKn1N9 at mail.gmail.com>
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
From: Torsten Giebl
To: SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID: <4D390DCE.9040703 at syntheticsw.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

[slouken]

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

[Nicholas_Vining]

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

Nicholas Vining
Lead Programmer, Gaslamp Games
Dungeons of Dredmor, Coming in April 2011: http://www.gaslampgames.com

[Damian_Paz]

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: mordred@icculus.org (Nicholas Vining)
To: SDL Development List
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

[Rene_Dudfield]

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.On Thu, Jan 20, 2011 at 10: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

[Julien_Clement1]

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.

Le 21 janv. 2011 ? 10:09, sdl-request at lists.libsdl.org a ?crit :> Send SDL mailing list submissions to

sdl at lists.libsdl.org

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
sdl-request at lists.libsdl.org

You can reach the person managing the list at
sdl-owner at lists.libsdl.org

When replying, please edit your Subject line so it is more specific
than “Re: Contents of SDL digest…”

Today’s Topics:

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
From: Sam Lantinga
To: SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID:
<AANLkTik-55WptWRMUhMxGYB=eY8Xix98RnS7o735Wgmu at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

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!

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
-------------- 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
From: Nicholas Vining
To: SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID: <4D3949A1.9010401 at icculus.org>
Content-Type: text/plain; charset=“iso-8859-1”; Format=“flowed”

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

-------------- 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)
From: Damian Paz
To: SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in
1.3
Message-ID: <114915.23811.qm at web112607.mail.gq1.yahoo.com>
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.

---

From: Nicholas Vining
To: SDL Development List
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

-------------- next part --------------
An HTML attachment was scrubbed…
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110121/a25a6427/attachment.htm

---

---

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

End of SDL Digest, Vol 49, Issue 105

---

Julien CLEMENT
@Julien_Clement1

[slouken]

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?On Fri, Jan 21, 2011 at 12:39 AM, Sam Lantinga <@slouken> wrote:

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!

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, Founder and President, Galaxy Gameworks LLC

[Neil_White]

rename to

smcdl

slightly more complicated direct media layer

classic linux naming

[Damian_Paz]

What’s “direct” about this library after all?________________________________
From: neil@cloudsprinter.com (Neil White)
To: SDL Development List
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

[Rainer_Deyke]

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.On 1/21/2011 02:34, Sam Lantinga wrote:

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?

–
Rainer Deyke - rainerd at eldwood.com

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

[PoV]

I’m for.

Nathaniel J Fries wrote:

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.

Neil White wrote:

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.

Sam Lantinga wrote:

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.

Ren? Dudfield wrote:

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

[Rene_Dudfield]

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!On Fri, Jan 21, 2011 at 11:13 AM, PoV wrote:

Ren? Dudfield wrote:

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.

[Vittorio_Giovara]

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
VittorioOn Fri, Jan 21, 2011 at 10:34 AM, Sam Lantinga wrote:

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?

On Fri, Jan 21, 2011 at 12:39 AM, Sam Lantinga wrote:

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!

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, Founder and President, Galaxy Gameworks LLC

---

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

[PoV]

Ren? Dudfield wrote:

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

[Mason_Wheeler]

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

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

UliOn Jan 21, 2011, at 10:34 AM, Sam Lantinga wrote:

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: @Ulrich_von_Zadow
Skype: uzadow