From: Fay J. F C. AAC/W. <joh...@eg...> - 2004-10-05 16:27:52
|
Brian, Before you get too far let me send you my "freeglut_init.c" that already has a bunch of changes to "glutInitDisplayString". I thought I had sent them to you already but I don't see them in CVS. Give me a bit of time to make sure I have them right. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Steve Baker Sent: Tuesday, October 05, 2004 10:16 AM To: fre...@li... Subject: Re: [Freeglut-developer] support for GL_AUX buffers Brian Paul wrote: <snip> > > One of these would get OR'd with the other flags passed to > glutInitDisplayNode() to indicate how many AUX buffers are desired. > Similarly, glutInitDisplayString() would take new 'aux' tokens. Yeah - that seems like a reasonable thing to want to do. Go for it! ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-02-10 17:54:35
|
Brian, Someone has contacted me asking about the status of the auxiliary color buffers. Would it be possible to put in the patch you mentioned? John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Brian Paul Sent: Tuesday, October 05, 2004 9:59 AM To: fre...@li... Subject: [Freeglut-developer] support for GL_AUX buffers A while back I added support for AUX color buffers in Mesa. When I went to test it, I discovered that GLUT has no support for choosing visuals/pixel formats that support AUX buffers. Adding support for AUX buffers should be pretty easy and would be a good project for a beginner to get his feet wet. If nobody volunteers, I'll try to check in a patch someday. My expectation is that we'd define a few new tokens for glutInitDisplay(): #define GLUT_AUX1 0x0400 #define GLUT_AUX2 0x0800 #define GLUT_AUX3 0x1000 #define GLUT_AUX4 0x2000 One of these would get OR'd with the other flags passed to glutInitDisplayNode() to indicate how many AUX buffers are desired. Similarly, glutInitDisplayString() would take new 'aux' tokens. Internally, we'd basically just have to update the visual selection code a bit. -Brian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Brian P. <bri...@tu...> - 2005-02-10 20:47:13
|
Sure. I'll try to get to it later. -Brian Fay John F Contr AAC/WMG wrote: > Brian, > > Someone has contacted me asking about the status of the > auxiliary color buffers. Would it be possible to put in the patch you > mentioned? > > John F. Fay > joh...@eg... > 850-729-6330 > -----Original Message----- > From: fre...@li... > [mailto:fre...@li...] On Behalf Of > Brian Paul > > Sent: Tuesday, October 05, 2004 9:59 AM > To: fre...@li... > Subject: [Freeglut-developer] support for GL_AUX buffers > > > A while back I added support for AUX color buffers in Mesa. When I > went to test it, I discovered that GLUT has no support for choosing > visuals/pixel formats that support AUX buffers. > > Adding support for AUX buffers should be pretty easy and would be a > good project for a beginner to get his feet wet. If nobody > volunteers, I'll try to check in a patch someday. > > My expectation is that we'd define a few new tokens for glutInitDisplay(): > > #define GLUT_AUX1 0x0400 > #define GLUT_AUX2 0x0800 > #define GLUT_AUX3 0x1000 > #define GLUT_AUX4 0x2000 > > One of these would get OR'd with the other flags passed to > glutInitDisplayNode() to indicate how many AUX buffers are desired. > Similarly, glutInitDisplayString() would take new 'aux' tokens. > > Internally, we'd basically just have to update the visual selection > code a bit. > > -Brian > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Brian P. <bri...@tu...> - 2005-02-11 14:58:34
|
<sigh> this is taking longer than expected. I'm having trouble compiling the latest freeglut sources. I recently upgraded to FC3 and the 3.4.2 gcc compiler is more picky about assignments between object pointers and function pointers. For example: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/X11R6/include -g -O2 -Wall -pedantic -Werror -MT libglut_la-freeglut_ext.lo -MD -MP -MF .deps/libglut_la-freeglut_ext.Tpo -c freeglut_ext.c -fPIC -DPIC -o .libs/libglut_la-freeglut_ext.o freeglut_ext.c:40: warning: ISO C forbids conversion of function pointer to object pointer type freeglut_ext.c:41: warning: ISO C forbids conversion of function pointer to object pointer type [about 100 other warnings omitted] I had to fix a few instances of this in Mesa after I upgraded. I'm fixing the freeglut sources now and will check in my changes soon. -Brian Brian Paul wrote: > > Sure. I'll try to get to it later. > > -Brian > > Fay John F Contr AAC/WMG wrote: > >> Brian, >> >> Someone has contacted me asking about the status of the >> auxiliary color buffers. Would it be possible to put in the patch you >> mentioned? >> >> John F. Fay >> joh...@eg... >> 850-729-6330 >> -----Original Message----- >> From: fre...@li... >> [mailto:fre...@li...] On Behalf Of >> Brian Paul >> >> Sent: Tuesday, October 05, 2004 9:59 AM >> To: fre...@li... >> Subject: [Freeglut-developer] support for GL_AUX buffers >> >> >> A while back I added support for AUX color buffers in Mesa. When I >> went to test it, I discovered that GLUT has no support for choosing >> visuals/pixel formats that support AUX buffers. >> >> Adding support for AUX buffers should be pretty easy and would be a >> good project for a beginner to get his feet wet. If nobody >> volunteers, I'll try to check in a patch someday. >> >> My expectation is that we'd define a few new tokens for >> glutInitDisplay(): >> >> #define GLUT_AUX1 0x0400 >> #define GLUT_AUX2 0x0800 >> #define GLUT_AUX3 0x1000 >> #define GLUT_AUX4 0x2000 >> >> One of these would get OR'd with the other flags passed to >> glutInitDisplayNode() to indicate how many AUX buffers are desired. >> Similarly, glutInitDisplayString() would take new 'aux' tokens. >> >> Internally, we'd basically just have to update the visual selection >> code a bit. >> >> -Brian >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >> Use IT products in your business? Tell us what you think of them. Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out >> more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > > > ------------------------------------------------------- > 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. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Brian P. <bri...@tu...> - 2005-02-11 15:23:06
|
OK, I've checked in fixes for all the compilation problems and added AUX buffer support. I wasn't sure how to implement it for WGL so someone else will have to do that. -Brian |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-02-10 21:20:42
|
Great, thank you very much. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Brian Paul Sent: Thursday, February 10, 2005 2:49 PM To: fre...@li... Subject: Re: [Freeglut-developer] support for GL_AUX buffers Sure. I'll try to get to it later. -Brian Fay John F Contr AAC/WMG wrote: > Brian, > > Someone has contacted me asking about the status of the > auxiliary color buffers. Would it be possible to put in the patch you > mentioned? > > John F. Fay > joh...@eg... > 850-729-6330 > -----Original Message----- > From: fre...@li... > [mailto:fre...@li...] On Behalf Of > Brian Paul > > Sent: Tuesday, October 05, 2004 9:59 AM > To: fre...@li... > Subject: [Freeglut-developer] support for GL_AUX buffers > > > A while back I added support for AUX color buffers in Mesa. When I > went to test it, I discovered that GLUT has no support for choosing > visuals/pixel formats that support AUX buffers. > > Adding support for AUX buffers should be pretty easy and would be a > good project for a beginner to get his feet wet. If nobody > volunteers, I'll try to check in a patch someday. > > My expectation is that we'd define a few new tokens for glutInitDisplay(): > > #define GLUT_AUX1 0x0400 > #define GLUT_AUX2 0x0800 > #define GLUT_AUX3 0x1000 > #define GLUT_AUX4 0x2000 > > One of these would get OR'd with the other flags passed to > glutInitDisplayNode() to indicate how many AUX buffers are desired. > Similarly, glutInitDisplayString() would take new 'aux' tokens. > > Internally, we'd basically just have to update the visual selection > code a bit. > > -Brian > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > ------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-02-14 19:31:37
|
Great, thank you very much. I'm checking it out right now. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Brian Paul Sent: Friday, February 11, 2005 9:25 AM To: fre...@li... Subject: Re: [Freeglut-developer] support for GL_AUX buffers OK, I've checked in fixes for all the compilation problems and added AUX buffer support. I wasn't sure how to implement it for WGL so someone else will have to do that. -Brian ------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-02-14 20:25:25
|
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. Meanwhile, the "fgChooseVisual" function sets the "GLX_RED_SIZE", "GLX_GREEN_SIZE", and "GLX_BLUE_SIZE fields to one each while "fgSetupPixelFormat" sets the "cRedBits", "cGreenBits", and "cBlueBits" fields all to zero. If anybody knows what is going on here, I would appreciate it if he could explain it. Failing that, I propose to try making the system rational (keeping the present X behavior as the default--and testing Windows, hoping that nothing breaks) while implementing the ability to pass values in. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Brian Paul Sent: Friday, February 11, 2005 9:25 AM To: fre...@li... Subject: Re: [Freeglut-developer] support for GL_AUX buffers OK, I've checked in fixes for all the compilation problems and added AUX buffer support. I wasn't sure how to implement it for WGL so someone else will have to do that. -Brian ------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Brian P. <bri...@tu...> - 2005-02-14 22:50:09
|
freeglut's glutInitDisplayString() looks kind of hokey to me. I have a feeling it needs a total rewrite. -Brian 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. Meanwhile, the "fgChooseVisual" > function sets the "GLX_RED_SIZE", "GLX_GREEN_SIZE", and "GLX_BLUE_SIZE > fields to one each while "fgSetupPixelFormat" sets the "cRedBits", > "cGreenBits", and "cBlueBits" fields all to zero. > > If anybody knows what is going on here, I would appreciate it if > he could explain it. Failing that, I propose to try making the system > rational (keeping the present X behavior as the default--and testing > Windows, hoping that nothing breaks) while implementing the ability to > pass values in. > > John F. Fay > joh...@eg... > 850-729-6330 > -----Original Message----- > From: fre...@li... > [mailto:fre...@li...] On Behalf Of > Brian Paul > > Sent: Friday, February 11, 2005 9:25 AM > To: fre...@li... > Subject: Re: [Freeglut-developer] support for GL_AUX buffers > > > OK, I've checked in fixes for all the compilation problems and added > AUX buffer support. I wasn't sure how to implement it for WGL so > someone else will have to do that. > > -Brian > > > > ------------------------------------------------------- > 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. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: Richard R. <sf...@ol...> - 2005-02-15 00:02:16
|
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/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-02-15 14:24:06
|
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 joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Richard Rauch Sent: Monday, February 14, 2005 6:02 PM To: fre...@li... 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Stephen J B. <sj...@li...> - 2005-02-15 15:24:13
|
Fay John F Contr AAC/WMG wrote: > 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. This is a really difficult area. The problem is that you won't always get what you ask for - and it's hard to control which of the necessary compromises best suits the application. If the application demands (say) "red 8 green 8 blue 8 stencil 8" and the hardware only supports either "red 4 green 4 blue 4 stencil 8" or either "red 8 green 8 blue 8 stencil 0" - which should we pick? It's impossible to know whether the application has fallback code for the lack of a stencil buffer that works well or not. If it does have decent work-arounds for the lack of stencil then we should give it the best colour quality - but if the application falls apart if there is no stencil buffer then we should certainly compromise image quality to give it to him. In reality, it's even worse than that because there are depth buffers, alpha buffers, stereo buffers, etc. The problem is also complicated by the fact that giving the application MORE than it asks for is often a bad thing. eg If you gave it 24 bit RGB and 24 bit Z when it only asked for 16 bit RGB and 24 bit Z, that might have a severe impact on performance if the underlying hardware writes 16 bits at a time and you might have been better off giving him 16 bit RGB and 16 bit Z. However, we don't know whether he asked for 24 bit Z because he actually NEEDED that much precision - or whether he merely wanted to make sure he didn't get unecessarily poor Z precision on a system that could in fact have handled it perfectly well. > In the present implementation, "red", "green", and > "blue" are ignored completely while "stencil" and "depth" set on/off > flags. In the end, glutInitDisplayString needs to do whatever GLUT did. Doing 'better' isn't necessarily a good thing because 'better' is also 'different' - and because we don't truly know what the application wants, being different will often mean we are actually doing worse. But extending this scheme to actually be useful is very difficult. IMHO, a better API would be one in which the application asks for something and is returned a list of available visuals, sorted in some way such that the available settings that are 'closest' to his requirements are at the top of the list. Naive applications could then simply pick the topmost one from the list and get essentially the behavior we are offering now - a more sophisticated application (that perhaps REQUIRES some kind of stencil buffer come-what-may) could search down from the top of the list until it finds one that meets it's minimum requirements - and a super-sophisticated application could just ask for any old combination of settings and search the entire list itself. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Richard R. <sf...@ol...> - 2005-02-16 02:52:43
|
On Tue, Feb 15, 2005 at 08:24:00AM -0600, Fay John F Contr AAC/WMG wrote: > What I am saying is that "glutInitDisplayString" looks like it should acc= ept > something like the following: >=20 > glutInitDisplayString ( "red 8 green 4 blue 12 stencil 24 depth 8" ) ; (nod) I know. That's why I said that it is more flexible than the bit-mask approach. (^& I had the impression that an equal sign (=3D) was used for that in the original GLUT, but as I said I haven't used the feature much myself, and hadn't looked at it since I rewrote this function in OpenGLUT last year. I did not add numeric support to OpenGLUT's version of this when I did the rewrite; I focused on the egregiously weird general token-parsing. --=20 "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2005-02-15 15:57:59
|
Looking at the GLUT code, I see that it gets better (or more involved). GLUT appears to support something along the lines of glutInitDisplayString ( "red<=8 green=4 blue=12 stencil=24 depth=8" ) ; and then searches for the best fit available. John F. Fay joh...@eg... 850-729-6330 -----Original Message----- From: fre...@li... [mailto:fre...@li...] On Behalf Of Stephen J Baker Sent: Tuesday, February 15, 2005 9:24 AM To: fre...@li... Subject: Re: [Freeglut-developer] support for GL_AUX buffers Fay John F Contr AAC/WMG wrote: > 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. This is a really difficult area. The problem is that you won't always get what you ask for - and it's hard to control which of the necessary compromises best suits the application. If the application demands (say) "red 8 green 8 blue 8 stencil 8" and the hardware only supports either "red 4 green 4 blue 4 stencil 8" or either "red 8 green 8 blue 8 stencil 0" - which should we pick? It's impossible to know whether the application has fallback code for the lack of a stencil buffer that works well or not. If it does have decent work-arounds for the lack of stencil then we should give it the best colour quality - but if the application falls apart if there is no stencil buffer then we should certainly compromise image quality to give it to him. In reality, it's even worse than that because there are depth buffers, alpha buffers, stereo buffers, etc. The problem is also complicated by the fact that giving the application MORE than it asks for is often a bad thing. eg If you gave it 24 bit RGB and 24 bit Z when it only asked for 16 bit RGB and 24 bit Z, that might have a severe impact on performance if the underlying hardware writes 16 bits at a time and you might have been better off giving him 16 bit RGB and 16 bit Z. However, we don't know whether he asked for 24 bit Z because he actually NEEDED that much precision - or whether he merely wanted to make sure he didn't get unecessarily poor Z precision on a system that could in fact have handled it perfectly well. > In the present implementation, "red", "green", and > "blue" are ignored completely while "stencil" and "depth" set on/off > flags. In the end, glutInitDisplayString needs to do whatever GLUT did. Doing 'better' isn't necessarily a good thing because 'better' is also 'different' - and because we don't truly know what the application wants, being different will often mean we are actually doing worse. But extending this scheme to actually be useful is very difficult. IMHO, a better API would be one in which the application asks for something and is returned a list of available visuals, sorted in some way such that the available settings that are 'closest' to his requirements are at the top of the list. Naive applications could then simply pick the topmost one from the list and get essentially the behavior we are offering now - a more sophisticated application (that perhaps REQUIRES some kind of stencil buffer come-what-may) could search down from the top of the list until it finds one that meets it's minimum requirements - and a super-sophisticated application could just ask for any old combination of settings and search the entire list itself. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org ------------------------------------------------------- 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. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |