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

[Patrick D. <ma...@pd...>]

Am 05.04.2013 17:10, schrieb Mike C. Fletcher:
> On 13-04-05 09:44 AM, Mike C. Fletcher wrote:
>> On 13-04-04 06:21 PM, Chris Barker - NOAA Federal wrote:
>>> On Thu, Apr 4, 2013 at 10:31 AM, Mike C. Fletcher
>>> <mcf...@vr...> wrote:
>> ...
>>>> As for the original error, it *could* be that there's a problem 
>>>> with 64-bit
>>>> windows there, but I'm a bit skeptical, as 64-bit Linux doesn't 
>>>> show any
>>>> problems, and the test_core.py script actually generates a framebuffer
>>>> during testing if glGenFrameBuffers is available.  That's my very 
>>>> first
>>>> smoke-test for the build working on any platform.
>>> well, IIUC, LInux (gcc) 64 bit gives you 64 bits for and "int" and
>>> Windows (MSVC) gives you 23 bits for an "int", or something like that
>>> -- there is defiantly a difference in there somewhere (maybe it's
>>> long?) Anyway, I think it sure could be a non-issue on LInux, and kill
>>> you on windows.
>> I'm pretty sure we would have hit a 23-bit integer bug before this .
>> All of PyOpenGL is using GLint = ctypes.c_int (which was taken from the
>> Linux GL headers), and if my reading of the spec is correct, c_int is
>> pretty close to what is meant (it should be c_long, as the minimum width
>> is 32 bits, but I don't think there are any platforms we actually
>> support which use 16-bit ints).
> I just now realized "23" was just mis-typed 32 (duh!)
>
> It turns out that, while I've been running test_core for 32-bit Python
> on Win64, I *haven't* been running it for 64-bit Python on Win64
> (because I didn't have 64-bit Pygame or Numpy installed (now fixed)).
> Test core did fail due to the use of a Python int for an IntConstant
> where the value was 0xffffffff, (Python's int is apparently 32-bit on
> 64-bit Python, sigh).  With that fixed (in bzr head), running:
>
>       test_core.py Tests.test_fbo
>
> *does* run correctly on a Win64 machine with 64-bit Python, Pygame and
> Numpy.  That is, I am using:
>
>           fbo = glGenFramebuffers(1)
>
> and getting the expected frame buffer, then rendering something into it,
> then rendering a quad with that texture on it.
>
> Weird thing is, you couldn't even *import* PyOpenGL on 64-bit Python...
> so either it got broken rather recently or something fishy is occurring.
>
> I'm still seeing a test failure on GLU tessellation (possibly a
> pointer-size issue)...
>
> Patrick, could you test that the above test runs on your configuration?
> If it doesn't, we're likely looking at a platform or driver bug.  If it
> does, then we'll need more investigation.  You shouldn't actually need
> bzr head for that test, but feel free to use it if you'd prefer.
>
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.

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?

Cheers,
Patrick