#98 glGenTextures () --> [long], while glBindTexture (int)

GL (74)
Brian Leair

I think there is a bug in the PyOpenGL interface to
glGenTextures/glBindTexture ().

If I ask for a single texture and bind to it I don't
experience a problem, however if I ask glGenTexture ()
for several texture IDs at a time I end up getting an
overflow exectption when I try to BindTexture.
I get the exception "OverflowError: long int too large
to convert to int" on my call to glBindTexture ().

Here is an example of python code that I would expect
to work:
def build_textures ():
# Ask for 128 texture IDs -
texture_names = glGenTextures (128)

# Bind each texture
for ID in texture_names:
glBindTexture (GL_TEXTURE_2D, ID)
# ...

# In C, something analogous would be:
# GLuint texture_names [128];
# glGenTextures (128, texture_names);
# ...
# int i;
# for (i=0; i<128; i++)
# {
# glBindTexture (GL_TEXTURE_2D, texture_names [i]);
# ...
# }

I'm running on WIndows 2000, ATI drivers, python 2.2.3,
and PyOpenGL

When I get the exception it is for texture_names [2]
and the ID is a value of 424967295 (-2).

Looking at the SWIG code that wraps glGenTextures and
glBindTexture, I see GenTextures creating a tuple from
the array of GLuints and returning that. This creates a
Tuple of python longs. I also see that BindTexture
parses its arguments as "ii". for the GLenum and for
the GLuint. If python longs have to be used, then
BindTexture () needs to be changed to take a long.

Texture IDs are opqaue values, so would it be an
acceptable apparoach to just have PyOpenGL use python
ints for texture IDs (when pytohn's sizoef (int) ==
sizeof (GLuint)).

Are there reasons why texture IDs as ints (signed) in
python would be bad?


  • Brian Leair
    Brian Leair

    Logged In: YES

    It appears that this is now fixed in PyOpenGL v
    glBindTexture now operates on an argument of a python long

  • Brian Leair
    Brian Leair

    • summary: glGenTextures () --> [long], while glBindTexture (int) --> glGenTextures () --> [long], while glBindTexture (int)
    • assigned_to: nobody --> mcfletch
    • status: open --> closed-out-of-date
  • Logged In: YES

    Okay, marking this fixed given report from original reporter
    that it works on