I'm trying to understand what/how/if PyOpenGL deals with multiple
versions of OpenGL. For example, if I run PyOpenGL on a machine with
OpenGL 1.3 libraries, I should have multitexturing abilities built-in
(e.g. glActiveTexture() function). This is specified in the OpenGL 1.3
Another example is that with OpenGL 1.2, the GL_CLAMP_TO_EDGE constant
should be defined.
However, PyOpenGL doesn't provide these names in the GL module when run
on an appropriate system. I wonder if this is simply an oversight
which would be easily fixed, a purposeful omission because runtime GL
version checking and name exporting may be tricky, or has never been
Incidentally, on linux, I can get around the missing glActiveTexture()
function by using ctypes to load the function. (On Windows, I get an
error that the arguments must be 4 bytes longer... I haven't tracked
this down, though.) Another workaround is that some OpenGL 1.3 drivers
(nVidia) still support the multitexturing ARB extension, but others
(ATI) don't. This success with ctypes and the continued good things I
hear about Pyrex make me wonder if maybe the PyOpenGL build system
could be simplified by getting away from SWIG and using these two
So, what's the story? Anyone know?
From: Mike C. Fletcher <mcfletch@ro...> - 2003-10-26 04:02:08
Andrew Straw wrote:
> Mike C. Fletcher wrote:
>> PyOpenGL is currently limited to OpenGL 1.1. At the moment, I don't
>> have drivers which support features from OpenGL 1.2 or above.
> You can always run Mesa to get OpenGL 1.4. (It's not HW accelerated,
> but it'll at least let you test.)
Hmm, have you actually done this? Seems like we don't have any support
for Win32 mesa built-in. Changing the linked libraries works partially,
but it would require figuring out all the *Context functions and adding
an entry to config.h unless I'm missing some simple way to drop it in.
I've spent a few hours playing with this so far and not yet figured out
what functions Mesa is supposed to export on Win32 (I assume the ones in
the wmesa.h header file, but none of them show up when I'm building).
Curiouser and curiouser thought the white hare...
Mike C. Fletcher
Designer, VR Plumber, Coder
Mike C. Fletcher wrote:
> Andrew Straw wrote:
>> Mike C. Fletcher wrote:
>>> PyOpenGL is currently limited to OpenGL 1.1. At the moment, I don't
>>> have drivers which support features from OpenGL 1.2 or above.
>> You can always run Mesa to get OpenGL 1.4. (It's not HW accelerated,
>> but it'll at least let you test.)
> Hmm, have you actually done this? Seems like we don't have any support
> for Win32 mesa built-in. Changing the linked libraries works partially,
> but it would require figuring out all the *Context functions and adding
> an entry to config.h unless I'm missing some simple way to drop it in.
I haven't used it on Windows. With debian, Mesa is what you get by
default, so that's where my experience with it comes from.
In my experience on linux, I think it's a matter of making sure the
right library is picked up by the dynamic linker via placing mesa libs
or others in /usr/lib or /usr/X11/lib or whereever...
I didn't think there was special PyOpenGL support for Mesa. Perhaps
even if it's not needed on the linux side it would be needed on the
windows side?? (I did find some funkiness when trying to use ctypes on
Windows but not linux when trying to call OpenGL functions not bound by
PyOpenGL.) I haven't programmed OpenGL in C on Windows enough to know.