[SDL] SDL 1.3 and rendering API state management

[David Olofson]

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  --'