[SDL] Re: wxWindows

Daniel Phillips phillips at arcor.de
Tue Jan 28 08:20:01 PST 2003


On Tuesday 28 January 2003 11:04, Gib Bogle wrote:
> I just installed FLTK on W2000.  I built and tested the OpenGL samples,
> and they look OK.  But I have run into what appears to be a limitation.
> Adding glutFullScreen() to a demo program makes it almost, but not
> quite, full screen.  The Windows toolbar is left on the screen, as is
> the Office bar on the right edge.  I can't see how to display the OpenGL
> scene on a bare screen, which I need.  If you know how to do this,
> please let me know.  (Should we take this non-SDL discussion off the
> list?).

It's not a non-SDL discussion yet :-)

Glut doesn't go fully-fullscreen on Linux either.  Anyway, glut is simply the 
wrong interface for me.  Its widget set has a tiny fraction of the 
functionality of FLTK's and has only one mode of operation: embedded in the 
OpenGL surface.  FLTK looks capable of running either in the OpenGL surface 
or outside, or both at the same time.  (Note: I have not tried this yet, but 
soon.)

It may be a small thing, but I don't like having the widget set run my event 
dispatch loop for me.  My application is not widget-centric, it is rendering 
and realtime response-centric, so I want to run the main loop myself thanks.  
FLTK lets me do this, glut does not.

Running the dispatch loop myself instead of letting the widget set do it 
makes a bunch of interface glue go away.  I don't have to register an idle 
routine or any of the usual callbacks, I don't have to have a separate 
function for every different kind of gui event, I can centralize my logic for 
deciding when the screen needs refreshing, etc.  The bottom line is, keeping 
the main loop in my own program makes it shorter and gives it more accurate 
control at the same time, so this seems fundamentally right, and conversely, 
the traditional callback way of doing it seems fundamentally silly.

Glut provides some basic text rendering capability inside the OpenGL surface, 
which is the only feature of glut I use at present.  Really, this should be a 
separate library, with a lot more flexibility and higher rendering quality

Glut's basic polyhedra drawing is something you either just want to code 
inline in your application, or you want way more capability, such as 
constructive solid geometry, scene graph, etc.  Basic polyhedra are only 
useful for demos, and simple ones at that.

Glut's window management is pretty basic, so is SDL's.  But SDL caters better 
to the need to support both blitting and OpenGL drawing to the same surface 
and will handle color depth mismatches for you, so SDL does quite a bit to 
cut down on interface hassles.

Glut has filled an important niche in the past in that it gives you a way to 
run the same OpenGL program just about everywhere, gives you enough of a gui 
to set some options, enough text to communicate with the user, and that's 
about it.  Enough for then, but not enough for today, plus its interfaces are 
more verbose than necessary.  So, a big thankyou to Mark Kilgard for 
supplying this important component and making it easy to get started writing 
OpenGL apps, but for me it's a thing of the past.

I tried a little experiment on this FLTK+SDL demo:

   http://www.turricane.org/~wizard/projects/fltk-demo/

I added the SDL_FULLSCREEN flag where it creates the SDL window.  The result 
is interesting: the application goes to fullscreen, displays the SDL window 
briefly, then wham, it's back in windowed mode as the FLTK window opens.  OK, 
I was asking for something impossible and at least it did not crash.  Now, 
what do I have to do to get the FLTK window to open up inside the fullscreen 
SDL+OpenGL surface when the app is fullscreen, and outside when its not?  I 
believe I can do it, but it's going to require some work.  This is the real 
test of whether I have the right widget set.

Regards,

Daniel




More information about the SDL mailing list