Width!=Height textures in OpenGL

Started by
7 comments, last by Nik02 18 years, 4 months ago
Hi there! Is there any possibility of using textures with a size like 800x600 in OpenGL? I think playing around with tilesets or things like this will a bit tricky if I want to use a large graphics file as background image. Thanks!
Advertisement
Both image width and height have to be 2n + 2(border) for some integer n. Note that n can be different for width and height. So, to answer the question your topic asked--yes, but the example dimensions you gave won't work. Try fitting everything in into a 512 * 256 texture or maybe something similar.

/edit: you could always scale the image before giving it to OGL, though. A GLU function, gluBuild2DMipmaps does exactly that and creates your texture with mipmapping for you.
Thanks very much!
What deavik said is correct for plain OpenGL. But with ARB_texture_rectangle and ARB_texture_non_power_of_two you can use any size you want for your textures.
--
Quote:Original post by Enrico
But with ARB_texture_rectangle and ARB_texture_non_power_of_two you can use any size you want for your textures.


You can, but you don't want to, unless any of these extensions are simply rescaling the texture to a power of two. If it would be so easy to not have this limitation without "paying" for it, then it would have never existed in the first place.
f@dzhttp://festini.device-zero.de
Quote:Original post by Trienco
Quote:Original post by Enrico
But with ARB_texture_rectangle and ARB_texture_non_power_of_two you can use any size you want for your textures.


You can, but you don't want to, unless any of these extensions are simply rescaling the texture to a power of two. If it would be so easy to not have this limitation without "paying" for it, then it would have never existed in the first place.

Video cards that support NPOT or texRects support them on hardware, using them its not expensive at all. So yes, you can use them if you want.
In almost any case, it is more costly to use NPOT textures than POT ones. The hardware managing the texture memory has much easier time to allocate regularly-sized textures than arbitrary sized ones.

Add to this, some hardware pad the NPOT textures to powers of two internally, mainly to preserve predefined boundary values. This behavior depends on the texture packing algorithm used by the graphics driver.

Niko Suni

Quote:Original post by Nik02
In almost any case, it is more costly to use NPOT textures than POT ones. The hardware managing the texture memory has much easier time to allocate regularly-sized textures than arbitrary sized ones.

Add to this, some hardware pad the NPOT textures to powers of two internally, mainly to preserve predefined boundary values. This behavior depends on the texture packing algorithm used by the graphics driver.


But on the latest hardware this should have been taken into account, and I would hope it is no longer slower.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Regarding NPOT performance hits, there's much more in it than untrained eye can see. For example, MIP filtering: how would you (optimally and robustly) filter an arbitrarily-sized texture to the next smaller level, without sacrificing quality or speed, as opposed to a rectangular power-of-two texture? How would you optimally fill a texture atlas (a video memory block in this case) with NPOT textures while preserving as much free space as possible, as opposed to POT? [smile]

If you know answers to these questions, you'll realize that NPOT is always going to be at least a little slower than POT (although the difference can very well be unnoticeable in practice).

Niko Suni

This topic is closed to new replies.

Advertisement