Why do images for textures on the iPhone need to have power-of-two dimensions?

Question

I\'m trying to solve this flickering problem on the iphone (open gl es game). I have a few images that don\'t have pow-of-2 dimensions. I\'m going to replace them with images

Answer 1

I imagine it's a pretty decent optimization in the graphics hardware to assume power-of-2 textures. I bought a new laptop, with latest laptop graphics hardware, and if textures aren't power-of-2 in Maya, the rendering is all messed up.

Answer 2

The reason that most systems (even many modern graphics cards) demand power-of-2 textures is mipmapping.

What is mipmapping?

Smaller versions of the image will be created in order to make the thing look correctly at a very small size. The image is divided by 2 over and over to make new images.

So, imagine a 256x128 image. This would have smaller versions created of dimensions 128x64, 64x32, 32x16, 16x8, 8x4, 4x2, 2x1, and 1x1.

If this image was 256x192, it would work fine until you got down to a size of 4x3. The next smaller image would be 2x1.5 which is obviously not a valid size. Some graphics hardware can deal with this, but many types cannot.

Some hardware also requires a square image but this isn't very common anymore.

Why do you need mipmapping?

Imagine that you have a picture that is VERY far away, so far away as to be only the size of 4 pixels. Now, when each pixel is drawn, a position on the image will be selected as the color for that pixel. So you end up with 4 pixels that may not be at all representative of the image as a whole.

Now, imagine that the picture is moving. Every time a new frame is drawn, a new pixel is selected. Because the image is SO far away, you are very likely to see very different colors for small changes in movement. This leads to very ugly flashing.

Lack of mipmapping causes problems for any size that is smaller than the texture size, but it is most pronounced when the image is drawn down to a very small number of pixels.

With mipmaps, the hardware will have access to 2x2 version of the texture, so each pixel on it will be the average color of that quadrant of the image. This eliminates the odd color flashing.

http://en.wikipedia.org/wiki/Mipmap

Edit to people who say this isn't true anymore: It's true that many modern GPUs can support non-power-of-two textures but it's also true that many cannot.

In fact, just last week I had a 1024x768 texture in an XNA app I was working on, and it caused a crash upon game load on a laptop that was only about a year old. It worked fine on most machines though. It's a safe bet that the iPhone's gpu is considerably more simple than a full PC gpu.

Answer 3

1. You can find OpenGL ES support info about Apple Ipod/Iphone devices here: Apple OpenES support
2. OpenGL ES 2.0 is defined as equal to OpenGL 2.0
3. The constraint about texture size's has been disappear only from version 2.0 So if you use OpenGL ES with version less then 2.0 - it is normal situation.

Answer 4

Typically, graphics hardware works natively with textures in power-of-2 dimensions. I'm not sure of the implementation/construction details that cause this to be the case, but it's generally how it is everywhere.

EDIT: With a little research, it turns out my knowledge is a little out of date -- a lot of modern graphics cards can handle arbitrary texture sizes now. I would imagine that with the space limitations of a phone's graphics processor though, they'd probably need to omit anything that would require extra silicon like that.

Answer 5

Try implementing wrapping texture-mapping in software and you will quickly discover why power-of-2 sized are desirable.

In short, you will find that if you can assume power-of-2 dimensions then a lot of integer multiplications and divisions turn into bit-shifts.

I would hazard a guess that the recent trend in relaxing this restriction is due to GPUs moving to floating-point maths.

Edit: The "because of mipmapping" answer is incorrect. Mipmapped, non-power-of-two textures are a common feature of modern GPUs.

Answer 6

Are you using PVRTC compression? That requires powers of 2 and square images.