What I am saying is that "glutInitDisplayString" looks like it should accept something like the following:

  glutInitDisplayString ( "red 8 green 4 blue 12 stencil 24 depth 8" ) ;

but it doesn't.  In the present implementation, "red", "green", and "blue" are ignored completely while "stencil" and "depth" set on/off flags.  Then when selecting a visual in X or a pixel format in Windows, the "red size," "green size," and "blue size" are hard-coded to one in X or zero in Windows.  If the stencil bit is set, the X implementation sets the "stencil size" to one while in Windows it is set to eight whether or not the "stencil" flag is set.  Similarly, the "depth size" is set to 24 in Windows under all circumstances while in X it is set to one if the "depth" flag is set.

John F. Fay
-----Original Message-----
From: freeglut-developer-admin@lists.sourceforge.net [mailto:freeglut-developer-admin@lists.sourceforge.net] On Behalf Of Richard Rauch

Sent: Monday, February 14, 2005 6:02 PM
To: freeglut-developer@lists.sourceforge.net
Subject: Re: [Freeglut-developer] support for GL_AUX buffers

On Mon, Feb 14, 2005 at 02:25:15PM -0600, Fay John F Contr AAC/WMG wrote:
> Gentlemen,
>       This auxiliary buffer support is opening a small can of worms for
> me.  In particular, I am looking at "glutInitDisplayMode" and
> "glutInitDisplayString" as they compare to "fgChooseVisual (for X) and
> "fgSetupPixelFormat" (for Win32).  The "glutInitDisplayMode" function sets a
> bitmap variable to an input variable which is (presumably) also a bitmap.
> The "glutInitDisplayString" function parses tokens.  On the other hand, the
> other two functions are looking not just for bit settings but also for
> numerical values.  For example, the tokens "red", "green", and "blue" are
> supposed to specify buffer precisions in bits.  The "glutInitDisplayMode"
> does not have anything like a capability to capture this information while
> "glutInitDisplayString" could parse the next token but instead does nothing.

I think that glutInitDisplayString() is far more general and flexible.  It's
one downside is that there is no comppile-time check for typos.

I haven't really used it, though.  Are you saying that it doesn't work in
practice, or only that it is not doing all that its design permits?

  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/

SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
Freeglut-developer mailing list