[SDL] SDL 1.3 and rendering API state management

David Olofson 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
> function.

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 
texture pointer.


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