[SDL] SDL 1.3 and rendering API state management

[David Olofson]

On Monday 04 September 2006 20:03, Bob Pendleton wrote:
[...]
> Apologies for not editing this post down, but I wasn't sure what to
> edit out :-) My suggestion is that the advanced SDL 2d/3d (what
> ever) should just cause and error termination if they are called on
> an OpenGL surface. There is *never any reason* to use them on an
> OpenGL surface. 

Well, as long as it's strictly forbidden to use them in GUI toolkits 
and other add-on libs. And "basic" SDL 2D is out too, so basically, 
if you use OpenGL (or Direct3D), you're on your own - no SDL add-on 
libs will be able to render over your display, unless they happen to 
natively support your 3D API(s) of choice.

I believe it's easier and safer to wire existing libs to a custom 
implementation of the SDL 2D, Advanced2D and/or whatever API, than to 
port the libs. Also, if you decide to switch to alternative lib or 
newer version or something down the road, your porting effort becomes 
more or less wasted time, whereas if you had your own SDL *2D 
implementation, you could just switch lib and get on with the real 
work.


> OTOH No reason they can't work on software surfaces. But, it is
> clear that they will mess up the rendering context on an OpenGL
> surface.

They won't do anything beyond your control if their backends call into 
your own rendering code. :-)


> The alternative is to post a context lost event (which is 
> something Windows users have wanted for a long time) and do what
> ever they do. But, that is asking for problems. Another alternative
> behavior is to error off unless the programmer has asked for context
> lost events. Then you know the programmer is ready to handle the
> context problems caused by using the SDL APIs when they really
> should not use them.

Yeah, I like the general idea of somehow making it hard for developers 
to not realize there is a problem to deal with.

The context lost event is effectively the notification system I had in 
mind, only much simpler and probably quite sufficient to deal with 
the problem.

Not sure what happens if you have more than two clients - the (SDL 
core or other) renderer and the application - but OTOH, you should 
never need that if things like Advanced2D can implement both the SDL 
2D API and it's own extensions in the same renderer. (Well, maybe if 
we end up with more than one rendering extension lib and people want 
to mix libs that don't use the same rendering extension lib, but the 
idea with Advanced2D is that it should cover pretty much anything 
that isn't best done with the normal SDL 2D API or directly over a 3D 
API. :-)


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