Re: [PyOpenGL-Users] Difficulty accessing glCreateShader

[Mike C. F. <mcf...@vr...>]

Mohan wrote:
> Hi Mike,
>
> Thank you very much for the (very quick!) reply. Changing the code to refer 
> to
>
>    glCreateShader = OpenGL.GL.glCreateShader 
>
> etc. solved that problem. Unfortunately, there is still an error, namely
>
>    ValueError: glShaderSource requires 2 arguments (shaderObj, string), 
> received 4:
>     (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>)
>  
> (I have kept the
>
>    glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), 
> POINTER(c_int)]
>
> in the source.)
>   
Sorry, I should have been more verbose in the explanation.  You are 
using code that uses the equivalent of the "raw" PyOpenGL api, i.e. raw 
ctypes-coded interfaces with the C DLL.  You can certainly continue to 
do that, or you can switch to using the PyOpenGL API.  The code sample 
you are using as a source is from before PyOpenGL supported the 2.x (or 
3.x) extension functions, so it's showing you the raw C-style API 
calls.  Probably would be easier to use a sample written for PyOpenGL 
3.x to get started faster.  There's a sample in OpenGLContext, another 
in the proesch PyOpenGL-Demo subdirectory, and a third in the 
PyOpenGL-Demo/GLUT subdirectory IIRC.

You shouldn't need any ctypes references to work with PyOpenGL unless 
you want to use ctypes data-types (arrays).  You shouldn't ever need to 
specify argtypes for a PyOpenGL function, at least.
> 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
> directly.<
>
> 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.
>   
This is an allowed OpenGL operating modality, and apparently some driver 
writers are relying on it.  Basically the work-around is to only do the 
calls *after* you have a rendering context available from which to 
retrieve the functions.  It shouldn't happen with *core* functions 
AFAIK, it should only happen with ARB, EXT or other extension functions.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com