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:
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.
Oh, I know about the general problems of calling a function without a proper context
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.
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.