Re: Setting Up on New Machine

On 12-02-25 07:19 PM, Ian Mallett wrote:
> On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     The tess issues seem to have been there for a long time; it works
>     perfectly well in OpenGLContext' usage and tests, and even works
>     if I copy the OpenGLContext test into a raw test, but the original
>     test doesn't generate vertices (it wasn't checking for that
>     previously).  At this point I'm assuming this is just a test-setup
>     issue, so not a critical fix.
>
> Yeah, I'm not too concerned about gluTess* stuff; there's hardware 
> support for tessellation now, which is better.  And I can honestly 
> say, I've not had need for either.
>
> I am having a new problem, however.  glutInit is failing.  The error 
> looks something like:
>
>     Traceback (most recent call last):
>       File "<pyshell#2>", line 1, in <module>
>         glutInit()
>       File
>     "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py",
>     line 324, in glutInit
>         _base_glutInit( ctypes.byref(count), holder )
>     TypeError: 'NoneType' object is not callable
>
> There are similar problems with other GLUT functions.  I read 
> somewhere that this may be due to 64 bit issues (i.e., PyOpenGL is 
> trying to use a glut32.dll compiled for 32 bit platforms).  Is this 
> the case?  And is there a way to solve it for the general case?
>
> Thanks,
> Ian
Alright, I'm now set up and able to build GLUT and GLE in both 32 and 
64-bit configurations.  I'm working on making the build process for both 
of those automatic so that maintaining them won't be a royal pain when 
e.g. we need to build for Python 3.x compiler as well.  I've also got 
the latest (trunk) PyOpenGL accelerate modules built for 32 and 64-bit.

Not really sure about the 32-bit/64-bit issues for GLUT and GLE.  From 
what I read you can't load the 32-bit DLLS at all in a 64-bit build (and 
vice versa), so it seems we'll need to provide completely separate 32 
and 64-bit DLLS packages/directories or have the DLLS be e.g. glut64.dll 
and opengle64.dll.  My preference is for the latter, as that way you can 
still run PyOpenGL from a bzr checkout.  The idea would be to use 
platform.architecture() to query the DLL size *only* on Windows 
(apparently .architecture has problems on OSX).  Using sys.maxint does 
not *appear* to work, as on both my 64-bit build of Python it seems to 
return 2**31-1, which makes me think "WTF, is this the wrong Python"?.

If anyone sees any problems with that (glut64.dll, opengle64.dll), let 
me know, otherwise I'll try to finish up the build process and integrate 
the 64-bit DLLs into the packages.

Have fun,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com


------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net