From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-07-08 13:05:17
|
Per, I have not run into this before. I do know that the menus don't display when you are running in single-buffered mode, but I had not experimented with the "GL_TEXTURE_3D" flag at all. Thank you for finding this. Please do make a clean test case. John F. Fay joh...@eg... -----Original Message----- From: Per Zetterlund [mailto:pe...@fo...] Sent: Tuesday, July 08, 2003 4:16 AM To: fre...@li... Subject: [Freeglut-developer] Menu bug? Hello, The menus doesn't seem to work when GL_TEXTURE_3D is enabled. Is this a known bug, or should I try to make a clean(er) test case? Per -- pe...@fo... ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-07-08 13:08:15
|
Oh. If Chris knows about it, then please cancel my last transmission. John F. Fay joh...@eg... -----Original Message----- From: Chris Purnell [mailto:cj...@lo...] Sent: Tuesday, July 08, 2003 5:19 AM To: fre...@li... Subject: Re: [Freeglut-developer] Menu bug? On Tue, Jul 08, 2003 at 11:15:43AM +0200, Per Zetterlund wrote: > The menus doesn't seem to work when GL_TEXTURE_3D is enabled. Is this a > known bug, or should I try to make a clean(er) test case? Yes, this is known bug. -- Christopher John Purnell | I thought I'd found a reason to live http://www.lost.org.uk/ | Just like before when I was a child --------------------------| Only to find that dreams made of sand What gods do you pray to? | Would just fall apart and slip through my hands ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-07-08 16:24:47
|
I agree wholeheartedly that the menus need to go into their own subwindows. Do we do this before our release or to we hold it until the next one? I did sort of declare a feature freeze a couple of weeks ago ... John F. Fay joh...@eg... -----Original Message----- From: Steve Baker [mailto:sjb...@ai...] Sent: Tuesday, July 08, 2003 11:18 AM To: fre...@li... Subject: Re: [Freeglut-developer] Menu bug? Fay John F Contr AAC/WMG wrote: > Per, > > I have not run into this before. I do know that the menus don't > display when you are running in single-buffered mode, but I had not > experimented with the "GL_TEXTURE_3D" flag at all. Thank you for > finding this. Please do make a clean test case. Well, I think it's clear what's going on - it's what Brian and I were saying about the rendering of menu's needing to happen in a separate rendering context. Since our Menu code knows nothing about 3D textures (having been written before that was a standard part of OpenGL), it doesn't do a glDisable(GL_TEXTURE_3D) before it renders the polygons that make up the menu. Since whatever 3D texture was last applied by the application stays in effect, we'll be rendering 3D texture all over the menu. If the 3D map happens to have 100% transparency - or the colour BLACK or something in the (*,*,0.0) plane, then the menu's will come out transparent or black or whatever. It is the impossibility of successfully turning off ALL of the OpenGL state (including extensions) in freeglut's menu renderer that requires that we render the menu's in a separate window with a separate rendering context. ---------------------------- 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 sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Steve B. <sjb...@ai...> - 2003-07-08 17:26:48
|
Fay John F Contr AAC/WMG wrote: > I agree wholeheartedly that the menus need to go into their own > subwindows. Do we do this before our release or to we hold it until the > next one? I did sort of declare a feature freeze a couple of weeks ago ... I don't really know the code very well - but it sounds like a big change. I would probably punt it to 2.0.1 and just list it as a 'known bug' in 2.0.0. Note that this problem isn't unique to 3D textures - any 'oddball' rendering states that the application leaves lying around on the stack could cause similarly bizarre problems. ---------------------------- 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----- |
From: Eric S. <er...@sa...> - 2003-07-08 19:59:20
|
Steve Baker said: > Fay John F Contr AAC/WMG wrote: >> I agree wholeheartedly that the menus need to go into their own >> subwindows. Do we do this before our release or to we hold it until the >> next one? I did sort of declare a feature freeze a couple of weeks ago >> ... > > I don't really know the code very well - but it sounds like a big change. > > I would probably punt it to 2.0.1 and just list it as a 'known bug' in > 2.0.0. > > Note that this problem isn't unique to 3D textures - any 'oddball' > rendering > states that the application leaves lying around on the stack could cause > similarly bizarre problems. Agreed. We'll want to get a mostly stable release out soon, then we can do some more code cleanup. With a release, we may even get more people interested and possibly some code contributors (I don't know enough to help too much, I'm still having fun just making an OpenGL+freeglut demo. ;)). -sandalle -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 Eric Sandall | Source Mage GNU/Linux Developer er...@sa... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ |
From: Mike A. H. <mh...@ww...> - 2003-07-09 00:49:05
|
On Tue, 8 Jul 2003, Fay John F Contr AAC/WMG wrote: >Date: Tue, 8 Jul 2003 11:24:13 -0500 >From: Fay John F Contr AAC/WMG <joh...@eg...> >To: fre...@li... >Reply-To: fre...@li... >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C3456D.5E3CA1D7" >Subject: RE: [Freeglut-developer] Menu bug? > >I agree wholeheartedly that the menus need to go into their own subwindows. >Do we do this before our release or to we hold it until the next one? I did >sort of declare a feature freeze a couple of weeks ago ... While it's a rather nasty bug, after reading the thread, I think I agree with the others that it's best left for 2.0.1 or whatever is next. One thing that I can do to help the project, is once the 2.0.0 release is out (or even a reasonably complete release candidate), I can update freeglut in rawhide, and officially remove GLUT. This will result in quite wide beta testing by end users and developers IMHO. I'll try to do this as soon as everyone here thinks it is ready. Any failure cases that arise can either be fixed before the release, or deferred for the next one. Hope this helps. -- Mike A. Harris |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-10-27 15:20:00
|
If I may reply in some detail ... (1) Yes. The "||" should be a "&&". (2) I agree. I also would like to take out the "!= NULL". (3) I have no objection to rewriting the code on stylistic grounds. If it were stable and bugfree, there would be some grounds for not fiddling with it, but as it is it needs all the help it can get. John F. Fay joh...@eg... -----Original Message----- From: Richard Rauch [mailto:sf...@ol...] Sent: Monday, October 27, 2003 12:20 AM To: fre...@li... Subject: [Freeglut-developer] Menu bug? [If you don't see the point of this email, skip to the last couple of paragraphs...] Shouldn't the || in this be a &&? /* * There must be a current window and a current menu set: */ freeglut_return_if_fail( fgStructure.Window != NULL || fgStructure.Menu != NULL ); ..? I think so. If fgStructure is non-NULL, then the value of fgStructure.Menu does not matter, and the following code will execute---some of which attempts to use fgStructure.Menu. As a point of style, I would like to suggest that: x != NULL ...is harder to read than: x ...as a test for x's validity. I know that I have to think appreciably harder about the former than the latter. I believe that the existing code is a bug, and that the bug exists precisely because the "x != NULL" is more work to parse (or to construct), mentally. (Well, it's also complicated because of the odd "return if fail", which is semantically a negation. What the author presumably wanted was "If this fails or if that fails", but instead they got "if this-OR-that fails" -=> "if this-fails AND that-fails".) The menu code's bug could be fixed by simply changing || to &&. We could also get rid of the {!= NULL}s. Even better would be to write it as two freeglut_return_if_fail() operations: freeglut_return_if_fail( fgStructure.Window ); freeglut_return_if_fail( fgStructure.Menu ); IMHO, this is far clearer. I raise this general point because there's lots of code that uses the (in my eyes) obfusticating "if( x != NULL )" construct when "if( x )" is so much simpler and clearer. This is a style issue which, if addressed, will improve the code's clarity greatly at certain points. Are there any objections to changing this (as a general style improvement to the code, not just fixing the one local bug), or is the former actually preferred for some reason? -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Richard R. <sf...@ol...> - 2003-10-27 15:28:03
|
On Mon, Oct 27, 2003 at 08:49:51AM -0600, Fay John F Contr AAC/WMG wrote: > If I may reply in some detail ... > > (1) Yes. The "||" should be a "&&". Okay. I thought it through a couple of times just to be sure and decided that I had to be right and committed the change. (^& > (2) I agree. I also would like to take out the "!= NULL". I'll add that to my mental list of things to cull as I go, then. > (3) I have no objection to rewriting the code on stylistic grounds. If it > were stable and bugfree, there would be some grounds for not fiddling with > it, but as it is it needs all the help it can get. (nod) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Stephen J B. <sj...@li...> - 2003-10-27 19:53:46
|
Richard Rauch wrote: >>(2) I agree. I also would like to take out the "!= NULL". > > I'll add that to my mental list of things to cull as I go, then. It's a matter of taste - but I tend to go though putting those INTO the code while I'm tidying it up! Without the !=NULL thing, a pointer tends to look like a boolean (which it isn't). But it *is* a matter of taste. ----------------------------------------------------------------------- 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...> - 2003-10-27 21:07:18
|
On Mon, Oct 27, 2003 at 01:56:24PM -0600, Stephen J Baker wrote: > Richard Rauch wrote: > > >>(2) I agree. I also would like to take out the "!= NULL". > > > >I'll add that to my mental list of things to cull as I go, then. > > It's a matter of taste - but I tend to go though putting those INTO > the code while I'm tidying it up! I think that if the code had read: return_if_fail( ptr1 || ptr2 ); ...rather than: return_if_fail( ptr1 != NULL || ptr2 != NULL ); ...the slip of reasoning would not have occurred. > Without the !=NULL thing, a pointer tends to look like a boolean (which > it isn't). C doesn't have a real boolean. You have to imagine a boolean, which can be done as well with a pointer as with an int or char, etc. Though even with C++, I prefer this approach. Maybe my old roots as a long-standing C programmer are showing. I find it cleaner and clearer, since there is a distinguished "invalid" pointer and it acts like a "false" value, and the compiler "automatically" does this check for you. I think of it as overloading the if() expression (or overloading the truth-testing of an expression) in a natural manner. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2003-10-28 00:43:25
|
Richard Rauch wrote: > C doesn't have a real boolean. Eh? 'bool' ? bool may not be in ANSI-C (I'm not sure) - but for sure it's in ISO C99 and I don't know of any C or C++ compilers that don't support 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----- |
From: Richard R. <sf...@ol...> - 2003-10-28 20:27:33
|
On Mon, Oct 27, 2003 at 06:39:12PM -0600, Steve Baker wrote: > Richard Rauch wrote: > > >C doesn't have a real boolean. > > Eh? 'bool' ? I've only heard of that in C++. For amusement, I tried this simple file: int main (int argc, char **argv) { bool b; b = 0; return 0; } Compiling with gcc 2.95 and 3.3 gives errors. No such type as {bool}. Compiling with a C++ compiler works, of course. > bool may not be in ANSI-C (I'm not sure) - but for sure it's in ISO C99 > and I don't know of any C or C++ compilers that don't support it. Maybe GCC 3.3 is not C99 compliant. I know that ANSI/ISO C from 1989 does not have it. If GCC 3.3 is C99 compliant then this is a type defined in a header file (if it's defined at all), not a fundamental type. If it's not a fundamental type, then if (etc.) cannot be defined in terms of it. If you don't use a {bool} in an if, I'm not sure what you are supposed to use it for. (^& -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Steve B. <sjb...@ai...> - 2003-07-08 16:16:29
|
Fay John F Contr AAC/WMG wrote: > Per, > > I have not run into this before. I do know that the menus don't > display when you are running in single-buffered mode, but I had not > experimented with the "GL_TEXTURE_3D" flag at all. Thank you for > finding this. Please do make a clean test case. Well, I think it's clear what's going on - it's what Brian and I were saying about the rendering of menu's needing to happen in a separate rendering context. Since our Menu code knows nothing about 3D textures (having been written before that was a standard part of OpenGL), it doesn't do a glDisable(GL_TEXTURE_3D) before it renders the polygons that make up the menu. Since whatever 3D texture was last applied by the application stays in effect, we'll be rendering 3D texture all over the menu. If the 3D map happens to have 100% transparency - or the colour BLACK or something in the (*,*,0.0) plane, then the menu's will come out transparent or black or whatever. It is the impossibility of successfully turning off ALL of the OpenGL state (including extensions) in freeglut's menu renderer that requires that we render the menu's in a separate window with a separate rendering context. ---------------------------- 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----- |