SDL is used for more than just games.
JeffOn Wednesday 02 February 2011 06:16, David Olofson wrote:
With the current state of things, I’m having a hard time seeing why one
would design a new game to run within the limitations of a “pure 2D” API -
[…]
There are plenty of developers who would like to have a fallback
option if the hardware drivers are broken or even just not installed.
Granted, often it makes more sense to just bail, but, for some
applications like educational applications, analytic visualization and
even casual games, it is perfectly viable to fall back to software
rendering.This is what I’ve been thinking as well, but I think it basically comes
down to this: You either use “2D over 3D” style rendering, or you don’t.
It’s kind of ridiculous to demand hardware acceleration, and then do
nothing but plain rectangular blits. (For this reason, it seems rather
strange to me to restrict the SDL 1.3 API to rectangular operations and
no rotation or arbitrary polygons.)While I agree that the lack of rotation is a wart, you’re forgetting
something even more basic: blending. Per-pixel alpha w/o hardware
support is very costly.
…and yet, it was there in SDL 1.2 already - although the RLE acceleration
feature makes it highly usable (at least for AA) on anything but ancient
pocket calculators, basically.
Anyway, that’s actually my point; that, as soon as you start doing transforms
(beyond integer pixel displacement) and blending, hardware acceleration is
pretty much needed for realtime rendering anyway. So, why not do it properly
(2D OpenGL subset style API), and provide a software implementation for the
occasional off-screen rendering job, or less demanding applications?
As to rotation/scaling, IIRC, the reason why rotation is left out has little
to do with software rendering. Some accelerated hardware lacks rotation but
does scaling.
It’s relatively easy, and often even preferable, to create sprite
sheets w/pre-rotated images. However, though color keying works for
pure binary alpha, doing full alpha doesn’t have a similar work
around.
Well, if you need realtime performance with software rendering, your game
engine is going to need some special cases anyway. So, why not just have it
stay away from realtime rotations and heavy blending effects when running
without hardware acceleration?
Granted, this will be very hard to do with some game designs, but that’s just
the way it is; those designs pretty much require “3D style” acceleration.
With the current state of things, I’m having a hard time seeing why one
would design a new game to run within the limitations of a “pure 2D” API
- and if it still requires OpenGL or Direct3D to run, it’s just
ridiculous…!I clearly disagree. There are loads of games I’d like to write within
just such a “limited” system, from relatively simple puzzle games to
isometric tile based games. Again, I’d really like rotation as well,
but still - the SDL 1.3 API gets me most of what I want at the moment
(at least when combined with _mixer, _image, etc.).
Well, I’m into fullscreen scrolling action games, and even the “half screen”
scrolling Kobo Deluxe is struggling to achieve playable frame rates (IMHO)
with software rendering in anything but “retro” resolutions. That’s why I
wrote the glSDL “wrapper”. 
That said, I totally see your point - but my point is, how large a proportion
of your target market actually needs software rendering due to missing OpenGL
or Direct3D support?
Any ancient version of either API will do just fine for the basic scaling,
rotation, filtered textured polygons and various forms of blending, and that’s
really all you need to upgrade from the retro look to the kind of level even
casual gamers on ancient hardware expect these days.
It might be easier to understand my position if you consider that I’m
intending to make money selling games. Although I would of course like my
games to run on anything with a CPU in it (like Kobo Deluxe), I just don’t
have the development resources to do that while achieving the kind of look and
feel people would expect from a game released less than ten years ago.
Again, I’m not personally opposed to doing away with the software
renderer, I just understand the reasons for wanting to keep it.I do, however think that the software renderer shouldn’t hold back the
mainline rendering system. For example, just because rotation is slow
in software, doesn’t mean it shouldn’t be available in the hardware
path.
I totally agree with that!
It’d be nice to have a way to query the system to tell if each major
function (blit, blending, rotation, etc.) is accelerated in the
current renderer. That would allow an application to adapt to the
system’s capabilities.
Yes, absolutely.
Of course this is all moot, as Sam stated waaaaaaaay up-thread that
SDL_1.3 isn’t dropping the software rendering path.
Well, there are still the issues of how what that software rendering path
should do, and what the rendering API should look like. I don’t know if that
is set in stone, but well, as it is, I’m not considering SDL 1.3 as a viable
alternative to OpenGL for my current and future projects.
I don’t know if my requirements are odd or something, but looking at casual
games and even Flash games these days, I think not. I might do without
arbitrary shaped polygons and color modulation (though that would engine
exhaust flames and that sort of stuff much harder to do nicely), but going
back to pre-rotated sprites just isn’t an option in a game where everything is
physics based and “free direction”. Even though I do have a 2.5D software
engine that could render nices sprites with any number of rotations, the
memory consumption would be a problem, and I’m already burning worrying
amounts of memory on the (mostly non-tiled) backgrounds.On Wednesday 02 February 2011, at 17.01.27, Greg Jandl <greg.jandl at gmail.com> wrote:
On Wed, Feb 2, 2011 at 08:16, David Olofson <@David_Olofson> wrote:
On Tuesday 01 February 2011, at 16.48.32, Greg Jandl <greg.jandl at gmail.com> wrote:
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
‘---------------------------------------------------------------------’
Yes, I use it for GUI toolkits and various other stuff myself - and I wouldn’t
want that stuff to require OpenGL or Direct3D to run at all.
What I’m saying is basically that if SDL 1.3 doesn’t embrace the whole “2D
over 3D acceleration” thing, I think the 2D rendering API will be of rather
limited use for games. Even lowly Flash games use textured, antialiazed
polygons these days - and that’s (so far) all in software…!
That said, where does one draw the line? What we would all really like, I
guess, is an add-on library that provides a full-on 3D API that runs over
OpenGL as well as Direct3D. That would cover the “advanced 2D” part just fine
as well, like OpenGL and Direct3D do now, but without everyone and his dog
having to write two backends.
But, who’s going to design and code that?On Wednesday 02 February 2011, at 17.24.30, Jeff Post <j_post at pacbell.net> wrote:
On Wednesday 02 February 2011 06:16, David Olofson wrote:
With the current state of things, I’m having a hard time seeing why one
would design a new game to run within the limitations of a “pure 2D” APISDL is used for more than just games.
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
‘---------------------------------------------------------------------’
Maybe SDL 1.2 can be continued by someone else? At least to fix the bugs it
still has.________________________________
From: david@olofson.net (David Olofson)
To: sdl at lists.libsdl.org
Sent: Wed, February 2, 2011 2:15:09 PM
Subject: Re: [SDL] Proposal: Drop support for software rendering in 1.3
On Wednesday 02 February 2011, at 17.24.30, Jeff Post <j_post at pacbell.net> wrote:
On Wednesday 02 February 2011 06:16, David Olofson wrote:
With the current state of things, I’m having a hard time seeing why one
would design a new game to run within the limitations of a “pure 2D” APISDL is used for more than just games.
Yes, I use it for GUI toolkits and various other stuff myself - and I wouldn’t
want that stuff to require OpenGL or Direct3D to run at all.
What I’m saying is basically that if SDL 1.3 doesn’t embrace the whole “2D
over 3D acceleration” thing, I think the 2D rendering API will be of rather
limited use for games. Even lowly Flash games use textured, antialiazed
polygons these days - and that’s (so far) all in software…!
That said, where does one draw the line? What we would all really like, I
guess, is an add-on library that provides a full-on 3D API that runs over
OpenGL as well as Direct3D. That would cover the “advanced 2D” part just fine
as well, like OpenGL and Direct3D do now, but without everyone and his dog
having to write two backends.
But, who’s going to design and code that?
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
‘---------------------------------------------------------------------’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I thought that was Ogre on SDL. And why do people keep saying software
rotation is too slow for realtime? I use it a ton! It just depends on the
algorithm you use.
Jonny DOn Wed, Feb 2, 2011 at 12:15 PM, David Olofson wrote:
On Wednesday 02 February 2011, at 17.24.30, Jeff Post <j_post at pacbell.net> wrote:
On Wednesday 02 February 2011 06:16, David Olofson wrote:
With the current state of things, I’m having a hard time seeing why one
would design a new game to run within the limitations of a “pure 2D”
APISDL is used for more than just games.
Yes, I use it for GUI toolkits and various other stuff myself - and I
wouldn’t
want that stuff to require OpenGL or Direct3D to run at all.What I’m saying is basically that if SDL 1.3 doesn’t embrace the whole “2D
over 3D acceleration” thing, I think the 2D rendering API will be of rather
limited use for games. Even lowly Flash games use textured, antialiazed
polygons these days - and that’s (so far) all in software…!That said, where does one draw the line? What we would all really like, I
guess, is an add-on library that provides a full-on 3D API that runs over
OpenGL as well as Direct3D. That would cover the “advanced 2D” part just
fine
as well, like OpenGL and Direct3D do now, but without everyone and his dog
having to write two backends.But, who’s going to design and code that?
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
‘---------------------------------------------------------------------’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I thought that was Ogre on SDL.
Ogre is a full blown 3D engine - not a 3D rendering API. It may (or may not)
fit the bill perfectly if you’re doing a 3D game with 3D maps, models and all,
but it’s not the right tool for textured polygons and rotated sprites in a 2D
game.
What I’m talking about is basically a stripped down and simplified OpenGL,
that runs over OpenGL and Direct3D. It would cover most 3D stuff except
possibly the latest hardcore fads, and doing so, it would automatically also
cover pretty much anything that could be considered “2D”.
If Microsoft hadn’t been so successful at fighting OpenGL in the low end
market, that answer would have been OpenGL, plain and simple. Not everyone
loves the OpenGL API, but it gets the job done, and you don’t need a degree
and tens years of experience to use it.
And why do people keep saying software rotation is too slow for realtime? I
use it a ton! It just depends on the algorithm you use.
Indeed, software rendering isn’t that slow, and even “low end” CPUs are
pretty fast these days. The biggest issue actually tends to be getting the
output to the screen; not the software rendering itself. But, of course, if
you need blending and color modulation along with interpolation/filtering on
anything but tiny objects, CPU requirements are going to be unrealistic. For
now, at least. :-)On Wednesday 02 February 2011, at 18.29.40, Jonathan Dearborn wrote:
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
‘---------------------------------------------------------------------’
Show me a DirectX backend first, then do away with Windib. The fact is, Windib is fast in the first place. The Surface and blit API could be maintained with a directX backend, by being a “wrapper”, so people think they’re doing surfaces but it’s actually textures. The point is, as long as people can load a .png or .bmp file and then slap it on the screen without too many llnes, it’s good whether that’s windib blitting or older directx blitting or whatever directx10 does nowadays. So moral of the story, don’t do away with the blitting yet, just add the openGL and directX backends so people have more options; I have spoken.