Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Mike C. F. <mcf...@vr...>]

On 13-04-06 11:55 AM, Patrick Dietrich wrote:
...
> OK here is what I did:
>
> - uninstalled PyOpenGL_accelerate and PyOpenGL (using Windows 
> Software-Removal)
> - downloaded PyOpenGL from bzr: "bzr branch lp:pyopengl"
> - built and installed PyOpenGL: "python setup.py build", "python 
> setup.py install"
> - downloaded 64-bit pygame 1.9.2pre from 
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame
> - executed "python test_core.py" in the test/ directory inside the 
> pyopengl directory from bzr
>      --> this fails (see attachment)
>
> I'm not sure if I have to change to the "head" distro somehow. Sorry 
> I'm not familiar with bzr.
Nope, that's head already.
> I also tried to test my drivers with a simple C-Program. Unfortunately 
> I can't get glew running with MinGW. But from what I read in the 
> conversation MinGW may yield different results that MSVC anyway?
It would tell us if it's hardware/drivers.

I followed the same steps, and on an Intel Graphics Win64 Windows 7 
machine this time... and got 0 errors for the test_core test suite (on 
bzr head).  The values you're seeing in the access violation reports 
*look* wrong, that is, the first 4 bytes are all 1's.  If you could 
print out:

     v = ctypes.c_uint()
     print ctypes.addressof( v )

for a value that's producing the error, it would at least let us know if 
the address is wrong before it goes into the wrapping process.  If the 
all-ones addresses are "real", then maybe we're seeing a driver issue 
with the greater than 2GB addresses (maybe drivers coded for 32-bit 
mode?)  If they are an artefact of the conversion process, then we can 
use pdb to step through the wrapping process one step at a time to try 
to figure out where the conversion gets messed up.

Take care,
Mike

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