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™.
(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™ 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 --'On Sunday 03 September 2006 20:18, Simon wrote:
