[SDL] SDL 1.3 and rendering API state management

[David Olofson]

On Sunday 03 September 2006 20:18, Simon wrote:
> > Why not do it properly while we're at it? Unless there is a clean
> > way of getting "normal" SDL code to play along with code using
> > OpenGL or Direct3D directly, we're not really improving the
> > situation much compared to SDL 1.2.
> 
> I agree, right now I feel as if the library would "behave" correctly 
> with other library, until the developer decide they don't anymore
> and start mixing render context and so on.  But this is to be
> expected.

It depends on who the "developer" is, I suppose... There's a 
difference between people who just want to use a bunch of high level 
libraries together to get the job done, and those who implement their 
own renderers. There are few reasons to do the latter. In fact, I can 
think of only two right now (and they're closely related):

	1) You want to implement extensions to the SDL 2D
	   rendering API that cannot be layered cleanly
	   above an existing SDL renderer. (That's what I'm
	   trying to do right now.)

	2) You're doing a full 3D game (OpenGL or Direct3D)
	   and want to wire the SDL 2D calls into your
	   engine, so you can integrate add-on libs that rely
	   on these calls.

If you're not trying to do something like the above, you should, as 
far as is realistically possible, *never* have to worry about 
interoperability of SDL add-on libs, IMNSHO. It should Just Work(TM). 
(So we don't have to respond to the same "It doesn't work!" posts all 
the time. ;-)

If you *are* doing something like the aforementioned hardcore hacking, 
there's really no way escaping the low level details. Fortunately, if 
you're into that stuff, you most probably understand the nature of 
these issues. You just need the tools to deal with them properly. 
Also, by using these tools properly, it should be easy to end up with 
a final product that Just Works(TM) for others who just want to plug 
it into their SDL applications.


> There must be a way inside SDL to "regulate" the use of extra
> libraries. Right now it seems to be an almost perfect free-for-all.

Well, yeah, when it comes to rendering in SDL 1.2, it's pretty much 
only explicit and specific cooperation between libs, or nothing. (You 
*can* layer GUI libs and stuff over glSDL, but that's only because 
glSDL "fakes" polymorphism at compile time.)


[...]
> I'm thinking about a way to monitor the state changes and a
> convenient way to deal with them (change them back, save
> state/restore state, etc...)

It's not too hard to keep track of changes, I think. SDL just keeps 
track of which renderer is using the context, and when another 
renderer takes over, a callback notifies the new renderer so it can 
restore anything that has been changed since the last time that 
renderer had the context.

However, unless similarities between the states as set up by different 
renderers are known, it becomes as simple as "Switched renderer? 
Restore all state data!"

I suppose one could analyze the state as initialized by each renderer, 
to optimize away pointless reloads of identical state data, but is it 
really worth the effort? It probably is IFF there is extremely 
frequent renderer changes - like one or two small primitives from 
each renderer, hundreds or thousands of times per frame. I doubt this 
will ever be an issue in actual application code, though I can 
certainly think of a bunch of ways of creating situations like 
that...

So, perhaps all we need to do is keep track of which renderer is using 
each context, and notify the "new" renderer whenever there is a 
switch. (That is, call it's ReinitContext() method or something.)


> And besides, if new functionality is given to us to the price of
> some complication, I'm sure this is a deal some of us can agree
> with! ;)

Well, yeah, but I think it's generally a good idea to try to simplify 
things rather than complicate them. ;-)

Or rather, I think it's possible to pretty much bridge the 2D/3D gap 
without making SDL harder to use. It's not a trivial problem, but 
that only makes it more important that SDL helps developers to deal 
with it.


All that said, I still think runtime plugin renderers is a good idea. 
It can be used to solve the "extended renderer" problem in an 
efficient and rock solid way (by simply not having multiple renderers 
on one context) - but it can also be used to implement support for 
new targets and other things that you otherwise cannot do without 
modifying SDL.


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