just a stupid thing, but texture coordinates are always from 0 to 1 from left to right, and from top to bottom, too
and its faster to shift than to multiply, and this, too for getting the info wich damn pixel you really need to access… how do you know wich x,y in getpixel(x,y) you have to give?
you have to scale your y to get the right pixel, and this you do normaly with a nice bitshift with the height (the y on a gpu is NOT a float anymore but a fixedpoint, so shifts are working then…)
Dunno why they should be power of 2, but I’m sure of one thing : we must all write to SGI, ask for this question and post the answer on the FAQ !
Every month we read the same question
Originally posted by LordKronos:
[b] Im not disputing your claim, since I havent used any non-nvidia cards for openGL, but which cards are you talking about? I wasnt aware that any allow this.
Possibilities: Perhaps those cards take a performance hit for allowing you to do so. Or maybe the driver resamples the image to a power of 2 when you upload.
[/b]
I don’t know to what extents different vendors support non power of 2 textures, but I know that all of ATi, nVidia and Matrox does have it in hardware in their latest offerings. I dont know much about what restriction there are.
I remembered for example that my old G400 accepted non power of 2 textures in OpenGL. It shouldn’t do that without an extension of some sort so I think the later driver versions removed that functionality. The Radeon support non power of 2 texture, but only in DX AFAIK. And as Matt said nVidia supports it in hw too.
just a stupid thing, but texture coordinates are always from 0 to 1 from left to right, and from top to bottom, too
No, that is only in the OpenGL API. It’s a good a design decision because the programmer does not need to keep track of the width and height of the texture he’s drawing with – he just uses 0…1 and OpenGL scales it to the appropriate coordinates. If a texture is 64x64 then the texture coordinates range from 0…63.
Also, if a texture was power-of-two sideways but not heightways, what would happen if you used your u/v mapping to rotate the texture?
It would work perfectly fine. No matter what the U and V coordinates are, you’d still ignore the height when reading the texture data from memory (except with perspective-correct mapping).
Anyway, textures are never really rotated; instead, the U and V coordinates of the vertices are altered to make the texture look rotated.