I understand that GL_REPEAT parameter will ignore the integer portion of the texture coordinate, only the fractional part is used when doing texture mapping. The question is how OpenGL handles the texture border? For instance, if the texcoord is 2.0, the return value should be the same as the return value at texcoord 0.0 or at 1.0? I assume the "normal" texcoord is in [0.0,1.0] range, which is the most common texcoord range.
Thanks for your answer!
2.0 is clamped to 0.0, as it doesn't fall out of the [0, 1] range, it doesn't consider the texture border.
Your concrete example is interesting. Say you have a 1D texture of size 2 [a b]
What you actually get from a texture coordinate of 0.0 depends on filtering. It's not necessarily a. The only location where you have a and just a for LINEAR (ignoring mipmapping) is at texture coordinate 0.25. The same is true for b and 0.75.
At 0.0 and 1.0 (and 2.0, for that matter), you will get (a+b)/2 (again, LINEAR). It is not the case that 0 will give you a and 1 will give you b.
-0.25 0 0.25 .5 0.75 1 1.25 ...
_____________________________
| | |
B | A | B | A
_____________________________
In the case of NEAREST filtering, 0.0 and 1.0 are exactly on the edge of the texels, While I don't remember exactly what the specification says on that case, I would not rely on it.
All that said... All this is discussing the texture coordinates that are used by a fragment. They are not the ones you passed in, but the ones that were rasterized.
E.g. If you draw a quad that covers a 2 pixel region, with 1 texture coordinate from 0 to 1.
Here is a diagram of the pixels that get covered along with the interpolated coordinates:
0 0.25 .5 0.75 1 _________________ | | | | P0 | P1 | _________________
The texture coordinates that the fragments will use are indeed 0.25 and 0.75 (aka the rasterizer interpolates texture coordinates in the middle of the pixel), even though you passed in 0 and 1.