[SDL] SDL 1.3 and rendering API state management
david at olofson.net
Sun Sep 3 02:47:10 PDT 2006
On Sunday 03 September 2006 11:12, Ryan C. Gordon wrote:
> > A simple solution would be some kind of mutual notification
> > interface, so that SDL renderers can tell the application when
> > they've messed with the API state, and vice versa.
> Alternately, you can use glPushAttrib().
Well, the hard part is figuring out when to do this... I can't see any
sensible way to automate it, so for all practical matters, it's
"manual control" from the application side. Error prone and hard to
debug - especially if the offending code is not your own, but inside
various add-on libs that you're trying to use together.
> 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.
This is (sort of) fine if you're using OpenGL (or Direct3D) directly
in the application code, but what if you're "just" trying to use an
add-on library that's supposed to add some extra rendering calls?
To a user not aware of the inner workings of these things, it probably
seems very strange that various add-on libs all using SDL and
supporting the same rendering APIs still just won't work together
without various mysterious rituals.
I think the current situation with SDL 1.2, OpenGL, glSDL, various GUI
toolkits etc, is hindering code reuse and making SDL tricky to use -
and there isn't even a good technical reson for these problems in the
first place! They are just side effects of SDL 1.2 not being designed
to deal with these issues.
> Otherwise, you're talking about locking down a fairly complicated
> set of promises (or specifying a fairly complicated set of
> notification APIs).
That's exactly why I'm suggesting either a notification interface, or
simply having the add-on libraries plugging in new SDL renderers,
that implement the standard SDL 2D API in suitable ways. Both
solutions relieve both SDL and the add-on libs from the burden of
making any promises; the first by allowing both sides to say when
they've changed things, and the second by simply turning add-on
rendering libs into plug-in SDL renderers.
//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