How many times must I say that I do not want to sacrifice the
software renderer before people stop suggesting that’s what I am
after? People DID draw triangles before 3D video cards?
Consider some use cases:
Palette swaps. SDL’s renderer can’t do them. Oh, they were a staple
of 2D games, but they’re not supported by SDL’s renderer because SDL
might have to emulate it on fixed pipeline OpenGL and it wouldn’t
necessarily be a cheap operation. Still cheaper than software
rendering, of course, and a 2D game ought to run just fine anyway.
On shader-based OpenGL and D3D and obviously unaccelerated rendering,
it’s basically free. It COULD be added if someone took the time.
Drawing polygons. This one is trivial in all 3D-backed render
targets obviously, but the fact is that people used to do it before
there was OpenGL. The algorithms aren’t even complex unless you do
subpixel weighting. It may have been the realm of hand-tuned asm on
a 6502, but flat-shaded polygons were common in basic C on a 386. I
wouldn’t suggest trying to anti-alias them in C, but ? they could be
drawn. And it would give SDL an often-requested feature that “works
anywhere”, not just OpenGL.
Circles are easy to do in software compared to polygons, but they’re
done completely differently in 3D targets, and generally considered
"not doable" because the best you’ll get is an approximation.
Though, if you can’t tell the approximation is an approximation, does
it matter? Not a traditional feature of 90s game console graphics
hardware, but it’s worth at least considering today because it’s so
very different on 3D hardware vs. classic software.
“Mode 7 style” 3D effects. Firmly in the "would be cool, I guess"
category for me. I do NOT suggest implementing arbitrary textured
polygons. The fact is that the SNES’s mode 7 effects cheat, and they
cheat a lot. The end result of the cheating looked very cool at the
time and is still kind of cool in a retro sort of way.
Extending the renderer. Actually three usage cases, not one:
-
You are using the SDL renderer in your code already, and you
decide to make the jump to OpenGL (or at least optionally include
some pretty effects if you’ve got it?) Maybe you’re going to support
the other rendering targets as well, or maybe not. Either way, you
don’t have to FIRST port your code before you can start adding stuff.
All it would take is some ability to query the renderer’s state a bit
and obtain the underlying context if needed.
-
You’re NOT using the SDL renderer at all, but you want to use an
extension library that does. Say, a revived SDL_console for
debugging, scripting, etc. This was actually one of the stated
reasons for SDL 1.3 to actually HAVE a unified renderer, and it’s
still not actually possible without hackery and making assumptions
about SDL’s internals that you really shouldn’t do. Which is sad,
because it actually happens to work just fine on software and
shader-based 3D targets. It’s only old school OpenGL that you have
to actually do any work at it. And the work would be minimal if SDL
could be queried about a few things?
-
SDL_gpu. It’s a REPLACEMENT for the SDL renderer why? In part
because it works in both SDL 1.2 and 2.x, but also because it’s
simply not actually possible to implement what SDL_gpu does on top of
the SDL renderer without making assumptions about internal state data
within SDL. If you think the idea above about SNES mode 7 style
effects was worth doing, the argument is successfully made (as is
likely) that it serves some kind of specific functions and doesn’t
belong in SDL proper, you COULD still implement it and apps using the
SDL renderer API could still use the code.
Doing any (or all three) of these things requires a couple of queries
and a callback or two?little more than that. But I still think that
basic polygons should be done in SDL.
JosephOn Fri, Jun 20, 2014 at 01:42:08AM +0200, Jonas Kulla wrote:
2014-06-20 0:57 GMT+02:00 T. Joseph Carter <@T_Joseph_Carter>:
SDL_gpu is an alternative to the SDL renderer, not an addition. Also, it
explicitly does NOT support software targets (or D3D for that matter?) So
it doesn’t really matter what it does in the context of this discussion.
SDL_Renderer gets most of its strengths from the fact that it is so
incredibly simple: it will run (almost) anywhere.
If you want to implement things already present in SDL_gpu, while
sacrificing the software backend, all you’re doing
is rewriting SDL_gpu. What is it about SDL_Renderer that makes it the
must-use interface of every SDL2 user?
One of the major problems with SDL 1.2 was that there were a lot of really
cool extension libraries that only worked with software rendering or only
worked with OpenGL. Nothing worked with D3D for some reason. 
This problem should theoretically be gone now, but in practice it isn’t
because the SDL renderer doesn’t play nice with anything else. You could
not revive SDL_console to create a debugging and scripting environment for
your game if you use SDL_gpu, or OpenGL, or D3D, or anything else.
You are constrained to the SDL renderer’s functions which are severely
limited because ultimately the renderer wants to be a wrapper around a few
OpenGL (or equivalent) calls, but is constrained because the software
rendering target, and by the fact that there is zero growth potential if
you use SDL’s renderer without porting your code to use OpenGL or something
natively first.
I’m pretty sure the renderer is just an implementation of “how can I get
SDL1.2 style code hardware accelerated
as quickly as possible?”.
I see two possible solutions, and I actually advocate both:
- Give the user some hooks into the renderer so that they can implement
what isn’t supported themselves. In particular, if the rendering target is
using a fixed OpenGL pipeline, you need to be able to reliably know what
state SDL thinks the pipeline is in. You can write your code to make
assumptions that are currently correct, but they might not always be. And
the API additions to query that information would be pretty basic. As the
game and its developer outgrow the renderer’s limits, they have the means
to expand and even to eventually migrate away from the renderer if desired.
… which defeats the entire purpose of being graphics platform agnostic. If
you’re going to target a system with
OpenGL on it, you might as well just write your app in pure OpenGL.
- Accept that SDL’s renderer isn’t and shouldn’t be basically an
over-glorified blitter. In which case, the question to ask isn’t what are
its current limitations, but what should its limitations be? Currently
it’s limited to things easily implemented in software that happen to be
thin wrappers of accelerated backends. It could do a little more than that
without changing any exiting API.
Joseph
On Thu, Jun 19, 2014 at 09:45:30PM +0200, Jonas Kulla wrote:
2014-06-19 21:29 GMT+02:00 T. Joseph Carter <@T_Joseph_Carter
:
If we take that attitude, then we really ought to look at some fairly
significant API improvements for the renderer going forward?stuff I would
compare with basically the SNES in terms of built-in graphics capability,
possibly with a few minor additions that are widely requested and are
basically free in a 3D renderer anyway, such as rotation. I know if
SDL’s renderer had support for basic rendering, 2D polygons (possibly
sans
textures for speed reasons?) and stuff like the SNES’s much-loved Mode 7,
they would get used for some really cool stuff.
Even if all of the above is implemented, the SDL renderer would be a
paper-thin interface to any 3D subsystem you’ve got. And given minor
limitations on what functionality the renderer presents, it’s not much
heavy lifting for software targets than what SDL already has. The
argument
is mostly whether or not what SDL already has for software targets is
"bloat" as it is.
I wouldn’t have any objections to that either. Basically, any time the
SDL renderer becomes more capable, I’m all for it.
Joseph
Doesn’t SDL_gpu already do rotation and polygon rasterization?
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