Proposal: Drop support for software rendering in 1.3

SDL Development
81

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.

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?

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 KOn 2011-01-24 02:04, Eric Wing wrote:

82

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.On Sun, Jan 23, 2011 at 10:23 PM, Nathaniel J Fries wrote:

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 :slight_smile:

-Will

83

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.

KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Will Langford
Sent: Sunday, January 23, 2011 10:49 PM
To: sdl at 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 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 :slight_smile:

-Will

84

FYI, at the moment, I’m not planning any of the restructuring that has been
proposed in this thread.

As Ken said, stability first! :)On Sun, Jan 23, 2011 at 10:15 PM, Ken Rogoway wrote:

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-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
*On Behalf Of *Will Langford
Sent: Sunday, January 23, 2011 10:49 PM

To: sdl at 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 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 :slight_smile:

-Will

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

85

Will Langford wrote:

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
}

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 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 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 :slight_smile:

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/

86

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

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.

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.

-EricOn 1/23/11, pk wrote:

On 2011-01-24 02:04, Eric Wing wrote:
–
Beginning iPhone Games Development
Learn how to program games for iOS

87

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-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
To: peka at min-epost.net; SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/23/11, pk wrote:

On 2011-01-24 02:04, Eric Wing wrote:

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

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.

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
Learn how to program games for iOS

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

88

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.

-OzOn Mon, Jan 24, 2011 at 2:15 AM, Ken Rogoway wrote:

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-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
On
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
To: peka at min-epost.net; SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/23/11, pk wrote:

On 2011-01-24 02:04, Eric Wing wrote:

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

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.

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
Learn how to program games for iOS

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

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

89

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 :slight_smile:

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)

90

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.

JeffOn Monday 24 January 2011 05:52, Alex Barry wrote:

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.

91

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: nfries88@yahoo.com (Nathaniel J Fries)
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).

92

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.

93

michelleC wrote:

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

michelleC wrote:

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

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?

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 KOn 2011-01-24 08:00, Eric Wing wrote:

96

Yep, we’re keeping the software renderer. :)On Mon, Jan 24, 2011 at 5:52 AM, Alex Barry <alex.barry at 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

On Mon, Jan 24, 2011 at 2:15 AM, Ken Rogoway wrote:

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-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
On
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
To: peka at min-epost.net; SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/23/11, pk wrote:

On 2011-01-24 02:04, Eric Wing wrote:

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

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.

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
Learn how to program games for iOS

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

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

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

97

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: slouken@libsdl.org (slouken)
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

Yep, we’re keeping the software renderer. :slight_smile:

On Mon, Jan 24, 2011 at 5:52 AM, Alex Barry <alex.barry at 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

On Mon, Jan 24, 2011 at 2:15 AM, Ken Rogoway wrote:

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-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On

Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
To: peka at min-epost.net; SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/23/11, pk wrote:

On 2011-01-24 02:04, Eric Wing wrote:

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

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.

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
Learn how to program games for iOS

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

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

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

98

Yep. :)On Mon, Jan 24, 2011 at 11:24 AM, Mason Wheeler wrote:

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 <@slouken>
**
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

Yep, we’re keeping the software renderer. :slight_smile:

On Mon, Jan 24, 2011 at 5:52 AM, Alex Barry <alex.barry at 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

On Mon, Jan 24, 2011 at 2:15 AM, Ken Rogoway wrote:

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-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org]
On
Behalf Of Eric Wing
Sent: Monday, January 24, 2011 1:00 AM
To: peka at min-epost.net; SDL Development List
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/23/11, pk wrote:

On 2011-01-24 02:04, Eric Wing wrote:

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

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.

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
Learn how to program games for iOS

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

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

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

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

99

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.On 1/24/2011 12:24, Mason Wheeler wrote:

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?

–
Rainer Deyke - rainerd at eldwood.com

100

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

From: Rainer Deyke
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3

On 1/24/2011 12:24, Mason Wheeler wrote:

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.