Aligning Textures on POW2 boundaries?
Author
I'm wondering how important it is to still align my textures on POW2 boundaries(2, 4, 8, 16, 32, 64, etc.)?
I'm working on a 2D game, and several of my textures are smaller than POW2 boundaries. Aligning them on non POW2 boundaries is more efficient in calculations for coldet and drawing.
How many cards still require POW2 boundaries?
Toolmaker
By boundaries, do you mean size. Power of 2 sizes ins't a requirement for most cards, but you need to check the caps.
But, non power of 2 sizes are usually less efficient to use.
There's no real reason not to use powers of 2. You are packing many textures together, aren't you?
But, non power of 2 sizes are usually less efficient to use.
There's no real reason not to use powers of 2. You are packing many textures together, aren't you?
the power of two thing is present on most cards i'd assume. Better to just stay safe. Like I know that the geforce 4 has this limitation. And it's just two generations behind the current gfx card generation. Most people dont even have that.
GeForce3 need pow2 (but supports nonpow2conditional... ie: if you draw without scaling, and never wrap, it'll use a non-pow texture. Good for titlescreens, HUDS, and sprites). GeForce4 seems to be only very slightly changed from the GeForce3, so yeah, I imagine GeForce4 needs pow2 textures.
If you ask D3D to load your textures and they aren't pow2 sizes, it will automatically round up the texture sizes. You can ask it to scale or not scale the actual image. If you scale the image, it will be blurry. If you don' scale the image, you'll need to scale your UVs, and ensure they don't wrap (the unused image space will likely look ugly!)
Just use pow2.
If you ask D3D to load your textures and they aren't pow2 sizes, it will automatically round up the texture sizes. You can ask it to scale or not scale the actual image. If you scale the image, it will be blurry. If you don' scale the image, you'll need to scale your UVs, and ensure they don't wrap (the unused image space will likely look ugly!)
Just use pow2.
1) Many cards/drivers do still have a requirement that textures are created with power-of-2 dimensions. The Radeon 9800 in this machine does for example.
2) You can determine whether the card requires power-of-2 dimensions at runtime by checking for the D3DPTEXTURECAPS_POW2 cap. Some chips will allow textures which aren't power-of-2, but will impose some restrictions on their usage, these will report the D3DPTEXTURECAPS_NONPOW2CONDITIONAL cap (see the docs for that cap for a list of restrictions).
3) Some older chips had two restrictions, the textures had to have power-of-2 dimensions AND they had to be exactly square. Additionally, the 3Dfx chips used to have an upper size limit of 256x256 for textures.
It's those old days many people think about when they talk about the restrictions; nowadays all but the power-of-2 restriction has been lifted on most chips (dimensions still have an upper limit, but it's much higher now).
So a 256x64 texture is fine on most chips now.
4) You can't mip-map properly with textures which aren't power-of-2 because a width of say 33 can't be divided by 2 without giving a fractional result. If you're "minifying" textures at all on the polygons you're drawing, then you should use mip-mapping for performance reasons (texel cache).
5) Power-of-2 textures simplify jobs like allocation/organisation of video memory for the driver, as well as making it easier to ensure the internal representation is on an even boundary etc.
6) If you load a texture which isn't a power-of-2 size into a device which requires it, then the results are undefined. Sometimes the texture will be stretched to the the next highest or lowest power of 2, sometimes it will be truncated, other times less expected results will occur.
7) Something in Toolmaker's original post worried me: "calculations for coldet" - you're not seriously considering accessing pixels of textures being used for rendering to determine collisions are you? Please don't - that's a very easy way to stall the whole pipeline and get really bad performance.
Consider anything that the GPU uses (such as textures) to be WRITE ONLY from the CPU's point of view if you want anywhere near good perfomance.
If you do need pixel perfect collisions, I'd store a "collision map" and/or collision versions of your tiles/sprites in system memory, completely separate to the rendered textures. You can also hang collision and gameplay specific data off these maps a lot easier than you can with textures.
2) You can determine whether the card requires power-of-2 dimensions at runtime by checking for the D3DPTEXTURECAPS_POW2 cap. Some chips will allow textures which aren't power-of-2, but will impose some restrictions on their usage, these will report the D3DPTEXTURECAPS_NONPOW2CONDITIONAL cap (see the docs for that cap for a list of restrictions).
3) Some older chips had two restrictions, the textures had to have power-of-2 dimensions AND they had to be exactly square. Additionally, the 3Dfx chips used to have an upper size limit of 256x256 for textures.
It's those old days many people think about when they talk about the restrictions; nowadays all but the power-of-2 restriction has been lifted on most chips (dimensions still have an upper limit, but it's much higher now).
So a 256x64 texture is fine on most chips now.
4) You can't mip-map properly with textures which aren't power-of-2 because a width of say 33 can't be divided by 2 without giving a fractional result. If you're "minifying" textures at all on the polygons you're drawing, then you should use mip-mapping for performance reasons (texel cache).
5) Power-of-2 textures simplify jobs like allocation/organisation of video memory for the driver, as well as making it easier to ensure the internal representation is on an even boundary etc.
6) If you load a texture which isn't a power-of-2 size into a device which requires it, then the results are undefined. Sometimes the texture will be stretched to the the next highest or lowest power of 2, sometimes it will be truncated, other times less expected results will occur.
7) Something in Toolmaker's original post worried me: "calculations for coldet" - you're not seriously considering accessing pixels of textures being used for rendering to determine collisions are you? Please don't - that's a very easy way to stall the whole pipeline and get really bad performance.
Consider anything that the GPU uses (such as textures) to be WRITE ONLY from the CPU's point of view if you want anywhere near good perfomance.
If you do need pixel perfect collisions, I'd store a "collision map" and/or collision versions of your tiles/sprites in system memory, completely separate to the rendered textures. You can also hang collision and gameplay specific data off these maps a lot easier than you can with textures.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
