[SDL] SDL 1.3 and rendering API state management
david at olofson.net
Mon Sep 4 13:20:55 PDT 2006
On Monday 04 September 2006 21:07, Stephane Marchesin wrote:
> > You can add all sorts of rendering APIs by simply layering them on
> > top of the SDL surface structure and blit operations, or you can
> > go down to the pixel level and do what ever you want to any SDL
> > surface.
> No, as soon as you want to hardware accelerate the new
> functionality, you have to have a least some hook to the internals.
> Say, for example the hardware exposes a rotation function that goes
> unused by the current SDL code. If you don't want rotation support
> in SDL itself, but in an external library, you have to do it in
> software. That's because SDL doesn't expose the hardware's rotation
Right. This was the first problem I ran into: I can't use SDL
textures, as I can't get at the OpenGL texture name or Direct3D
> On the other hand, if you have access to internal hooks through some
> plugin interface, you're now able to provide hardware acceleration
> for the new functionality. And really, you don't want things like
> rotation/scaling without acceleration, because they'd be pretty
> useless then.
Alternatively, if it's not realistically possible or too inefficient
to share contexts, there is the option of plugging in a full renderer
implementation using the current (internal) renderer registry API.
As "advanced" rendering features are apparently never going into SDL,
I think that is the safest and most efficient way of handling it.
We're effectively talking about maintaining a set of extended
versions of the SDL renderers, as a separate project - and I think
that's easier and more likely to actually work than any other
solution that's been discussed so far.
To me, it seems like an easy way out for everyone. The interfaces are
already in SDL 1.3; they're just not public. There are renderers as
well, so creating a new renderer is just a matter of ripping one or
more of the ones in SDL and extending as needed.
So, why bother plugging things in behind the SDL API, rather than
adding layers above SDL the way we are used to?
Well, adding layers doesn't automatically make add-on libs using the
SDL 2D API work over your display setup. Doesn't matter if you
implement the full SDL 2D API, as there is no way you can have an
add-on library use it, unless you hack and recompile the add-on
library, or use some compile time magic a la glSDL/wrapper.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
More information about the SDL