Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers
Brought to you by:
mcfletch
From: Mike C. F. <mcf...@vr...> - 2013-04-05 15:10:54
|
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. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |