Simple texture question

It's unlikely that they need to be square, but it depends on your graphics chip. I think it's been a few years since any have required it.

You can read more about texture size limitations (and see the code to check)
here

Ok, but I've never really understood a couple things. Say my card supports power of 2 textures, but yours doesn't. Does that mean that you can't run my app or do I just write code to load and pad the texture?

Thanks!

If you pad the texture, then you'd have to change all the texture coordinates for each mesh too.

There's really only two kinds out there: Those cards that *require* power of 2, and those that don't.

If they require power of 2 sized textures, you just round up the width and/or height to the next power of 2 and then you resize/resample the texture manually into a new memory buffer before uploading it.

IF they don't require power of 2, you just let it be as it is.

There is also NONPOW2CONDITIONAL which says you can use non-pow2 textures if you don't scale them, etc. The full list of conditions is listed in the SDK. For HUDs and title screens this may be useful. On some cards that don't require POW2, it's still a huge performance boost to use POW2.

Considering how many cards still in active use require POW2 for standard texturing (ie: not meeting the requirements for NONPOW2CONDITIONAL), and considering how many cards still benefit from POW2 even if they don't require it, I'd suggest you stick with POW2 texture sizes. Square hasn't been an issue for a long time, like since DX7 era cards... Or atleast for common cards. It's possible some onboard Intel chips, or odd chips like DeltaChrome, and Parhelia have issues with non square textures.

Pow2, but non-square should be fine, but you'd best check the caps of any target hardware.

Yeah, I planned on sticking with power of 2 textures, I just didn't like the idea of a 3mb bitcrap because it had to be 1024x1024, when it could be shrunk to 1024x512. I converted it to a png anyway and now its <100kb. Thanks guys, I'll look into this stuff.

The file may be < 100K, but that means little. A PNG file is compressed on disk, but it's decompressed on load, and is uncompressed in video memory. A BMP, TGA, PNG, JPG, etc, all take the same video memory. The only way to reduce video memory usage is to load the texture into a smaller format, like D3DFMT_R5G6B5 16-bit, or using one of the a DXT compressed formats.

Quote:

Original post by Programmer16 Yeah, I planned on sticking with power of 2 textures, I just didn't like the idea of a 3mb bitcrap because it had to be 1024x1024, when it could be shrunk to 1024x512. I converted it to a png anyway and now its <100kb. Thanks guys, I'll look into this stuff.

That should be fine. I don't know of any cards that don't allow a 2:1 ratio.

edit: It appears I was wrong...

[Edited by - Daniel Miller on July 13, 2005 12:01:45 PM]

Be really careful with NONPOW2CONDITIONAL and POW2 caps. What POW2 means is that the card can only do POW2 textures. This is on for most cards.

NONPOW2CONDITIONAL means, assuming POW2 is on, the card can actually do non-pow2 textures, but not with all features. Again, most cards turn this on.

Cards like the GeForce6 series, support non-pow2 textures totally generally, including mip-mapping, so they turn OFF both caps, which confuses some programs, but is the right setting.

That said, you almost never want non-pow2 mip-maps.

Also be careful when using D3DX to load your textures with the number of mip-levels set to D3DX_DEFAULT - it will create mip-maps on a gf6 card for a non-pow2 texture which won't be correct, and on a non-gf6, it will rescale it to the nearest pow-2 and then create mip-maps.

The ProSavage DDR requires square textures as well, but it lies and says it doesn't. That caused us a lot of problems.

Quote:

Original post by Namethatnobodyelsetook The file may be < 100K, but that means little. A PNG file is compressed on disk, but it's decompressed on load, and is uncompressed in video memory. A BMP, TGA, PNG, JPG, etc, all take the same video memory. The only way to reduce video memory usage is to load the texture into a smaller format, like D3DFMT_R5G6B5 16-bit, or using one of the a DXT compressed formats.

I know that, but I'd rather distribute a smaller file (I'm not even loading 64mb of textures at the moment, so a large texture in memory doesn't really bother me right now.)