View Full Version : Weird NPOT behaviour

12-05-2005, 11:55 PM
Hello, I'm having an strange problem with a npot texture. The texture is a 66x241 (24bpp) texture (no matter if is bmp, jpg or any other format, the texture loading process is ok, I checked that). If I try to draw a fullwindowed quad with this texture, I get this (http://www.typhoonlabs.com/~ffelagund/bad.jpg)
aspect, but if I enlarge the texture to make it POT (I mean, filling the texture with black color in the parts that I merged with the original texture) I get this other aspect (http://www.typhoonlabs.com/~ffelagund/semigood.jpg) , wich is right (for this process I need to change all texture coords of the objects where I apply this texture, and is a waste of memory, so I preffer the GL_NPOT solution)
I really dont know what is happening, all other npot textures are right, and I checked this issue with geforce and 3dlabs cards, and with all of them I get the same result.

To summarize:
- I only have this problem with this texture (and another one) in a set of 100-120 textures.
- The result is the same in any card I've tested.
- The loading process is OK, because if I enlarge the texture to be POT, it is well displayed.

Perhaps am I using incorrectly the NPOT extension?
Here is the replo application if anyone want's try: test.rar (http://www.typhoonlabs.com/~ffelagund/test.rar)

12-06-2005, 02:11 AM
Looks like a glPixelStore problem. Read up on GL_UNPACK_ALIGNMENT.

12-07-2005, 02:04 AM
That was just that! glPixelStorei(GL_UNPACK_ALIGNMENT, 1); solved the problem. I must study more deeply this to know WHY this happened with this texture and not with the others. Thanks :)

12-07-2005, 02:26 AM
The inital value for unpack alignment is 4. Your bitmap has 3 bytes per pixel, 66 pixels per row, yielding 198 bytes per row, which is not a multiple of 4. Hence the problem.

The default alignment of 4 is almost never a problem for POT textures, because every possible width above or equal 4 is also a multiple of 4. So no matter what the pixel format, a row always occupies a multiple of 4 bytes.

12-07-2005, 04:46 AM
Thanks for explanation. I am re-reading the redbook's pixelstore chapter. An am not very familiar with this part of the GL pipeline (that's the reason why I didn't though in the pixel unpack way)
A question that comes to my mind... setting the alignemnt to 1 could have performance problems? I mean: it is safe set it to 1 for the whole application execution, or it is better adjusting it according to every textures' size?

Mikkel Gjoel
12-07-2005, 06:58 AM
Have you considered using texture_rectangles instead? I have seen much better performance with this extension compared to npot-textures.

12-07-2005, 11:35 AM
Well, NPOT textures works very well with my current hardware (Realizm cards), so I didn't needed rectangle textures, but in our current project we must give support to the widest range of cards as possible, so It looks like I have to perform some performance measures with rectangle textures. Thanks for the tip :)

12-07-2005, 01:04 PM
on nvidia NPOT opengl 2.0 is supposed to be as fast as texture rectangle ? (with Geforce 6 at least )