How are textures dealt with internally?
BlitzMax Forums/BlitzMax Programming/How are textures dealt with internally?
| ||
| Apparently Max adjusts texture sizes to the nearest power of 2 texture - like 128 X 128. How does that effect LoadAnimImage with say two images within one 128 X 128 graphic? Are they treated as 64 X 128? Or is each image also sized-up - 128 X 128 X 2? Because generally it's common practice to use a large graphic with multiple frames of animation and odd sized textues can be slower - or when they're sized-up as mentioned. Basically I'm looking to optimize, and knowing how Max handles texture mapped quads (which is what they are internally I guess) would help. |
| ||
| On most hardware and under OpenGL1.2 without extra extensions, the textures in video memory have to be in powers of 2, starting at 64x64. It won't allow you to create a 64x128 texture, for example. Rectangular texture support was added later. So if you load up an image as a 8x8 image it will sit on its own 64x64 texture, wasting lots of space. I don't know whether LoadAnimImage lets you grab stuff at non-power-of-two sizes, but if it does, it would grab them into power-of-two textures. So yes probably it would waste videoram. If you are willing to learn OpenGL yourself you could store your full image containing all the anim frames as a single texture and then set up your own quads with texture mapping, adjusting the texture coordinates for each so that it shows only the frame you want. |
| ||
| Are they treated as 64 X 128? Yes, and that's completely legitimate as it's not an odd texture size (64 and 128 are both powers of 2). |
| ||
| you could store your full image containing all the anim frames as a single texture and then set up your own quads with texture mapping But that then runs into the other problem of using large textures which some cards deal with poorly - we can't win can we? ;-) Someone posted that the Geforce2 slows down significantly using textures over 256 X 256 - any thoughts on optimum texture size? |
   |