Re: [PyOpenGL-Users] features from OpenGL > 1.1

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

Andrew Straw wrote:

> 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 spec:
> http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf

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.  There are 
a few extensions that, if I get the time, I might code up wrappers for, 
but they aren't the fun/sexy stuff for new hardware, I only have a 
Radeon 7500.

> 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.) 

Don't know.

> Another workaround is that some OpenGL 1.3 drivers (nVidia) still 
> support the multitexturing ARB extension, but others (ATI) don't.  

Hmm, strange.  They really should be providing OpenGL 1.1 drivers with 
the extensions alongside the 1.3 drivers... sigh.  Not that it would 
help much, as we don't have the extensions in many (most) cases.

> 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 technologies?

ctypes is likely to be too slow for more than a few functions, as 
there's a lot of manipulation required to make the Python objects OpenGL 
compatible.  Pyrex is possible, but in the end, it's almost the same 
problem as with the SWIG system, you wind up needing to extend Pyrex to 
support polymorphic array parameters, to provide the bridge code for 
various Python-ised calls, etceteras.  Code complexity doesn't go down 
much AFAICS... that said, if someone wants to prove me wrong, I'd be 
delighted :) .  I'd be more interested in seeing someone model the whole 
problem in Python with a code-generator to create SWIG, Pyrex or Ctypes 
code for any given function so that we could try them all out alongside 
one another (and maybe add a straight C code generator to see if that 
makes things easier...).  Oh well.

> So, what's the story?  Anyone know?

HTH,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/