[SDL] SDL 1.3 and rendering API state management
david at olofson.net
Sun Sep 3 10:36:33 PDT 2006
On Sunday 03 September 2006 19:17, Torsten Giebl wrote:
> Hello !
> > Doesn't feel quite right to bypass everything, including display
> > setup, but then again, if the renderer "plugin" API is made
> > public, you can basically just rip that code from SDL. Not exactly
> > megabytes of code anyway! :-)
> > The advantages seem to be major ones, though - and it solves the
> > SDL 2D vs external renderer "extension" conflicts in a clean and
> > potentially very efficient way. (No extra cost for mixing SDL 2D
> > and "extended" calls, as both are wired to the same renderer.)
> How does this work ?
> The coder hast copy&paste the renderers from 1.3 ? Always ?
No, only if you're going to do "backend stuff". Normal applications
and other code that uses the SDL API (or plugin extensions to it) are
not affected by this.
When using the SDL API, you aren't really supposed to be using OpenGL,
Direct3D or whatever the SDL rendererer is using, directly. You're
supposed to use the SDL API.
Now, if you want to extend SDL - add more rendering operations, add
support for another target (QuickDraw, Pixomatic, some odd console
chipset, ...) - you're in backend land. You're effectively messing
with the internal operation of SDL as a side effect of (ab)using the
same target context that the SDL renderer is using.
It's really not very different from the situation with SDL 1.2 and
OpenGL: If you want to do OpenGL rendering, you have to do all of it
yourself. (Well, except for setting up the display.) As you set up
the display for OpenGL rendering, the SDL 2D API is rendered unusable
on the display surface. To bring it back to life, you need to slap
glSDL/wrapper in between the application and SDL.
What glSDL/wrapper does is essentially what an SDL 1.3 renderer does:
It implements the SDL 2D rendering API over OpenGL, so that the
application can still use the SDL 2D calls. The only difference is
that glSDL does it compile time be means of a bunch of messy
redefinitions, whereas an SDL 1.3 renderer fills in a struct with a
bunch of low level functions at run time.
//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