pyopengl-users Mailing List for PyOpenGL (Page 117)
Brought to you by:
mcfletch
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(81) |
Oct
(41) |
Nov
(55) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(34) |
Feb
(3) |
Mar
(16) |
Apr
(5) |
May
(10) |
Jun
(13) |
Jul
(24) |
Aug
(14) |
Sep
(14) |
Oct
(9) |
Nov
(10) |
Dec
(16) |
2003 |
Jan
(25) |
Feb
(59) |
Mar
(9) |
Apr
(21) |
May
(54) |
Jun
(4) |
Jul
(16) |
Aug
(19) |
Sep
(19) |
Oct
(15) |
Nov
(13) |
Dec
(22) |
2004 |
Jan
(19) |
Feb
(8) |
Mar
(20) |
Apr
(16) |
May
(13) |
Jun
(18) |
Jul
(18) |
Aug
(14) |
Sep
(24) |
Oct
(47) |
Nov
(20) |
Dec
(10) |
2005 |
Jan
(23) |
Feb
(31) |
Mar
(11) |
Apr
(29) |
May
(18) |
Jun
(7) |
Jul
(11) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(11) |
Dec
(7) |
2006 |
Jan
(7) |
Feb
(8) |
Mar
(15) |
Apr
(3) |
May
(8) |
Jun
(25) |
Jul
(19) |
Aug
(3) |
Sep
(17) |
Oct
(27) |
Nov
(24) |
Dec
(9) |
2007 |
Jan
(6) |
Feb
(43) |
Mar
(33) |
Apr
(8) |
May
(20) |
Jun
(11) |
Jul
(7) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(15) |
Dec
(18) |
2008 |
Jan
(14) |
Feb
(6) |
Mar
(6) |
Apr
(37) |
May
(13) |
Jun
(17) |
Jul
(22) |
Aug
(16) |
Sep
(14) |
Oct
(16) |
Nov
(29) |
Dec
(13) |
2009 |
Jan
(7) |
Feb
(25) |
Mar
(38) |
Apr
(57) |
May
(12) |
Jun
(32) |
Jul
(32) |
Aug
(35) |
Sep
(10) |
Oct
(28) |
Nov
(16) |
Dec
(49) |
2010 |
Jan
(57) |
Feb
(37) |
Mar
(22) |
Apr
(15) |
May
(45) |
Jun
(25) |
Jul
(32) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(11) |
Dec
(28) |
2011 |
Jan
(35) |
Feb
(39) |
Mar
|
Apr
(25) |
May
(32) |
Jun
(17) |
Jul
(29) |
Aug
(10) |
Sep
(26) |
Oct
(9) |
Nov
(28) |
Dec
(4) |
2012 |
Jan
(24) |
Feb
(47) |
Mar
(4) |
Apr
(8) |
May
(9) |
Jun
(6) |
Jul
(4) |
Aug
(1) |
Sep
(4) |
Oct
(28) |
Nov
(2) |
Dec
(2) |
2013 |
Jan
(11) |
Feb
(3) |
Mar
(4) |
Apr
(38) |
May
(15) |
Jun
(11) |
Jul
(15) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
(3) |
Dec
(14) |
2014 |
Jan
(24) |
Feb
(31) |
Mar
(28) |
Apr
(16) |
May
(7) |
Jun
(6) |
Jul
(1) |
Aug
(10) |
Sep
(10) |
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(19) |
Dec
|
2016 |
Jan
(6) |
Feb
(1) |
Mar
(7) |
Apr
|
May
(6) |
Jun
|
Jul
(3) |
Aug
(7) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
(6) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: <no...@so...> - 2001-09-15 20:22:57
|
Support Requests item #461872, was opened at 2001-09-15 10:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=461872&group_id=5988 Category: install Group: None Status: Open Priority: 5 Submitted By: Greg Welch (gregwelch) Assigned to: Tarn Weisner Burton (twburton) Summary: install 2.0.0.44 on Mac OS X Initial Comment: I can find a tgz package w/ binaries for pyopengl 1.5.6, but I am using python 2.1 and latest numpy so apparently need (and would want) pyopengl 2. However there is no config file for v2 for OS X (darwin, or darwin1). I began to look at the config files to see if I could figure out what to change (from freebsd for example) but it began to look a little ugly to me. While it might be "good for me" I have no particular desire to lear how to do this right now. I just want to use pyopengl under OS X. Should I be able to build/install pyopengl2 on OS X? BTW, I have Tenon's Xtools X server. Thanks in advance. Greg Welch Research Associate Professor Department of Computer Science UNC Chapel Hill we...@cs... ---------------------------------------------------------------------- >Comment By: Greg Welch (gregwelch) Date: 2001-09-15 13:22 Message: Logged In: YES user_id=324637 I see that in August you (right?) were looking for volunteers for testing. http://groups.google.com/groups?q=pyopengl+mac& hl=en&rnum=1&selm= mailman.997609020.21699.clpa- moderators%40python.org I volunteer. And/or what else can I do to help? ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-15 11:15 Message: Logged In: YES user_id=21784 Porting of PyOpenGL2 to Mac9 (and I presume OSX) is not completed and is currently stalled. At least for Mac9 the distutils metroworks compiler only compiles libs. For configuration purposes PyOpenGL2 needs to be able to compile executables (in distutils.mwerkscompiler.MWerksCompiler.link) Eventually it would be nice for distutils.command.config to work, i.e. compile and preprocess, but this is not an imperative right now. The work for these methods to work on all other compilers has been done, excepting MetroWerks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=461872&group_id=5988 |
From: <no...@so...> - 2001-09-15 18:16:02
|
Support Requests item #461872, was opened at 2001-09-15 10:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=461872&group_id=5988 Category: install Group: None Status: Open Priority: 5 Submitted By: Greg Welch (gregwelch) Assigned to: Tarn Weisner Burton (twburton) Summary: install 2.0.0.44 on Mac OS X Initial Comment: I can find a tgz package w/ binaries for pyopengl 1.5.6, but I am using python 2.1 and latest numpy so apparently need (and would want) pyopengl 2. However there is no config file for v2 for OS X (darwin, or darwin1). I began to look at the config files to see if I could figure out what to change (from freebsd for example) but it began to look a little ugly to me. While it might be "good for me" I have no particular desire to lear how to do this right now. I just want to use pyopengl under OS X. Should I be able to build/install pyopengl2 on OS X? BTW, I have Tenon's Xtools X server. Thanks in advance. Greg Welch Research Associate Professor Department of Computer Science UNC Chapel Hill we...@cs... ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-15 11:15 Message: Logged In: YES user_id=21784 Porting of PyOpenGL2 to Mac9 (and I presume OSX) is not completed and is currently stalled. At least for Mac9 the distutils metroworks compiler only compiles libs. For configuration purposes PyOpenGL2 needs to be able to compile executables (in distutils.mwerkscompiler.MWerksCompiler.link) Eventually it would be nice for distutils.command.config to work, i.e. compile and preprocess, but this is not an imperative right now. The work for these methods to work on all other compilers has been done, excepting MetroWerks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=461872&group_id=5988 |
From: <no...@so...> - 2001-09-15 17:37:25
|
Support Requests item #461872, was opened at 2001-09-15 10:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=461872&group_id=5988 Category: install Group: None Status: Open Priority: 5 Submitted By: Greg Welch (gregwelch) Assigned to: Tarn Weisner Burton (twburton) Summary: install 2.0.0.44 on Mac OS X Initial Comment: I can find a tgz package w/ binaries for pyopengl 1.5.6, but I am using python 2.1 and latest numpy so apparently need (and would want) pyopengl 2. However there is no config file for v2 for OS X (darwin, or darwin1). I began to look at the config files to see if I could figure out what to change (from freebsd for example) but it began to look a little ugly to me. While it might be "good for me" I have no particular desire to lear how to do this right now. I just want to use pyopengl under OS X. Should I be able to build/install pyopengl2 on OS X? BTW, I have Tenon's Xtools X server. Thanks in advance. Greg Welch Research Associate Professor Department of Computer Science UNC Chapel Hill we...@cs... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=461872&group_id=5988 |
From: <no...@so...> - 2001-09-10 11:58:33
|
Support Requests item #455914, was opened at 2001-08-27 14:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=455914&group_id=5988 Category: install Group: v2.0 >Status: Closed Priority: 5 Submitted By: Dr. Lothar Esser (lessertx) Assigned to: Tarn Weisner Burton (twburton) Summary: IRIX installation Initial Comment: Hi, my sys.platform is sys.platform is irix646 and I am having trouble to run python setup.py build. The biggest problem seems to be that I could not figrue out to change compiler options. It always uses cc which is fine except that many scripts contain c++ comments on which the c compiler chokes. I can add a switch -Xcpuscomm but I don't know how to tell that to the setup script. I tried the usual setenv CCFLAGS '-n32 -Xcpuscomm' but it seems to be ignored. So what can I do to configure it ? Sorry if I overlooked the obvious ... but I ran out of ideas. Thanks, Lothar ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-02 06:54 Message: Logged In: YES user_id=21784 New version of PyOpenGL has C++ comments removed. Have you tried it? Please respond so I can determine the status of this support request. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-08-27 15:28 Message: Logged In: YES user_id=21784 You can try alias cc=cc -Xcpluscomm. The C++ comments have been removed in CVS. The next release is on the 1st. I would really like to make sure this works so if the alias method doesn't then I'll give a dist without C++ comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=205988&aid=455914&group_id=5988 |
From: <no...@so...> - 2001-09-10 11:58:06
|
Bugs item #459730, was opened at 2001-09-07 21:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459730&group_id=5988 Category: build Group: v2.0 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Linux-Mandrake build uses wrong X11 dirs Initial Comment: The config file for the linux build specifies /usr/X11/[include|lib] for finding includes/libs. This is not correct for mandrake (at least 8.0) which has them installed in /usr/X11R6/[include|lib]. The python setup.py has detection of libraries using various paths, perhaps your setup.py could use similar mechanisms? ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-10 04:57 Message: Logged In: YES user_id=21784 Done ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 07:48 Message: Logged In: YES user_id=21784 I suppose it wouldn't hurt to add these, but isn't this an omission on Mandrake's part? Doesn't one normally have X11 linked to X11Rx? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459730&group_id=5988 |
From: <no...@so...> - 2001-09-09 02:22:53
|
Bugs item #459892, was opened at 2001-09-08 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 Category: GLUT Group: v2.0 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: glutMouseFunc handler button arg Initial Comment: A handler defined on a modified version of the "simple" demo: def on_mouse(self, button, state, x, y): print (button, state, x, y) when used via glutMouseFunc(self.on_mouse) the button arg is always 0, the others are what is expected. That is, I get output like: (0, 0, 198, 203) (0, 1, 114, 262) (0, 0, 137, 43) (0, 1, 207, 105) (0, 0, 168, 30) (0, 1, 162, 240) (0, 0, 263, 220) (0, 1, 87, 130) (0, 0, 149, 230) (0, 1, 157, 88) I'm new to GL, so my apologies if I'm missing an additional initialisation or handler step. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 19:22 Message: Logged In: YES user_id=21784 no prob ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-08 19:19 Message: Logged In: YES user_id=6405 *sigh* Sorry, my mistake. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 19:10 Message: Logged In: YES user_id=21784 Tested on Win32 and Linux (RedHat). Works fine. The C code used to interface to glutMouseFunc and the callback is trivial, i.e. just passes the arguments straight through. Try this C program so we can determine if its' a PyOpenGL problem. This will probably work to compile gcc -o test test.c -lglut -lGL -lGLU ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-08 18:44 Message: Logged In: YES user_id=6405 That test script didn't work - PyOpenGL_info.html attached. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 18:11 Message: Logged In: YES user_id=21784 Try out this test script. Works on my system. If it doesn't work on your system upload PyOpenGL_info.html produced by OpenGL/scripts/info.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 |
From: <no...@so...> - 2001-09-09 02:19:27
|
Bugs item #459892, was opened at 2001-09-08 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 Category: GLUT Group: v2.0 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: glutMouseFunc handler button arg Initial Comment: A handler defined on a modified version of the "simple" demo: def on_mouse(self, button, state, x, y): print (button, state, x, y) when used via glutMouseFunc(self.on_mouse) the button arg is always 0, the others are what is expected. That is, I get output like: (0, 0, 198, 203) (0, 1, 114, 262) (0, 0, 137, 43) (0, 1, 207, 105) (0, 0, 168, 30) (0, 1, 162, 240) (0, 0, 263, 220) (0, 1, 87, 130) (0, 0, 149, 230) (0, 1, 157, 88) I'm new to GL, so my apologies if I'm missing an additional initialisation or handler step. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-09-08 19:19 Message: Logged In: YES user_id=6405 *sigh* Sorry, my mistake. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 19:10 Message: Logged In: YES user_id=21784 Tested on Win32 and Linux (RedHat). Works fine. The C code used to interface to glutMouseFunc and the callback is trivial, i.e. just passes the arguments straight through. Try this C program so we can determine if its' a PyOpenGL problem. This will probably work to compile gcc -o test test.c -lglut -lGL -lGLU ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-08 18:44 Message: Logged In: YES user_id=6405 That test script didn't work - PyOpenGL_info.html attached. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 18:11 Message: Logged In: YES user_id=21784 Try out this test script. Works on my system. If it doesn't work on your system upload PyOpenGL_info.html produced by OpenGL/scripts/info.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 |
From: <no...@so...> - 2001-09-09 02:10:45
|
Bugs item #459892, was opened at 2001-09-08 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 Category: GLUT Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: glutMouseFunc handler button arg Initial Comment: A handler defined on a modified version of the "simple" demo: def on_mouse(self, button, state, x, y): print (button, state, x, y) when used via glutMouseFunc(self.on_mouse) the button arg is always 0, the others are what is expected. That is, I get output like: (0, 0, 198, 203) (0, 1, 114, 262) (0, 0, 137, 43) (0, 1, 207, 105) (0, 0, 168, 30) (0, 1, 162, 240) (0, 0, 263, 220) (0, 1, 87, 130) (0, 0, 149, 230) (0, 1, 157, 88) I'm new to GL, so my apologies if I'm missing an additional initialisation or handler step. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 19:10 Message: Logged In: YES user_id=21784 Tested on Win32 and Linux (RedHat). Works fine. The C code used to interface to glutMouseFunc and the callback is trivial, i.e. just passes the arguments straight through. Try this C program so we can determine if its' a PyOpenGL problem. This will probably work to compile gcc -o test test.c -lglut -lGL -lGLU ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-08 18:44 Message: Logged In: YES user_id=6405 That test script didn't work - PyOpenGL_info.html attached. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 18:11 Message: Logged In: YES user_id=21784 Try out this test script. Works on my system. If it doesn't work on your system upload PyOpenGL_info.html produced by OpenGL/scripts/info.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 |
From: <no...@so...> - 2001-09-09 01:44:42
|
Bugs item #459892, was opened at 2001-09-08 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 Category: GLUT Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: glutMouseFunc handler button arg Initial Comment: A handler defined on a modified version of the "simple" demo: def on_mouse(self, button, state, x, y): print (button, state, x, y) when used via glutMouseFunc(self.on_mouse) the button arg is always 0, the others are what is expected. That is, I get output like: (0, 0, 198, 203) (0, 1, 114, 262) (0, 0, 137, 43) (0, 1, 207, 105) (0, 0, 168, 30) (0, 1, 162, 240) (0, 0, 263, 220) (0, 1, 87, 130) (0, 0, 149, 230) (0, 1, 157, 88) I'm new to GL, so my apologies if I'm missing an additional initialisation or handler step. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-09-08 18:44 Message: Logged In: YES user_id=6405 That test script didn't work - PyOpenGL_info.html attached. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 18:11 Message: Logged In: YES user_id=21784 Try out this test script. Works on my system. If it doesn't work on your system upload PyOpenGL_info.html produced by OpenGL/scripts/info.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 |
From: <no...@so...> - 2001-09-09 01:11:41
|
Bugs item #459892, was opened at 2001-09-08 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 Category: GLUT Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: glutMouseFunc handler button arg Initial Comment: A handler defined on a modified version of the "simple" demo: def on_mouse(self, button, state, x, y): print (button, state, x, y) when used via glutMouseFunc(self.on_mouse) the button arg is always 0, the others are what is expected. That is, I get output like: (0, 0, 198, 203) (0, 1, 114, 262) (0, 0, 137, 43) (0, 1, 207, 105) (0, 0, 168, 30) (0, 1, 162, 240) (0, 0, 263, 220) (0, 1, 87, 130) (0, 0, 149, 230) (0, 1, 157, 88) I'm new to GL, so my apologies if I'm missing an additional initialisation or handler step. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 18:11 Message: Logged In: YES user_id=21784 Try out this test script. Works on my system. If it doesn't work on your system upload PyOpenGL_info.html produced by OpenGL/scripts/info.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 |
From: <no...@so...> - 2001-09-09 01:00:02
|
Bugs item #459892, was opened at 2001-09-08 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 Category: GLUT Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: glutMouseFunc handler button arg Initial Comment: A handler defined on a modified version of the "simple" demo: def on_mouse(self, button, state, x, y): print (button, state, x, y) when used via glutMouseFunc(self.on_mouse) the button arg is always 0, the others are what is expected. That is, I get output like: (0, 0, 198, 203) (0, 1, 114, 262) (0, 0, 137, 43) (0, 1, 207, 105) (0, 0, 168, 30) (0, 1, 162, 240) (0, 0, 263, 220) (0, 1, 87, 130) (0, 0, 149, 230) (0, 1, 157, 88) I'm new to GL, so my apologies if I'm missing an additional initialisation or handler step. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459892&group_id=5988 |
From: <no...@so...> - 2001-09-08 21:15:08
|
Feature Requests item #459865, was opened at 2001-09-08 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355988&aid=459865&group_id=5988 Category: new module Group: v2.1 Status: Open Resolution: None >Priority: 2 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Tarn Weisner Burton (twburton) Summary: Wrap GLFW Initial Comment: Wrap the GLFW lib. Provides simple windowing alternative to GLUT. Currently only available on Win32 and rather new, but something to keep an eye on. http://opengl.freehosting.net/glfw/ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355988&aid=459865&group_id=5988 |
From: <no...@so...> - 2001-09-08 21:15:00
|
Feature Requests item #459865, was opened at 2001-09-08 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355988&aid=459865&group_id=5988 Category: new module Group: v2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Tarn Weisner Burton (twburton) Summary: Wrap GLFW Initial Comment: Wrap the GLFW lib. Provides simple windowing alternative to GLUT. Currently only available on Win32 and rather new, but something to keep an eye on. http://opengl.freehosting.net/glfw/ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355988&aid=459865&group_id=5988 |
From: <no...@so...> - 2001-09-08 14:48:50
|
Bugs item #459730, was opened at 2001-09-07 21:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459730&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Linux-Mandrake build uses wrong X11 dirs Initial Comment: The config file for the linux build specifies /usr/X11/[include|lib] for finding includes/libs. This is not correct for mandrake (at least 8.0) which has them installed in /usr/X11R6/[include|lib]. The python setup.py has detection of libraries using various paths, perhaps your setup.py could use similar mechanisms? ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 07:48 Message: Logged In: YES user_id=21784 I suppose it wouldn't hurt to add these, but isn't this an omission on Mandrake's part? Doesn't one normally have X11 linked to X11Rx? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459730&group_id=5988 |
From: <no...@so...> - 2001-09-08 14:40:38
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 07:40 Message: Logged In: YES user_id=21784 There might be some subtlety that I don't know of, but I just can't see what the difference could possible be. Anyways using double* is nesc with the current typemap system. Using double[][3] makes things really complex and since all the protos work now (try the GLE demos) I don't see the point in changing the current system. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-08 07:19 Message: Logged In: YES user_id=6405 My C is a bit rusty, bit isn't double* different to double[][3]? Normally compilers don't complain if you mix-n-match doule* and double[]... ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:59 Message: Logged In: YES user_id=21784 The GLE warning are harmless warnings about double[] != *double The multimode_draw_arrays problem has been noted before. The current proto matches spec. Whether the spec has a typo or the typo is in the header is unresolved. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:57 Message: Logged In: YES user_id=6405 I also had a lot of API mismatches for the GLE.i interface file when compared to src/gle/src/gle.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 14:20:22
|
Bugs item #459735, was opened at 2001-09-07 21:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 Category: build Group: v2.0 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Build failures with 2.0.0.44 Initial Comment: Out of the box, without SWIG installed, I got build errors. I have attached the entire build log. The build was attempted using the PyOpenGL-2.0.0.44.tar.gz source distribution. With SWIG installed, I forced a build_w and it still broke. That was using swig 1.3a5. Relevant installed packages: python-2.1.1-3mdk python-devel-2.1.1-3mdk python-numeric-20.1.0-1mdk python-numeric-devel-20.1.0-1mdk tkinter-2.1.1-3mdk Mesa-3.4.1-4mdk Mesa-common-3.4.1-4mdk Mesa-common-devel-3.4.1-4mdk swig-1.3a5-1mdk Note: the log also contains some other type warnings. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-09-08 07:20 Message: Logged In: YES user_id=6405 Sorry, I didn't read the release notes - just the installation guide. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:53 Message: Logged In: YES user_id=21784 Please see http://sourceforge.net/project/shownotes.php? release_id=50914 ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:53 Message: Logged In: YES user_id=21784 Please see http://sourceforge.net/project/shownotes.php? release_id=50914 ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:37 Message: Logged In: YES user_id=6405 I've managed to get GLU's __init__.c to compile by modifying the GLU/__init__.i interface spec to change: GLUquadric -> GLUquadricObj GLUnurbs -> GLUnurbsObj GLUtesselator -> GLUtriangulatorObj which now matches the definitions given in GL/glu.h: #if defined GLU_VERSION_1_2 typedef struct GLUquadric GLUquadricObj; typedef struct GLUnurbs GLUnurbsObj; /* FIXME: We need to implement the other 1.3 typedefs - GH */ typedef struct GLUtesselator GLUtesselator; typedef GLUtesselator GLUtriangulatorObj; #else /* GLU 1.1 and older */ typedef struct GLUquadric GLUquadricObj; typedef struct GLUtriangulatorObj GLUtriangulatorObj; typedef struct GLUnurbs GLUnurbsObj; #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 |
From: <no...@so...> - 2001-09-08 14:19:14
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-09-08 07:19 Message: Logged In: YES user_id=6405 My C is a bit rusty, bit isn't double* different to double[][3]? Normally compilers don't complain if you mix-n-match doule* and double[]... ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:59 Message: Logged In: YES user_id=21784 The GLE warning are harmless warnings about double[] != *double The multimode_draw_arrays problem has been noted before. The current proto matches spec. Whether the spec has a typo or the typo is in the header is unresolved. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:57 Message: Logged In: YES user_id=6405 I also had a lot of API mismatches for the GLE.i interface file when compared to src/gle/src/gle.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 14:01:51
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Tarn Weisner Burton (twburton) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:59 Message: Logged In: YES user_id=21784 The GLE warning are harmless warnings about double[] != *double The multimode_draw_arrays problem has been noted before. The current proto matches spec. Whether the spec has a typo or the typo is in the header is unresolved. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:57 Message: Logged In: YES user_id=6405 I also had a lot of API mismatches for the GLE.i interface file when compared to src/gle/src/gle.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 13:59:11
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:59 Message: Logged In: YES user_id=21784 The GLE warning are harmless warnings about double[] != *double The multimode_draw_arrays problem has been noted before. The current proto matches spec. Whether the spec has a typo or the typo is in the header is unresolved. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:57 Message: Logged In: YES user_id=6405 I also had a lot of API mismatches for the GLE.i interface file when compared to src/gle/src/gle.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 13:53:21
|
Bugs item #459735, was opened at 2001-09-07 21:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 Category: build Group: v2.0 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Build failures with 2.0.0.44 Initial Comment: Out of the box, without SWIG installed, I got build errors. I have attached the entire build log. The build was attempted using the PyOpenGL-2.0.0.44.tar.gz source distribution. With SWIG installed, I forced a build_w and it still broke. That was using swig 1.3a5. Relevant installed packages: python-2.1.1-3mdk python-devel-2.1.1-3mdk python-numeric-20.1.0-1mdk python-numeric-devel-20.1.0-1mdk tkinter-2.1.1-3mdk Mesa-3.4.1-4mdk Mesa-common-3.4.1-4mdk Mesa-common-devel-3.4.1-4mdk swig-1.3a5-1mdk Note: the log also contains some other type warnings. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:53 Message: Logged In: YES user_id=21784 Please see http://sourceforge.net/project/shownotes.php? release_id=50914 ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:53 Message: Logged In: YES user_id=21784 Please see http://sourceforge.net/project/shownotes.php? release_id=50914 ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:37 Message: Logged In: YES user_id=6405 I've managed to get GLU's __init__.c to compile by modifying the GLU/__init__.i interface spec to change: GLUquadric -> GLUquadricObj GLUnurbs -> GLUnurbsObj GLUtesselator -> GLUtriangulatorObj which now matches the definitions given in GL/glu.h: #if defined GLU_VERSION_1_2 typedef struct GLUquadric GLUquadricObj; typedef struct GLUnurbs GLUnurbsObj; /* FIXME: We need to implement the other 1.3 typedefs - GH */ typedef struct GLUtesselator GLUtesselator; typedef GLUtesselator GLUtriangulatorObj; #else /* GLU 1.1 and older */ typedef struct GLUquadric GLUquadricObj; typedef struct GLUtriangulatorObj GLUtriangulatorObj; typedef struct GLUnurbs GLUnurbsObj; #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 |
From: <no...@so...> - 2001-09-08 13:53:12
|
Bugs item #459735, was opened at 2001-09-07 21:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 Category: build Group: v2.0 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Build failures with 2.0.0.44 Initial Comment: Out of the box, without SWIG installed, I got build errors. I have attached the entire build log. The build was attempted using the PyOpenGL-2.0.0.44.tar.gz source distribution. With SWIG installed, I forced a build_w and it still broke. That was using swig 1.3a5. Relevant installed packages: python-2.1.1-3mdk python-devel-2.1.1-3mdk python-numeric-20.1.0-1mdk python-numeric-devel-20.1.0-1mdk tkinter-2.1.1-3mdk Mesa-3.4.1-4mdk Mesa-common-3.4.1-4mdk Mesa-common-devel-3.4.1-4mdk swig-1.3a5-1mdk Note: the log also contains some other type warnings. ---------------------------------------------------------------------- >Comment By: Tarn Weisner Burton (twburton) Date: 2001-09-08 06:53 Message: Logged In: YES user_id=21784 Please see http://sourceforge.net/project/shownotes.php? release_id=50914 ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-09-07 23:37 Message: Logged In: YES user_id=6405 I've managed to get GLU's __init__.c to compile by modifying the GLU/__init__.i interface spec to change: GLUquadric -> GLUquadricObj GLUnurbs -> GLUnurbsObj GLUtesselator -> GLUtriangulatorObj which now matches the definitions given in GL/glu.h: #if defined GLU_VERSION_1_2 typedef struct GLUquadric GLUquadricObj; typedef struct GLUnurbs GLUnurbsObj; /* FIXME: We need to implement the other 1.3 typedefs - GH */ typedef struct GLUtesselator GLUtesselator; typedef GLUtesselator GLUtriangulatorObj; #else /* GLU 1.1 and older */ typedef struct GLUquadric GLUquadricObj; typedef struct GLUtriangulatorObj GLUtriangulatorObj; typedef struct GLUnurbs GLUnurbsObj; #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 |
From: <no...@so...> - 2001-09-08 06:57:30
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-09-07 23:57 Message: Logged In: YES user_id=6405 I also had a lot of API mismatches for the GLE.i interface file when compared to src/gle/src/gle.h. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 06:51:07
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 >Category: build >Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 06:45:41
|
Bugs item #459745, was opened at 2001-09-07 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Compile warning in 2.0.0.44 Initial Comment: My glext.h has extern void APIENTRY glMultiModeDrawArraysIBM (GLenum, const GLint *, const GLsizei *, GLsizei, GLint); whereas GL/IBM/multimode_draw_arrays.i has %name(glMultiModeDrawArraysIBM) void _glMultiModeDrawArraysIBM(const GLenum *mode, const GLint *first, const GLsizei *count, GLsizei primcount); i.e. the first arg is by-value in the glext header, but by-ref in the swig interface file. My glext.h has "GL_GLEXT_VERSION 7". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459745&group_id=5988 |
From: <no...@so...> - 2001-09-08 06:37:11
|
Bugs item #459735, was opened at 2001-09-07 21:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 Category: build Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Tarn Weisner Burton (twburton) Summary: Build failures with 2.0.0.44 Initial Comment: Out of the box, without SWIG installed, I got build errors. I have attached the entire build log. The build was attempted using the PyOpenGL-2.0.0.44.tar.gz source distribution. With SWIG installed, I forced a build_w and it still broke. That was using swig 1.3a5. Relevant installed packages: python-2.1.1-3mdk python-devel-2.1.1-3mdk python-numeric-20.1.0-1mdk python-numeric-devel-20.1.0-1mdk tkinter-2.1.1-3mdk Mesa-3.4.1-4mdk Mesa-common-3.4.1-4mdk Mesa-common-devel-3.4.1-4mdk swig-1.3a5-1mdk Note: the log also contains some other type warnings. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2001-09-07 23:37 Message: Logged In: YES user_id=6405 I've managed to get GLU's __init__.c to compile by modifying the GLU/__init__.i interface spec to change: GLUquadric -> GLUquadricObj GLUnurbs -> GLUnurbsObj GLUtesselator -> GLUtriangulatorObj which now matches the definitions given in GL/glu.h: #if defined GLU_VERSION_1_2 typedef struct GLUquadric GLUquadricObj; typedef struct GLUnurbs GLUnurbsObj; /* FIXME: We need to implement the other 1.3 typedefs - GH */ typedef struct GLUtesselator GLUtesselator; typedef GLUtesselator GLUtriangulatorObj; #else /* GLU 1.1 and older */ typedef struct GLUquadric GLUquadricObj; typedef struct GLUtriangulatorObj GLUtriangulatorObj; typedef struct GLUnurbs GLUnurbsObj; #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105988&aid=459735&group_id=5988 |