On 10/20/08, Greg Ewing <[EMAIL PROTECTED]> wrote: > How exactly do they fail? Do you get an exception? Well, they certainly don't run right out of the box.
The ARB example seems more complete, but it whines about the ARB extensions--how it can't find them for some reason. Probably because the proper import statements aren't there (I don't know them, and they weren't included). Changing them to non-ARB functions fixes this problem, but then a host of other problems crops up involving the arguments to certain calls (specifics if requested). Nothing I tried seems to appease them. The not-ARB example comes in two files--the latter needing the addition of various statements to load the required modules. The end result looks somewhat like the modified ARB code, but in two files, and it doesn't work either. At some point, when the code just appears to have so many errors (I believe in this case due to PyOpenGL's progress, not to author incompetancy), I think it may be best just to start over with some new code. There has to be some working shader code that works with the current (or nearly current) version of PyOpenGL somewhere. > I think pyglet has its own wrappers for OpenGL, and > doesn't use PyOpenGL. I see. > I can't think of any reason that PyGame in particular > should fail to suppport shaders. The only involvement > that PyGame has with OpenGL is to provide you with an > OpenGL context. After that it's down to the capabilities > of the OpenGL wrapper you're using -- PyOpenGL, pyglet > or whatever. OK, but I'd be very suprised if PyOpenGL didn't support shaders. > You might try using PyOpenGL 3.x, which I gather is > based on ctypes as well. It might give you access to > some newer OpenGL features, if that's what the problem > is. I have PyOpenGL 3.0.0.b2 or something. I notice it goes up to b6. I'll upgrade when I get home just for kicks. Ian
