Thank you very much for the (very quick!) reply. Changing the code to refer
glCreateShader = OpenGL.GL.glCreateShader
etc. solved that problem. Unfortunately, there is still an error, namely
ValueError: glShaderSource requires 2 arguments (shaderObj, string),
(2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>)
(I have kept the
glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p),
in the source.)
In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote
I'm guessing what's
happening is that you are on Win32, and that at the point where you import
the module, there's no glShaderSource function. As a result the wrappers
were not being created. Later, when you tried to call them, the
null-function wrapper was able to resolve the function and tried to call it
Is there a workaround for this? I had a look at the example you mentioned
in that post, and it references glShaderSourceARB rather than
glShaderSource. I can switch to ARB extensions if need be, but I'd like to
understand why the straightforward 2.0 approach isn't working, i.e. why
there's no glShaderSource function when the module is imported.
It sounds like I might be asking for help in an inappropriate place, in
that I'm not really using the functionality of PyOpenGL. (I am very
grateful for the previous assistance!) Would you happen to know of a more
appropriate mailing list or forum?
PS. My mail client is misbehaving -- I've waited half an hour to avoid
double posts, but in case something went wrong I'm very sorry!
I fooled around with these kinds of problems quite a bit and the best
way to make it work without too much work, is to switch all your OpenGL
code to their ARB equivalents. Best thing is that it makes it portable
across platforms as well. If you use the ARB function calls instead of
the "normal" ones, Windows, Mac OS X and Linux usually works 99% of the
time (not including driver differences).
I'm not completely clear on the problem, but it has something to do
with how/when the functions are bound to their OpenGL functions.
Windows binds them later on, while Mac OS X and Linux bind them earlier
(from what I've seen so far). Maybe Windows binds them when you call
the Glut init functions, but I'm sure Mike can give you a better answer
regarding the problem.