[SDL] stable SDL GUI

Joseph Carter knghtbrd at bluecherry.net
Tue Jul 2 11:40:01 PDT 2002


On Tue, Jul 02, 2002 at 05:53:35PM +0200, David Olofson wrote:
> [...]
> >If you're using software rendering only, it's pretty useful.  If you're
> >using OpenGL, it's completely useless.  You might be able to get it to
> >work with glSDL maybe,
> 
> Yeah - but then one would have to make glSDL cooperat nicely with "user"
> OpenGL code, and that's not a high priority for me, at least. It's
> beyond the scope of glSDL.
> 
> (Keep an eye on the higher levels of the "Spitfire Engine"; graphics
> engine of Kobo Deluxe - it's about to get native OpenGL support.)

(Your lines aren't warpping, David..)

It seems that making glSDL work with user OpenGL code wouldn't be too
hard.  I was already making the assumption that the OpenGL code in
question would simply restore the state to that which glSDL expects, but
if you want to make that an officially supported path at some point, you
can provide functions to query/save/restore OpenGL's state.  You can just
push the current transformation matrix and pop it afterward.  Things like
the current color, blendfunc, etc, can be assumed to need resetting by the
user code..

Generally we tend to keep our color set to white, our frustum set to the
user's chosen aspect/FOV, blending disabled with the blendfunc set to
alpha blending (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA), etc..  If any part
of our engine changes these, it is expected that it will set them back
when it's done.  We lose a little performance because we still support
non-multitexture, so we're always turning on and off a second TMU if
present, but it's an acceptable (under 1% when GPU limited) tradeoff for
people who are already getting a 16% performance boost (again GPU limited,
we're almost always CPU limited though) from having multitexture in the
first place..  =)


Thankfully Neither is specced to have higher requirements.  If you want to
run it, you _will_ need ARB multitexture, texture env combine, dot3 bump
mapping, and half a dozen other things that any card worth using already
has, but which aren't supported by idiot vendors like SiS..  It'll take us
at least another year to finish Neither.  If stupid vendors don't manage
to aquire a few clues by then, it's Not My Problem(TM), buy an NVIDIA
card.  Hey, by then even ATI might be stable enough - they are apparently
at least making some effort to produce a quality product for a change.  ;)


> > but in the end I think I'd rather see yet another
> >GUI project which supported both OpenGL and software rendering.  Such a
> >thing is on my todo list at some point.
> 
> Same here, although I'm thinking more along the lines of a
> GtkCanvas/Flash hybrid, specifically designed for "weird" and flashy
> GUIs of the kind seen in games, media players and audio applications.

I was hoping for something very simple and clean.  As with other things I
do because I'd rather not see people using the alternatives, I'd probably
BSD license the thing.  (Mental reminder: actually finish the docs for
DynGL 3 and upload the thing to a site somewhere already!)


> As a result of taking active part in a discussion on "audio GUIs"
> (VST/DX style stuff) on another list, I got contacted by the lead
> developer of an OpenGL only toolkit to be released soon. Might be a
> better idea than starting from scratch, but I can't really tell at this
> point.
> 
> (Contact me off the list for details on my design, or whatever.)

Interesting...  =)

-- 
Joseph Carter <knghtbrd at bluecherry.net>       My opinions are always right
 
Guns don't kill people.  It's those damn bullets.  Guns just make them go
really really fast.
        -- Jake Johanson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020702/a5462496/attachment-0008.pgp>


More information about the SDL mailing list