[SDL] SDL 1.3 and rendering API state management
david at olofson.net
Sun Sep 3 04:40:11 PDT 2006
On Sunday 03 September 2006 11:12, Ryan C. Gordon wrote:
> I don't think SDL should make _any_ promises about what it will or
> won't touch in the GL stack if you are only using SDL's 2D
> facilities. Nor do I think that any add-on library should be
> changing GL state between calls. If you want to draw something, set
> your state, push some polygons, and set the state back. Otherwise,
> you're talking about locking down a fairly complicated set of
> promises (or specifying a fairly complicated set of notification
BTW, in this particular case (SDL_Advanced2D), I think it's somewhat
acceptable if the library has to track SDL revisions rather closely.
(An SDL renderer versioning API, maybe?)
After all, this started out as a discussion as to whether this stuff
belongs in SDL, or in an add-on library. In a less minimalistic and
more application specific library, the obvious solution would have
been to build this into SDL, but - provided these state sharing
issues can be dealt with nicely - an add-on/plugin approach is more
flexible and keeps the SDL core smaller, cleaner and simpler.
So, some possible solutions:
1. Make the SDL renderer interface public, so add-on
libs can plug in their own renderers.
+ Rock solid and efficient - all rendering
calls are made from a single place.
+ Allows renderers for *anything* to be
plugged in at run time.
- Existing SDL renderer features have to
be duplicated in external renderers.
2. Add a mutual state change notification interface
for SDL renderers and applications/add-on libs.
+ Easy to implement (?)
- Somewhat error prone. (How do you make
sure you're actually "sending" all required
3. Build Advanced2D into the SDL core.
+ All in one place - no state sharing issues.
+ 2D and Advanced2D code is pretty much
guaranteed to work together.
+ Less risk of different competing solutions
that won't cooperate.
- Bloats the SDL core library.
- Makes other targets much more different
from OpenGL and Direct3D. (Stuff beyond
the current API doesn't really lend itself
to real time software rendering.)
- No good if you want something else than
4. Have applications and add-on libs "manually" manage
state as needed.
- Expensive (if you save and restore
"everything" all the time), and/or error
prone and hard to debug.
- Hard to make add-on libs work together.
5. Simply don't support mixed SDL/Advanced2D rendering.
GUI toolkits and the like must be able to render
using any add-on libs they should be able to
+ Very easy.
- Doesn't help to make code reuse easier.
//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