pyopengl-devel Mailing List for PyOpenGL (Page 15)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-devel — Discussion of PyOpenGL development.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
(9) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(10) |
Aug
|
Sep
(3) |
Oct
(9) |
Nov
(20) |
Dec
(31) |
| 2003 |
Jan
(36) |
Feb
(44) |
Mar
(16) |
Apr
(35) |
May
(59) |
Jun
(17) |
Jul
(11) |
Aug
(14) |
Sep
(9) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
| 2004 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(42) |
Aug
(7) |
Sep
(17) |
Oct
(32) |
Nov
(7) |
Dec
(5) |
| 2005 |
Jan
(11) |
Feb
(11) |
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(7) |
Aug
(8) |
Sep
(8) |
Oct
(23) |
Nov
(29) |
Dec
(5) |
| 2007 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(10) |
May
(7) |
Jun
(12) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(6) |
Dec
(3) |
| 2008 |
Jan
(38) |
Feb
(10) |
Mar
(3) |
Apr
(13) |
May
(8) |
Jun
(12) |
Jul
(6) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(21) |
Dec
(1) |
| 2009 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(6) |
May
(4) |
Jun
(4) |
Jul
(38) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(16) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(17) |
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(3) |
Dec
(8) |
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(6) |
May
(3) |
Jun
(19) |
Jul
(6) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(6) |
| 2012 |
Jan
(8) |
Feb
(3) |
Mar
(26) |
Apr
(12) |
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(5) |
Dec
(1) |
| 2013 |
Jan
(2) |
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(4) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2008-10-08 06:43:34
|
Bugs item #2152623, was opened at 2008-10-08 01:05 Message generated for change (Settings changed) made by kostmo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2152623&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL >Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Karl Ostmo (kostmo) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError: GL_BITMAP with glDrawPixels Initial Comment: Error trace: glDrawPixels(len(pixels[0])*8, len(pixels), GL_STENCIL_INDEX, GL_BITMAP, pixels) File "/usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 915, in wrapperCall pyArgs.append( converter(arg, self, args) ) File "/usr/lib/python2.5/site-packages/OpenGL/GL/images.py", line 404, in __call__ arrayType = arrays.GL_CONSTANT_TO_ARRAY_TYPE[ images.TYPE_TO_ARRAYTYPE[ type ] ] KeyError: GL_BITMAP It looks like the capability to draw bitmaps (1 byte = 8 pixels) is not implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2152623&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-10-08 05:05:57
|
Bugs item #2152623, was opened at 2008-10-08 01:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2152623&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Karl Ostmo (kostmo) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError: GL_BITMAP with glDrawPixels Initial Comment: Error trace: glDrawPixels(len(pixels[0])*8, len(pixels), GL_STENCIL_INDEX, GL_BITMAP, pixels) File "/usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 915, in wrapperCall pyArgs.append( converter(arg, self, args) ) File "/usr/lib/python2.5/site-packages/OpenGL/GL/images.py", line 404, in __call__ arrayType = arrays.GL_CONSTANT_TO_ARRAY_TYPE[ images.TYPE_TO_ARRAYTYPE[ type ] ] KeyError: GL_BITMAP It looks like the capability to draw bitmaps (1 byte = 8 pixels) is not implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2152623&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-10-05 22:22:01
|
Bugs item #2143888, was opened at 2008-10-03 08:24 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2143888&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: glut32.dll required on vista? Initial Comment: This is strange ... I had a friend of mine test my codebase which I ship the entire OpenGL dir with so it's not required to be installed manually ... He didn't install anything special, he ran it, and it worked. Now, I have my _other_ friend test the same codebase ... and he gets this error: C:\SIL>__init__.py <<< SILr470 <<< psyco not initialized Traceback (most recent call last): File "C:\SIL\__init__.py", line 336, in <module> Singleton = Engine() File "C:\SIL\__init__.py", line 85, in __init__ OpenGL.GLUT.glutInit() File "C:\SIL\OpenGL\GLUT\special.py", line 316, in glutInit _base_glutInit( ctypes.byref(count), holder ) File "C:\SIL\OpenGL\GLUT\special.py", line 57, in _base_glutInit return __glutInitWithExit(pargc, argv, _exitfunc) File "C:\SIL\OpenGL\platform\baseplatform.py", line 280, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function __glutInit WithExit, check for bool(__glutInitWithExit) before calling C:\SIL> Apparently he needs the glut32.dll or something ? Why didn't my other friend also on vista lack glut32.dll ? Is it possible to have freeglut work purely in python code cross-platform without depending on a GLUT-specific binary at all? Freeglut seems to be going stagnant and it appears the thing people suggest most often is 'use a different windowing library', like SDL or something.. ? Here's a relevant GLUT bug report I submitted which I think is pretty crucial.. http://sourceforge.net/tracker/index.php?func=detail&aid=2137721&group_id=1032&atid=101032 Also, if PyOpenGL developers have to rely on the fact that their end-users will have glut32.dll in order to get anything working (or ship it themselves) .. then why even use PyOpenGL over say.. pygame or SDL-ctypes (which pygame-ctypes uses) .. because that also depends on the end-user having a binary (SDL in the case of SDL-ctypes, or pygame+SDL in the game of pygame) I guess what I'm asking for would basically be a rewrite of [Free]GLUT in python using winapi/xlib/cocoa calls while adding said fixes / enhancements, eh? Also.. one final thing I _CAN_ think of a difference in the two vista test cases.. the one that passed had python 2.4 + ctypes .. the one that failed had 2.6 https://svn.enthought.com/epd/ticket/148 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-05 22:21 Message: Putting 'glut32.dll' in the same directory as the executing script allows it to function.. I tried using the DLL from the following source: http://slickr-dotnet.googlecode.com/svn/trunk/Lib/freeglut.dll (obviously renaming it to glut32.dll first) but it failed. The following one works and is the one I'm currently using: http://bullet.googlecode.com/svn/trunk/GLUT32.DLL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2143888&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-10-03 08:24:59
|
Bugs item #2143888, was opened at 2008-10-03 08:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2143888&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: glut32.dll required on vista? Initial Comment: This is strange ... I had a friend of mine test my codebase which I ship the entire OpenGL dir with so it's not required to be installed manually ... He didn't install anything special, he ran it, and it worked. Now, I have my _other_ friend test the same codebase ... and he gets this error: C:\SIL>__init__.py <<< SILr470 <<< psyco not initialized Traceback (most recent call last): File "C:\SIL\__init__.py", line 336, in <module> Singleton = Engine() File "C:\SIL\__init__.py", line 85, in __init__ OpenGL.GLUT.glutInit() File "C:\SIL\OpenGL\GLUT\special.py", line 316, in glutInit _base_glutInit( ctypes.byref(count), holder ) File "C:\SIL\OpenGL\GLUT\special.py", line 57, in _base_glutInit return __glutInitWithExit(pargc, argv, _exitfunc) File "C:\SIL\OpenGL\platform\baseplatform.py", line 280, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function __glutInit WithExit, check for bool(__glutInitWithExit) before calling C:\SIL> Apparently he needs the glut32.dll or something ? Why didn't my other friend also on vista lack glut32.dll ? Is it possible to have freeglut work purely in python code cross-platform without depending on a GLUT-specific binary at all? Freeglut seems to be going stagnant and it appears the thing people suggest most often is 'use a different windowing library', like SDL or something.. ? Here's a relevant GLUT bug report I submitted which I think is pretty crucial.. http://sourceforge.net/tracker/index.php?func=detail&aid=2137721&group_id=1032&atid=101032 Also, if PyOpenGL developers have to rely on the fact that their end-users will have glut32.dll in order to get anything working (or ship it themselves) .. then why even use PyOpenGL over say.. pygame or SDL-ctypes (which pygame-ctypes uses) .. because that also depends on the end-user having a binary (SDL in the case of SDL-ctypes, or pygame+SDL in the game of pygame) I guess what I'm asking for would basically be a rewrite of [Free]GLUT in python using winapi/xlib/cocoa calls while adding said fixes / enhancements, eh? Also.. one final thing I _CAN_ think of a difference in the two vista test cases.. the one that passed had python 2.4 + ctypes .. the one that failed had 2.6 https://svn.enthought.com/epd/ticket/148 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2143888&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-09-26 11:19:56
|
Bugs item #2130003, was opened at 2008-09-26 11:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2130003&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Loading GLUT on DarwinPlatform failes Initial Comment: If the file system was formatted as case sensitive (Leopard offers this option at install time), the following code will fail: from OpenGL.GLU import * with >>> from OpenGL.GLU import * Traceback (most recent call last): File "<stdin>", line 1, in <module> File "OpenGL/GLU/__init__.py", line 2, in <module> from OpenGL import platform File "OpenGL/platform/__init__.py", line 36, in <module> _load() File "OpenGL/platform/__init__.py", line 27, in _load plugin_class = plugin.load() File "OpenGL/plugins.py", line 14, in load return importByName( self.import_path ) File "OpenGL/plugins.py", line 28, in importByName module = __import__( ".".join(moduleName), {}, {}, moduleName) File "OpenGL/platform/darwin.py", line 27, in <module> class DarwinPlatform( baseplatform.BasePlatform ): File "OpenGL/platform/darwin.py", line 47, in DarwinPlatform mode=ctypes.RTLD_GLOBAL File "OpenGL/platform/ctypesloader.py", line 42, in loadLibrary return dllType( name, mode ) File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ctypes/__init__.py", line 325, in __init__ self._handle = _dlopen(self._name, mode) OSError: ('dlopen(glut, 10): image not found', 'glut', None) >>> Proposed fix: in OpenGL/platform/darwin.py change line 46 from: 'glut', to 'GLUT', this will solve the problem. ikokai <at> gmail <dot> com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2130003&group_id=5988 |
|
From: Mike C. F. <mcf...@vr...> - 2008-09-15 02:19:38
|
I've just uploaded PyOpenGL 3.0.0b6 to SourceForge and PyPI. At this point there's not really much I'm intending to change before the 3.0.0 final release. We now have support for extensions up to the OpenGL 3.0 release, we should run on Win32 and Linux at least. We should be compatible with py2exe/pyinstaller/py2app. From here on out what we need is testing on various platforms, with various software configurations. I wouldn't be surprised if we find some bugs if there's no Numpy installed, or that we'll get unhappy results if you don't have GLUT or GLE and try to use them. I'd also suspect that our GLX/WGL/AGL wrapper is pretty unusable at this point (my not having any code that really tries to use it). There are likely dozens of extensions that are also in need of tweaked wrappers. In theory I might look at doing some optimizations or some more cleanup, but it's been years since we had a final release[1], and that can likely wait for a 3.0.1 release. With that said: easy_install PyOpenGL to setup PyOpenGL afresh, or easy_install -U PyOpenGL to update. If show-stopping bugs show up, we may need another beta, but at this point I don't know of any show-stoppers to get in the way. BTW, the online documentation[2] has been updated to cover the OpenGL 2.1 version of OpenGL, with links to a wider range of PyOpenGL-using Open Source projects. If you'd like your project added to the set of sample-code projects and you have an online source-code-control viewing system, just let me know. Enjoy yourselves, Mike [1] April 30. 2005 is the day I started work in earnest on replacing the SWIG-based PyOpenGL with a ctypes implementation... I can't claim to have been working solidly that whole time, however. [2] http://pyopengl.sourceforge.net/documentation/manual-3.0/index.xhtml -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: SourceForge.net <no...@so...> - 2008-08-27 23:32:36
|
Bugs item #2079402, was opened at 2008-08-27 23:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2079402&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLE Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 'DarwinPlatform' object has no attribute 'getExtensionProced Initial Comment: More specifically, I get this sequence of error messages File "/Users/woolford/EMAN2/lib/emimage2d.py", line 721, in render GL.glBlendEquation(GL.GL_FUNC_SUBTRACT); File "/Library/Python/2.5/site-packages/PyOpenGL-3.0.0b5-py2.5.egg/OpenGL/platform/baseplatform.py", line 296, in __call__ if self.extension and self.load(): File "/Library/Python/2.5/site-packages/PyOpenGL-3.0.0b5-py2.5.egg/OpenGL/platform/baseplatform.py", line 275, in load pointer = platform.PLATFORM.getExtensionProcedure( AttributeError: 'DarwinPlatform' object has no attribute 'getExtensionProcedure' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2079402&group_id=5988 |
|
From: Mike C. F. <mcf...@vr...> - 2008-08-22 18:31:18
|
For those who are interested in helping with the documentation/release
effort for PyOpenGL 3.x, the newly generated reference documentation is
now up, and includes sample-code references for various PyOpenGL-using
Open Source projects. This is still based on OpenGL 1.x documentation,
despite the fact that PyOpenGL should support anything up to OpenGL
3.x. At some point hopefully someone at Khronos group will release at
least the 2.1 DocBook source files and we can regenerate with those.
Check it out here:
http://pyopengl.sourceforge.net/documentation/manual-3.0/index.xhtml
The generation process is now entirely automatic, hopefully we'll get
more PyOpenGL-using projects added so that we can update the set
ofsample-code projects. As mentioned earlier, there's currently no
documentation for extensions. If you want to work on any of those, let
me know, the code to generate the documentation is up on LaunchPad:
bzr branch lp:~mcfletch/pyopengl/directdocs
There's obviously lots to be done with formatting as well if someone has
the time. If someone wants to add deprecation warnings for OpenGL 3.x,
that would be useful too, (e.g. create a text file with the names of the
deprecated functions and annotate the docs with a warning for each
deprecated operation).
Have fun,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Mike C. F. <mcf...@vr...> - 2008-08-15 19:57:12
|
Hi everyone,
It's high time we (I) got PyOpenGL 3.0.0 final released, I've been
puttering with it for 2+ years now and we're getting way behind the
curve. Here's what seems to be remaining in the queue for release:
* documentation
o regeneration of the documentation from docbook
o source-code url gathering from Open Source projects
o figure out an approach for extension documentation
o docstring tweaks to make the run-time docs easier to understand
o migration documentation
+ needs people with big libraries to track what they
needed to do to convert to 3.x
* testing
o win32 and OS-X need *way* more testing
o hpux, solaris and the like need to be tested to see if
they're even compatible
o linux other than Ubuntu and Gentoo likely needs testing
o testing with missing libraries to be sure we fail with
useful warnings (i.e. GLE, GLUT)
o testing with big existing PyOpenGL libraries/applications
o Python 2.4, and 2.6 testing
* installation procedures
o need more testing
o need documentation
o need working samples of pyinstaller, py2exe and py2app recipes
+ pyinstaller *should* be workable now with recipe in cvs
* optimization
o profile real-world code and see if we can provide a few
(optional) plug-ins to speed up common code paths
o likely the "wrapper" class and the associated helper
functions are the most appropriate targets
o possibly add a few more optimization flags to drop
debug/development functionality for deployment situations
* WGL/AGL/XGL
o while these libraries should be there, they haven't been
tested at all
o no extensions to these available yet
* cleanup
o some hacks, such as the use of classes instead of functions
for wrappers are not likely necessary any more (Python 2.2
no longer being compatible with PyOpenGL)
If people have other things they feel are needed before the final 3.0.0
release, please speak up. At some point post 3.0 release I'm thinking
of moving the source-code repository to LaunchPad to use BZR and allow
people to hack on the code-base more easily.
Enjoy yourselves,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Josh B. <jo...@jo...> - 2008-07-31 23:32:21
|
I am using glDrawPixels to draw from a pixel buffer object: ---------------------------- #draw bottom portion glPixelZoom(x_zoom, -y_zoom) glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB, self._waterfall_buffer_bottom) glDrawPixels(self._fft_size, self._frame_ptr, GL_RGBA, GL_UNSIGNED_BYTE, None) glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB, 0) #unbind ----------------------------- Currently, the data is set to None and the pixel buffer is drawn with a zero byte offset. According to the glDrawPixels docs: """If a non-zero named buffer object is bound to the GL_PIXEL_UNPACK_BUFFER target (see glBindBuffer) while a block of pixels is specified, data is treated as a byte offset into the buffer object's data store.""" How can I specify an offset into my pixel buffer in python? -Josh |
|
From: SourceForge.net <no...@so...> - 2008-07-27 04:13:57
|
Bugs item #2029134, was opened at 2008-07-27 12:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2029134&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: install Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: irobot (irbotto) Assigned to: Nobody/Anonymous (nobody) Summary: error in vbo_junk.py Initial Comment: I try to install PyOpenGL-3.0.0b4 by typing "python setup.py install" it's running and display its processing status. But when it display 'Extracting PyOpenGL-3.0.0b4-py2.5.egg to g:\python25\lib\site-packages", it said one file in the sub-directory \OpenGL\arrays\vbo-junk.py" has error at line 2. And display <<<<<<< vbo.py ^ SyntaxError: invalid syntax And then it ends up. I found that I can't use PyOpenGL. I try to look at the vbo_junk.py and found that there are many unknown command like "<<<<<<< vbo" and ">>>>>>> 1.5" at various part inside the file. I don't know what is the problem here. I have install python2.5 and the latest version of ez_setup. I fail with both the command "easy_install PyOpenGL" and "python setup.py install", end up with the same screen. I have try in the WinXp and Win98 platform and end up with the same result. I am not sure whether it is it a bug or not. Just for reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2029134&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-07-20 00:46:02
|
Bugs item #2019593, was opened at 2008-07-16 10:44 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2019593&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: install Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Mike C. Fletcher (mcfletch) Summary: vbo_junk.py contains diff conflict statements Initial Comment: In release 3.0.0b4 diff statements (e.g. >>>>>>>>) can be found in OpenGL/arrays/vbo_junk.py preventing installation. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-07-19 20:46 Message: Logged In: YES user_id=34901 Originator: NO Thanks for the heads-up. The junk file was intended to be deleted, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2019593&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-07-20 00:45:18
|
Bugs item #1906626, was opened at 2008-03-03 18:19 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1906626&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kenneth Evans (kennethevans) >Assigned to: Mike C. Fletcher (mcfletch) Summary: Error in __init__.py for Tk Initial Comment: Line 82 should be: _default_root.tk.call('lappend', 'auto_path', TOGL_DLL_PATH) Without this change: Z:\>python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.Tk Traceback (most recent call last): File "<stdin>", line 1, in <module> File "c:\python25\lib\site-packages\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\Tk\__ini t__.py", line 87, in <module> _default_root.tk.call('package', 'require', 'Togl') _tkinter.TclError: can't find package Togl >>> ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-07-19 20:45 Message: Logged In: YES user_id=34901 Originator: NO Fixed in current CVS, looks like a simple editing error ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1906626&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-07-16 14:43:57
|
Bugs item #2019593, was opened at 2008-07-16 14:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2019593&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: install Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: vbo_junk.py contains diff conflict statements Initial Comment: In release 3.0.0b4 diff statements (e.g. >>>>>>>>) can be found in OpenGL/arrays/vbo_junk.py preventing installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2019593&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-07-09 04:54:10
|
Bugs item #1737282, was opened at 2007-06-14 15:38 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1737282&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault on Ubuntu Fiesty x86-64 - 3.0.0a6 Initial Comment: With Python 2.5,Python-2.5.tar.bz2 numpy, numpy-1.0.tar.gz PyOpenGL, PyOpenGL-3.0.0a6.tar.gz OpenGL-ctypes/OpenGL/tests$ python test_glutwindow.py newArguments ['test_glutwindow.py'] Segmentation fault (core dumped) This occurs on line 78 glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-09 04:54 Message: Logged In: NO I receive the segmentation fault on my 64 bit Hardy Heron on an AMD64-2x, but it happens at the import OpenGL.GL statement, and it goes away if I run as root: 'sudo python test_glutwindow.py'. I have tried to reinstall all opengl components but it still segfaults on import OpenGL.GL. ---------------------------------------------------------------------- Comment By: hippodriver (hippodriver) Date: 2008-05-03 10:34 Message: Logged In: YES user_id=1981020 Originator: NO I get the same error on Fedora 9 AMD64 and Arch Linux ia32. Here are the library versions: a) Fedora 9 - PyOpenGL-3.0.0-0.5.b1.fc9.noarch - freeglut-2.4.0-14.fc9.x86_64 - python-2.5.1-25.fc9.x86_64 b) Arch Linux 03052008 - python 2.5.2-2 - python-opengl 3.0.0b1-1 - freeglut 2.4.0-3 ---------------------------------------------------------------------- Comment By: hippodriver (hippodriver) Date: 2008-05-03 09:16 Message: Logged In: YES user_id=1981020 Originator: NO I get the same error on Fedora 9 AMD64 and Arch Linux ia32. Here are the library versions: a) Fedora 9 - PyOpenGL-3.0.0-0.5.b1.fc9.noarch - freeglut-2.4.0-14.fc9.x86_64 - python-2.5.1-25.fc9.x86_64 b) Arch Linux 03052008 - python 2.5.2-2 - python-opengl 3.0.0b1-1 - freeglut 2.4.0-3 ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-04-07 00:45 Message: Logged In: YES user_id=34901 Originator: NO I can't reproduce the bug on a 64-bit Gentoo AMD64 machine running Python 2.5.1 and current CVS head against media-libs/freeglut-2.4.0-r1 . That is, the script runs here (I develop on this amd64 Gentoo box normally). Can you give more details about your library versions? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-25 10:58 Message: Logged In: NO What's going on this bug is still present in Ubuntu Gutsy (64 bits version), are pyopengl abandoned? or is there a secret bugfix? Nothing has happened with this bug for 4 month. A segfault on 64-bits Linux has to be considered a quite severe bug. I'm very new to Python but I need it for a course in 3d rendering at school so if there is some debugging I can do please let me know, but I think it's quite easy to reproduce. /Bjrn ---------------------------------------------------------------------- Comment By: Gary Orser (orser) Date: 2007-06-14 17:53 Message: Logged In: YES user_id=82696 Originator: NO Forgot to add: The script I used to build this python, generates a python that doesn't seg fault on Fiesty 32bit. It also seg faults, on SuSE 10.1 64 bit. This must be some sort of 64 bit issue. ---------------------------------------------------------------------- Comment By: Gary Orser (orser) Date: 2007-06-14 15:48 Message: Logged In: YES user_id=82696 Originator: NO Forgot to add: The script I used to build this python, generates a python that doesn't seg fault on Fiesty 32bit. It also seg faults, on SuSE 10.1 64 bit. This must be some sort of 64 bit issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1737282&group_id=5988 |
|
From: Renaud B. <ren...@im...> - 2008-06-20 09:40:29
|
hi list, i'm using pycairo to generate pictures. it uses the python buffer type to return the raw data. it would be great if functions such as DrawPixels could handle such array object. attached is a small patch against PyOpenGL-3.0.0b3 that modifies OpenGL/arrays/strings.py to make StringHandler also handle buffer objects. it works for my use case, but it may not be the best way to handle buffer. any suggestion ? if this patch is reasonable, what is the way to push it into the PyOpenGL distribution ? thanks, renaud diff -ru PyOpenGL-3.0.0b3/OpenGL/arrays/strings.py PyOpenGL-3.0.0b3- mine/OpenGL/arrays/strings.py --- PyOpenGL-3.0.0b3/OpenGL/arrays/strings.py 2008-06-13 18:17:52.000000000 +0200 +++ PyOpenGL-3.0.0b3-mine/OpenGL/arrays/strings.py 2008-06-20 11:18:06.000000000 +0200 @@ -7,7 +7,7 @@ class StringHandler( formathandler.FormatHandler ): """String-specific data-type handler for OpenGL""" - HANDLED_TYPES = (str, ) + HANDLED_TYPES = (str, buffer) from_param = staticmethod( dataPointer ) dataPointer = staticmethod( dataPointer ) def zeros( self, dims, typeCode=None ): @@ -31,6 +31,8 @@ """Convert given value to an array value of given typeCode""" if isinstance( value, str ): return value + elif isinstance( value, buffer ): + return str(value) elif hasattr( value, 'tostring' ): return value.tostring() elif hasattr( value, 'raw' ): |
|
From: SourceForge.net <no...@so...> - 2008-06-13 16:33:38
|
Bugs item #1959860, was opened at 2008-05-07 19:08 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: glReadPixels breaks 2.x compat. breaks pygame. Initial Comment: Hi, with glReadPixels changing its interface from 1, 2.x, it breaks pygame.image.save(screen). This is the only pyopengl function that pygame uses. It would be nice if pyopengl 3.x kept the same interface, of returning a string. cheers, ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-13 12:33 Message: Logged In: YES user_id=34901 Originator: NO Forgot to close. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-13 12:33 Message: Logged In: YES user_id=34901 Originator: NO Okay, glReadPixels and glGetTexImage now return strings in the default calls iff you specify GL_UNSIGNED_BYTE format. There's a test case that should trigger if that changes in the future. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-10 22:46 Message: Logged In: YES user_id=34901 Originator: NO Okay, I'm swayed. I was thinking of using the Python string as an input. If you convert from another object it should be fine. I'm okay with the change (can't say I like it, but compatibility is a pretty high priority). If you don't get to it I'll try to get it done on Friday before doing a release. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2008-06-06 19:35 Message: Logged In: YES user_id=2042 Originator: NO Hi, lots of old versions of pygame are still in use - so this pyopengl API break is still important to fix for pyopengl+pygame users using old versions of pygame. I don't think it should always return a string, but instead default to returning a string. This will break less software since this is what 1.x and 2.x do. Note pygame using programs are not the only program that expects a string to be returned. I don't know what you're talking about with the small string caching mechanisms breaking things? Is this a pyopengl3 small string cache? You can just convert a ctypes string to a python string with no issues. I can make the fix if you think it's ok? Here's a work around screenshot function for gl - that works for all versions of pyopengl. The main lines are these: data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() Where it looks to see if the return variable has a tostring() method - which is what the numpy instance has. def savescreen(screen, filename): def readScreen(x, y, width, height): """ Read in the screen information in the area specified """ glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() return data def saveImageData(width, height, data, filename): """ Save image data """ surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 12:44 Message: Logged In: YES user_id=34901 Originator: NO Pygame has already changed their code to support PyOpenGL 3.x, the new version allows the user to specify the data-type they want to have returned from array-producing code, but at the moment strings are not an option (no way to generate them in the correct dimensions yet without potentially falling afoul of the small-string caching mechanisms). I'm afraid I'll have to mark this "won't fix" as a result. If you feel this is a major problem, reopen the ticket and I'll consider it again, but aside from maybe implementing a "string" output type that could be selected, I don't see it as a desirable change to make the function always return strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-13 16:33:01
|
Bugs item #1959860, was opened at 2008-05-07 19:08 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: glReadPixels breaks 2.x compat. breaks pygame. Initial Comment: Hi, with glReadPixels changing its interface from 1, 2.x, it breaks pygame.image.save(screen). This is the only pyopengl function that pygame uses. It would be nice if pyopengl 3.x kept the same interface, of returning a string. cheers, ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-13 12:33 Message: Logged In: YES user_id=34901 Originator: NO Okay, glReadPixels and glGetTexImage now return strings in the default calls iff you specify GL_UNSIGNED_BYTE format. There's a test case that should trigger if that changes in the future. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-10 22:46 Message: Logged In: YES user_id=34901 Originator: NO Okay, I'm swayed. I was thinking of using the Python string as an input. If you convert from another object it should be fine. I'm okay with the change (can't say I like it, but compatibility is a pretty high priority). If you don't get to it I'll try to get it done on Friday before doing a release. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2008-06-06 19:35 Message: Logged In: YES user_id=2042 Originator: NO Hi, lots of old versions of pygame are still in use - so this pyopengl API break is still important to fix for pyopengl+pygame users using old versions of pygame. I don't think it should always return a string, but instead default to returning a string. This will break less software since this is what 1.x and 2.x do. Note pygame using programs are not the only program that expects a string to be returned. I don't know what you're talking about with the small string caching mechanisms breaking things? Is this a pyopengl3 small string cache? You can just convert a ctypes string to a python string with no issues. I can make the fix if you think it's ok? Here's a work around screenshot function for gl - that works for all versions of pyopengl. The main lines are these: data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() Where it looks to see if the return variable has a tostring() method - which is what the numpy instance has. def savescreen(screen, filename): def readScreen(x, y, width, height): """ Read in the screen information in the area specified """ glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() return data def saveImageData(width, height, data, filename): """ Save image data """ surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 12:44 Message: Logged In: YES user_id=34901 Originator: NO Pygame has already changed their code to support PyOpenGL 3.x, the new version allows the user to specify the data-type they want to have returned from array-producing code, but at the moment strings are not an option (no way to generate them in the correct dimensions yet without potentially falling afoul of the small-string caching mechanisms). I'm afraid I'll have to mark this "won't fix" as a result. If you feel this is a major problem, reopen the ticket and I'll consider it again, but aside from maybe implementing a "string" output type that could be selected, I don't see it as a desirable change to make the function always return strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-11 02:46:48
|
Bugs item #1959860, was opened at 2008-05-07 19:08 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: glReadPixels breaks 2.x compat. breaks pygame. Initial Comment: Hi, with glReadPixels changing its interface from 1, 2.x, it breaks pygame.image.save(screen). This is the only pyopengl function that pygame uses. It would be nice if pyopengl 3.x kept the same interface, of returning a string. cheers, ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-10 22:46 Message: Logged In: YES user_id=34901 Originator: NO Okay, I'm swayed. I was thinking of using the Python string as an input. If you convert from another object it should be fine. I'm okay with the change (can't say I like it, but compatibility is a pretty high priority). If you don't get to it I'll try to get it done on Friday before doing a release. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2008-06-06 19:35 Message: Logged In: YES user_id=2042 Originator: NO Hi, lots of old versions of pygame are still in use - so this pyopengl API break is still important to fix for pyopengl+pygame users using old versions of pygame. I don't think it should always return a string, but instead default to returning a string. This will break less software since this is what 1.x and 2.x do. Note pygame using programs are not the only program that expects a string to be returned. I don't know what you're talking about with the small string caching mechanisms breaking things? Is this a pyopengl3 small string cache? You can just convert a ctypes string to a python string with no issues. I can make the fix if you think it's ok? Here's a work around screenshot function for gl - that works for all versions of pyopengl. The main lines are these: data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() Where it looks to see if the return variable has a tostring() method - which is what the numpy instance has. def savescreen(screen, filename): def readScreen(x, y, width, height): """ Read in the screen information in the area specified """ glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() return data def saveImageData(width, height, data, filename): """ Save image data """ surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 12:44 Message: Logged In: YES user_id=34901 Originator: NO Pygame has already changed their code to support PyOpenGL 3.x, the new version allows the user to specify the data-type they want to have returned from array-producing code, but at the moment strings are not an option (no way to generate them in the correct dimensions yet without potentially falling afoul of the small-string caching mechanisms). I'm afraid I'll have to mark this "won't fix" as a result. If you feel this is a major problem, reopen the ticket and I'll consider it again, but aside from maybe implementing a "string" output type that could be selected, I don't see it as a desirable change to make the function always return strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-06 23:35:34
|
Bugs item #1959860, was opened at 2008-05-07 23:08 Message generated for change (Comment added) made by illume You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 >Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: glReadPixels breaks 2.x compat. breaks pygame. Initial Comment: Hi, with glReadPixels changing its interface from 1, 2.x, it breaks pygame.image.save(screen). This is the only pyopengl function that pygame uses. It would be nice if pyopengl 3.x kept the same interface, of returning a string. cheers, ---------------------------------------------------------------------- >Comment By: Rene Dudfield (illume) Date: 2008-06-06 23:35 Message: Logged In: YES user_id=2042 Originator: NO Hi, lots of old versions of pygame are still in use - so this pyopengl API break is still important to fix for pyopengl+pygame users using old versions of pygame. I don't think it should always return a string, but instead default to returning a string. This will break less software since this is what 1.x and 2.x do. Note pygame using programs are not the only program that expects a string to be returned. I don't know what you're talking about with the small string caching mechanisms breaking things? Is this a pyopengl3 small string cache? You can just convert a ctypes string to a python string with no issues. I can make the fix if you think it's ok? Here's a work around screenshot function for gl - that works for all versions of pyopengl. The main lines are these: data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() Where it looks to see if the return variable has a tostring() method - which is what the numpy instance has. def savescreen(screen, filename): def readScreen(x, y, width, height): """ Read in the screen information in the area specified """ glFinish() glPixelStorei(GL_PACK_ALIGNMENT, 4) glPixelStorei(GL_PACK_ROW_LENGTH, 0) glPixelStorei(GL_PACK_SKIP_ROWS, 0) glPixelStorei(GL_PACK_SKIP_PIXELS, 0) data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE) if hasattr(data, "tostring"): data = data.tostring() return data def saveImageData(width, height, data, filename): """ Save image data """ surface = pygame.image.fromstring(data, (width, height), 'RGB', 1) pygame.image.save(surface, filename) data = readScreen(0,0, screen.get_width(), screen.get_height()) saveImageData(screen.get_width(), screen.get_height(), data, filename) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 16:44 Message: Logged In: YES user_id=34901 Originator: NO Pygame has already changed their code to support PyOpenGL 3.x, the new version allows the user to specify the data-type they want to have returned from array-producing code, but at the moment strings are not an option (no way to generate them in the correct dimensions yet without potentially falling afoul of the small-string caching mechanisms). I'm afraid I'll have to mark this "won't fix" as a result. If you feel this is a major problem, reopen the ticket and I'll consider it again, but aside from maybe implementing a "string" output type that could be selected, I don't see it as a desirable change to make the function always return strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-06 19:45:27
|
Bugs item #1985513, was opened at 2008-06-05 10:31 Message generated for change (Settings changed) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1985513&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Mike C. Fletcher (mcfletch) Summary: glutReshapeFunc crash Initial Comment: Have found on several winxp/sp2 systems that any program using a glutReshapeFunc() call will crash when the window is resized regardless of the actual reshape function contents. glGetError is never triggered although python returns -1073741819 Problem can be seen with demo examples such as nehe/lesson1.py ian...@gm... ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 15:45 Message: Logged In: YES user_id=34901 Originator: NO Freaky. It appears that Win32 GLUT uses different calling conventions for the API functions and the callback functions? Anyway, with fixes in CVS reshape function appears to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1985513&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-06 16:44:12
|
Bugs item #1959860, was opened at 2008-05-07 19:08 Message generated for change (Settings changed) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Mike C. Fletcher (mcfletch) Summary: glReadPixels breaks 2.x compat. breaks pygame. Initial Comment: Hi, with glReadPixels changing its interface from 1, 2.x, it breaks pygame.image.save(screen). This is the only pyopengl function that pygame uses. It would be nice if pyopengl 3.x kept the same interface, of returning a string. cheers, ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 12:44 Message: Logged In: YES user_id=34901 Originator: NO Pygame has already changed their code to support PyOpenGL 3.x, the new version allows the user to specify the data-type they want to have returned from array-producing code, but at the moment strings are not an option (no way to generate them in the correct dimensions yet without potentially falling afoul of the small-string caching mechanisms). I'm afraid I'll have to mark this "won't fix" as a result. If you feel this is a major problem, reopen the ticket and I'll consider it again, but aside from maybe implementing a "string" output type that could be selected, I don't see it as a desirable change to make the function always return strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1959860&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-06 16:35:12
|
Bugs item #1979002, was opened at 2008-05-30 04:34 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1979002&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Mike C. Fletcher (mcfletch) Summary: Segfault with glReadPixelsf Initial Comment: PyOpenGL version: 3.0.0b2 Numpy version: 1.0.4 Platform: Windows XP SP 2 GPU: NVidia 8800GTS, 169.21 driver version Attempting to perform a glReadPixelsf on a 512x512 frame buffer causes a crash. In fact, every format I tried besides glReadPixelsub crashes. Thanks, Eddy Talvala, ta...@st... Minimum testcase that shows crash on my system attached. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-06-06 12:35 Message: Logged In: YES user_id=34901 Originator: NO You are correct, size of the element should be handled solely via the component count. I've updated the code in CVS, should show up in the next release. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-01 16:15 Message: Logged In: NO One additional note: Shouldn't formatBits for GL_LUMINANCE_ALPHA=16, not 8 (defined in OpenGL.GL.images) according to the current convention, as it returns two components, not one? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-01 15:49 Message: Logged In: NO Further experimentation appears to show that the bug is in OpenGL.images.createTargetArray createTargetArray attempts to create, based on the pixel format and the color channel type, a zero array of sufficient size. However, the calculation seems incorrect for the case of an RGB float array, at least. After adding some prints inside createTargetArray, and calling glReadPixels with: readback_image1 = glReadPixelsub(0,0,512,512,GL_RGB) I get the following values for the variables inside createTargetArray: formatBits: 24 typeBits: 8 lastDim, remainder: 3, 0 dims: (512, 512, 3) arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> Which is correct, and works fine. However, the same variables for the call readback_image2 = glReadPixelsf(0,0,width,height,GL_RGB) aren't correct: formatBits: 24 typeBits: 32 dims: (512, 512) arrayType: <class 'OpenGL.arrays.arraydatatype.GLfloatArray'> Most importantly, the dims tuple is wrong - the data has three color channels, each of which is a float. A 512x512 float array is 3 times too small to contain it, and explains why the code then crashes when simple.glReadPixels is called using the array returned by createTargetArray. Also, formatBits=24 makes little sense for a RGB float texture (where a pixel takes up 96 bits) unless formatBits=24 simply means '3 components'. It would seem at first glance that lastDim should simply be set based on format, not based on comparisons between formatBits and typeBits. Perhaps this code is holdover from an earlier version, where multiple color channels were stuffed into a single array entry, which no longer appears to be the case. Hope this helps, Eddy Talvala, <lastname> at stanford.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1979002&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-05 14:31:40
|
Bugs item #1985513, was opened at 2008-06-05 07:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1985513&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: glutReshapeFunc crash Initial Comment: Have found on several winxp/sp2 systems that any program using a glutReshapeFunc() call will crash when the window is resized regardless of the actual reshape function contents. glGetError is never triggered although python returns -1073741819 Problem can be seen with demo examples such as nehe/lesson1.py ian...@gm... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1985513&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-06-01 20:15:02
|
Bugs item #1979002, was opened at 2008-05-30 01:34 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1979002&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault with glReadPixelsf Initial Comment: PyOpenGL version: 3.0.0b2 Numpy version: 1.0.4 Platform: Windows XP SP 2 GPU: NVidia 8800GTS, 169.21 driver version Attempting to perform a glReadPixelsf on a 512x512 frame buffer causes a crash. In fact, every format I tried besides glReadPixelsub crashes. Thanks, Eddy Talvala, ta...@st... Minimum testcase that shows crash on my system attached. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-01 13:15 Message: Logged In: NO One additional note: Shouldn't formatBits for GL_LUMINANCE_ALPHA=16, not 8 (defined in OpenGL.GL.images) according to the current convention, as it returns two components, not one? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-06-01 12:49 Message: Logged In: NO Further experimentation appears to show that the bug is in OpenGL.images.createTargetArray createTargetArray attempts to create, based on the pixel format and the color channel type, a zero array of sufficient size. However, the calculation seems incorrect for the case of an RGB float array, at least. After adding some prints inside createTargetArray, and calling glReadPixels with: readback_image1 = glReadPixelsub(0,0,512,512,GL_RGB) I get the following values for the variables inside createTargetArray: formatBits: 24 typeBits: 8 lastDim, remainder: 3, 0 dims: (512, 512, 3) arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> Which is correct, and works fine. However, the same variables for the call readback_image2 = glReadPixelsf(0,0,width,height,GL_RGB) aren't correct: formatBits: 24 typeBits: 32 dims: (512, 512) arrayType: <class 'OpenGL.arrays.arraydatatype.GLfloatArray'> Most importantly, the dims tuple is wrong - the data has three color channels, each of which is a float. A 512x512 float array is 3 times too small to contain it, and explains why the code then crashes when simple.glReadPixels is called using the array returned by createTargetArray. Also, formatBits=24 makes little sense for a RGB float texture (where a pixel takes up 96 bits) unless formatBits=24 simply means '3 components'. It would seem at first glance that lastDim should simply be set based on format, not based on comparisons between formatBits and typeBits. Perhaps this code is holdover from an earlier version, where multiple color channels were stuffed into a single array entry, which no longer appears to be the case. Hope this helps, Eddy Talvala, <lastname> at stanford.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1979002&group_id=5988 |
32 messages has been excluded from this view by a project administrator.
