Well at least the redbook demos work (Running tests is a good thing...)
Written by
on
in
Snaking.
So, I decided I would try running all of the demos/tests that could be expected to run with the current state of OpenGL-ctypes. There's a considerable number of working tests (see the "continue reading" link below for more detail than anyone could possibly care about).
What's better, in doing so, I discovered a fairly big clue about the problems with glTexImage2D, namely that the problems do *not* occur if the texture-loading is delayed long enough. It appears that something about how I'm setting up the texture creation is trying to create textures without a valid current context. Will have to look into that next time I'm playing.
I spent a few minutes trying to get the glMap2[df] functions working. No go there; I seem to be messing up on calculating the strides and orders from the input array. No errors show up, but no pretty pictures either.
Anyway, think I'll check the current code in and try to stop thinking about it... still hoping for the elves to fix the code while I'm asleep :) . For the curious, the list of what demos/tests are currently working:
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
LarstiQ on 08/29/2005 8:15 a.m. #
Concerning your glTexImage2D problem, that's a fairly standard oops with OpenGL (including when just using C), operating prior to acquiring a context (say, from SDL_SetVideoMode) will not do that much, with textures you'll just get the default texture (all white in all implementations I've seen), since the upload had no effect.<br />
<br />
<br />
Mike Fletcher on 08/29/2005 9:18 a.m. #
Oh, I know about the *general* problems of calling a function without a proper context :) . The issue here is that the *same client code* as was working perfectly with PyOpenGL2 is failing under OpenGL-ctypes.<br />
<br />
Since the context is acquired from the GUI library when working in Python (i.e. the client code), there shouldn't be any differences assuming I've correctly mimiced (SP?) PyOpenGL2 in OpenGL-ctypes.<br />
<br />
I'm guessing there's some call that PyOpenGL2 is making in it's (involved) image wrappers that's allowing it to survive in this case while OpenGL-ctypes is raising errors.