I am playing with texturing in OpenGL and I have bumped into something I don't understand concerning texture coordinates: I have a 512x512 texture and thought both codes would behave in the same way : But they don't. The code using glTexCoord2f gives me what I want, but the code using glTexCoord2i gives very strange results, where the texture appears to be totally messed up depending on size's value.

The two functions behave the exact same way, by setting texture coordinates. Your use of glTexCoord2i attempts to set texels. So, glTexCoord2i(1, 1), will give you the results you're after.

The docs don't make any distinction between them, apart from parameter types.

The entry in the blue book for glTexCoord doesn't say anything about how integer values are interpreted, helpfully. (http://glprogramming.com/blue/ch05.html#id5535535)

The red book has this to say:

"Note that integer texture coordinates are interpreted directly rather than being mapped to the range [-1,1] as normal coordinates are." (http://glprogramming.com/red/chapter09.html#name6)

So they're interpreted directly, but with reference to what? I *think* that this means maybe you should be using 0 and 1 for the int code, same as for the float code. Although this would mean you can't use ints for accurate positioning. :o

Have you tried using your (int) size, or maybe size-1, as the non-zero argument to the int version? (Assuming size is something other than 512, which you've already tried...) Maybe they mean "interpreted directly in world units"...?

This has puzzled me too, but I hadn't gotten around to investigating yet.

Yes I find the documentation on the subject very light (The blue book is a real joke).
I have even taken a look at the opengl specifications but haven't found anything interesting.

I really wonder how one is supposed to reference texture coordinates with pixel precision. I understand the purpose of glTexCoord2f with the [0.0 ; 1.0] coordinate system (which by the way is different from what the red book says when talking about [-1; 1] mapping), but when dealing with simple 2D blits this approach doesn't look like the most simple one.

PS : The only purpose of my size variable is to draw quads of different sizes, but I wouldn't expect it to have any influence on the texture coordinates. Although it clearly has when using glTexCoord2i.

glTexCoord2i() is for INTEGER values, and

glTexCoord2f() is for floating point values.

if you are only using 1,2,3,4,5, ect... then integer is fine, but if you need to use the fractional part of a whole number you need to use glTexCoord2f()

Hope this clears this up.

What I am looking for is something describing the texture coordinate system when using integers.
When using floats the system ranges from coordinate (0.0, 0.0) to coordinate (1.0, 1.0).

But I have strong doubts that this is the same with integers. Instead I would have expected the system to range from coordinate (0, 0) to coordinate (texture_size - 1, texture_size - 1). But when doing some tests this assumption appears to be wrong. Else my 1st piece of code would behave like my 2nd one, but this is not the case.

No matter what function you use, the texture coordinates are specified in normalized coordinates; integers or not. That means you're tiling the texture 511 times in your example. However...

glMatrixMode(GL_TEXTURE);glLoadIdentity();glScalef(1/texture_width, 1/texture_height, 1);

Now you can reference the texture with texel coordinates instead, as they will be scaled to proper normalized coordinates automatically. Also, keep in mind that the full texture is referenced in the range [0, texture_width/height], not [0, texture_width/height-1].

Thanks Brother Bob, this makes sense.
And concerning "[0, texture_width/height], not [0, texture_width/height-1]", this was also tickling me, as else it wouldn't have been coherent with [0.0, 1.0].

From what I understand it seems that directly using normalized float coordinates is more natural than bothering with integers.