[SDL] SDL 1.3 and rendering API state management

David Olofson david at olofson.net
Mon Sep 4 16:21:32 PDT 2006


On Monday 04 September 2006 23:41, Bob Pendleton wrote:
> On Mon, 2006-09-04 at 22:58 +0200, David Olofson wrote:
> > 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.
> 
> OK, here I see we have two very different ways of looking at things.
> Remember that I have spent several full time months each of the last
> 2 years working on adding multiple windows to SDL. I got it working
> the way I want it on X11. Right now I am just sitting here biting my
> tongue hoping SDL 1.3 will not undo all the work I have done.

I'm not sure how different that part of SDL 1.3 really is from SDL 
1.2. All I know for sure is that 1.3 does support multiple windows.


> The right way to do GUI tool kits is to have multiple windows and
> windows within windows.

Well, it's the *traditional* way, but I'm not sure it's the right way 
for typical fullscreen games and similar multimedia applications.

Indeed, if windows can be shaped, have alpha channels etc, the visible 
result can be the same. However, if there are only rectangular opaque 
windows, it only really works for very basic GUI stuff. No fancy 
non-rectangular widgets, translucent selectors and stuff - but that 
seems to be what everyone expects these days.


> The way I implemented it some windows can be normal SDL 2D windows
> and some can be 3D OpenGL windows with each OpenGL window having its
> own context. This way you can have any mixture of 2D and 3D on the
> screen that you want. You can have 3D pop ups over 2D and 2D pop ups
> over 3D. You can have a 3D window as part of your screen with a nice
> tree widget in a 2D window next to the 3D window.

For someone like me, who tends to (ab)use SDL for anything graphics 
related, this is exactly what's needed to finally eliminate the need 
for any other graphics solutions whatsoever. :-)


> I think that solves the problem you are talking about here.

It does handle some cases, but considering the current state of widely 
available windowing systems, I don't see how it can reliably support 
the kind of "tight" visual integration expected from a modern game 
GUI. AFAIK, Mac OS X is the only widely available platform that can 
actually do live compositing of windows while serious stuff is going 
on. Try making a "live" window translucent on anything else, and see 
smooth animation turn slideshow...


> Also, it makes it possible to build powerful GUI toolkits without
> putting one into SDL. And, better yet, I have permission to add this
> to SDL after 1.3 is released.

I really hope that works out properly.


//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 mailing list