Alberto, you seriously mention Mesa 3D? It’s as slow as molasses, certainly for 2D rendering. The SDL software renderer beats the socks off it, often SDL is 50%-100% faster. So Mesa 3D is simply a non-option. In some cases it’s so slow that it might even be faster to emulate software 3d with SDL’s software renderer than to use Mesa. Just look at TinySDGL.
For what it’s worth, I’m in favor of removing the compatibility
support, keeping software rendering, and adding a stand-alone (so it’s
useful for general image manipulation) roto-zoomer function.> Date: Wed, 27 Jul 2011 22:07:08 -0700
From: Nicholas Vining
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3 status ?
Message-ID: <4E30EE7C.8020005 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Based on what we want to do for the next
game, I’m going to end up writing an actual OpenGL renderer, and that’s
going to be a support nightmare. Them’s the breaks, I suppose.
If it isn’t especially complex, you might try using TinyGL instead of
just whatever OpenGL implementation the users have, it’s purely
software, supposed to be fast, and it looks like there was at least an
attempt to port it to SDL. If it’ll work for your case, then it’ll
(hopefully) be easier to support than the alternatives.
As I was saying before, software rendering is a major CPU hog, beyond what one can easily imagine.
The simple reality is that memory is the bottleneck, and the GPU has faster memory.
Aside from this, it’s also remarkably hard to shovel the pixels over the PCI-E bus to the video card at reasonable speeds.On 07/28/2011 11:57 PM, Jared Maddox wrote:
For what it’s worth, I’m in favor of removing the compatibility
support, keeping software rendering, and adding a stand-alone (so it’s
useful for general image manipulation) roto-zoomer function.Date: Wed, 27 Jul 2011 22:07:08 -0700
From: Nicholas Vining
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3 status ?
Message-ID:<4E30EE7C.8020005 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedBased on what we want to do for the next
game, I’m going to end up writing an actual OpenGL renderer, and that’s
going to be a support nightmare. Them’s the breaks, I suppose.If it isn’t especially complex, you might try using TinyGL instead of
just whatever OpenGL implementation the users have, it’s purely
software, supposed to be fast, and it looks like there was at least an
attempt to port it to SDL. If it’ll work for your case, then it’ll
(hopefully) be easier to support than the alternatives.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
The argument that some targets simply don’t have a GPU is a compelling
one though.On 29/07/2011 09:29, Forest Hale wrote:
As I was saying before, software rendering is a major CPU hog, beyond
what one can easily imagine.The simple reality is that memory is the bottleneck, and the GPU has
faster memory.
Hi,
I am completely against droping support for software rendering.
When you develop simple 2D games, people who play your games expect it to
run everywhere, even on crappy old integrated video stuff.
As a developer, I also expect to everyone who wants to play my game, that
they can do it on their old Pentium III.
This is very relevant for tuxmath, tuxtype, and tuxpaint. Our stuff
does not require high performance, but we want it to work on the old,
sometimes ancient machines that accumulate in elementary schools.
Just my $0.02.–
David Bruce
For all your software needs, visit The Apt Store:
deb http://ftp.us.debian.org/debian stable main
But you could have all kinds of animation at 60fps 1080P in tuxpaint!!
On a more serious note I’m a big proponent of software rendering, but mostly from a technical rather than practical perspective - writing pixel poking code is fun.
My point is that it is inherently slow, even if you try hard to optimize it, so on any CAPABLE computer we should never be doing software rendering.On 07/29/2011 02:39 AM, David Bruce wrote:
Hi,
I am completely against droping support for software rendering.
When you develop simple 2D games, people who play your games expect it to
run everywhere, even on crappy old integrated video stuff.
As a developer, I also expect to everyone who wants to play my game, that
they can do it on their old Pentium III.This is very relevant for tuxmath, tuxtype, and tuxpaint. Our stuff
does not require high performance, but we want it to work on the old,
sometimes ancient machines that accumulate in elementary schools.
Just my $0.02.
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
I’ll second that, I’m in favor of removing SDL_compat, adding simple
2d manipulation features (like rotozooming) and leaving the software
render as it is.
What I’m really against is adding compile-time symbols or macros that
lead to very painful development environments.
just my 3.14$ cents
VittorioOn Fri, Jul 29, 2011 at 8:57 AM, Jared Maddox wrote:
For what it’s worth, I’m in favor of removing the compatibility
support, keeping software rendering, and adding a stand-alone (so it’s
useful for general image manipulation) roto-zoomer function.Date: Wed, 27 Jul 2011 22:07:08 -0700
From: Nicholas Vining
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL 1.3 status ?
Message-ID: <4E30EE7C.8020005 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedBased on what we want to do for the next
game, I’m going to end up writing an actual OpenGL renderer, and that’s
going to be a support nightmare. Them’s the breaks, I suppose.If it isn’t especially complex, you might try using TinyGL instead of
just whatever OpenGL implementation the users have, it’s purely
software, supposed to be fast, and it looks like there was at least an
attempt to port it to SDL. If it’ll work for your case, then it’ll
(hopefully) be easier to support than the alternatives.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Tim and David, I agree with you.
Forest, sure, SW rendering is slow and hogs the CPU if you want to render to display. If you want to do in-memory image editing, though, it can be very useful. Rendering to a HW texture and then reading back the pixels is sort of complicated and I’m unsure if it’s supported everywhere. In stead, I’d render to a sw surface, and update the texture only if needed.
Vittorio, agreed there, but which simple 2d features should be added? Now we have blitting and scaling. Next to add would be rotozooming? Anything else? Just plain rotation? Shearing? Affine transformations? Mode 7 style “perspective” projections? Do we needed more primitives too like triangles, circles, ellipses, rounded rectangles…? Or should those be left for the next version of SDL_gfx?
Kind Regards,
B.
Why are we still debating whether or not we want a software renderer?
I believe Ryan stated a number of replies back that the renderer is
generally complete, and it’s no longer a development bottleneck.
In regards to software rendering as a compatibility layer, I think
software rendering is useful. This thread is filled with various game
developers stating that, and to those who aren’t using the software
renderer, I suppose it shouldn’t matter to you if it is still included
or not.
-AlexOn Fri, Jul 29, 2011 at 8:02 AM, Beoran wrote:
Tim and David, I agree with you.
Forest, sure, SW rendering is slow and hogs the CPU if you want to render to
display. If you want to do in-memory image editing, though, it can be very
useful. Rendering to a HW texture and then reading back the pixels is sort
of complicated and I’m unsure if it’s supported everywhere. In stead, I’d
render to a sw surface, and update the texture only if needed.Vittorio, agreed there, but which simple 2d features should be added? Now we
have blitting and scaling. Next to add would be rotozooming? Anything else?
Just plain rotation? Shearing? Affine transformations? Mode 7 style
"perspective" projections? Do we needed more primitives too like triangles,
circles, ellipses, rounded rectangles…? Or should those be left for the
next version of SDL_gfx?Kind Regards,
B.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I agree.
Reading through this I wondered why there are so many pages about software render even after Ryan’s post…
The more interesting things to discuss are the ones on the first page.
For example how to handle coexistance of SDL 1.2 and SDL 1.3/2.0 in the future. Hopefully in the near future.
Right now you have to decide which SDL you want to have on your system (or prefix) and mostly people tend to decide on 1.2 because it works (with glitches).
And some kind of rough roadmap would be nice, too, especially I’d like to know whether 1.2 will get another release or whether people will need to check out the SDL 1.2 branch to get their bugs fixed…
MrOzBarry wrote:> Why are we still debating whether or not we want a software renderer?
I believe Ryan stated a number of replies back that the renderer is
generally complete, and it’s no longer a development bottleneck.
In regards to software rendering as a compatibility layer, I think
software rendering is useful. This thread is filled with various game
developers stating that, and to those who aren’t using the software
renderer, I suppose it shouldn’t matter to you if it is still included
or not.
-Alex
This should be easy to do. Use /usr/include/SDL1.2 and
/usr/include/SDL1.3. The pkg-config scripts should be named sdl and
sdl-1.3.On 07/31/2011 02:24 AM, Dominus wrote:
The more interesting things to discuss are the ones on the first page.
For example how to handle coexistance of SDL 1.2 and SDL 1.3/2.0 in the
future. Hopefully in the near future.
Right now you have to decide which SDL you want to have on your system
(or prefix) and mostly people tend to decide on 1.2 because it works
(with glitches).
And some kind of rough roadmap would be nice, too, especially I’d like to know whether 1.2 will get another release or whether people will need to check out the SDL 1.2 branch to get their bugs fixed…
On paper, 1.2.14 was meant to be the final 1.2 release, but I’d be surprised if we don’t end up doing a 1.2.15 with accumulated fixes.
Certainly the Mac OS X Lion fixes are hugely important, if nothing else, but I would actually like to make one major addition to 1.2: a Wayland video target, so old games can continue to be “native” when we move past X11 in the nebulous future.
In any case: we will always add 1.2 fixes to revision control, whether they get shipped in a formal release or not.
–ryan.