Quicky question:
I know PVR textures have to be square on the iPhone, but does this restriction apply to normal textures (GL_RGBA) as well?
Thanks for any info.

Nope, only applies to PVR.

The PVRTC tools on ImageTec's website allow you to compress non-square textures for what it's worth.

captainfreedom Wrote:Quicky question:
I know PVR textures have to be square on the iPhone, but does this restriction apply to normal textures (GL_RGBA) as well?
Thanks for any info.

Nope, but must be power of 2, and max 1024, min 8 (not sure about min, I remember I had problems with opengl aligment).

Skorche Wrote:The PVRTC tools on ImageTec's website allow you to compress non-square textures for what it's worth.

It doesn't really compress them , just wraps them into PVR format but internally non-square textures are simply stored as the uncompressed byte stream.

warmi Wrote:It doesn't really compress them , just wraps them into PVR format but internally non-square textures are simply stored as the uncompressed byte stream.

Sorry warmi - This isn't true. Look at the file sizes and take away the size of the PVR header.

PVRTC works on 4x4 (or 8x4 for 2bpp) blocks stored in Morton order (Wikipedia has a reasonable explanation of this). This allows for POT-dimensioned rectangles to be filled without ambiguity and that's what PVRTexTool does.

The minimum texture sizes are 8x8 for 4bpp and 16x8 for 2bpp.

However, on the iPhone there is a restriction to only allow square PVRTC textures (rectangular ones will be accepted on some SDKs/OSs, but officially they shouldn't be). I believe the maximum size on iPhone that is allowed is 1024x1024, but you may want to check on that. (Incidentally, the Windows version of PVRTexTool currently can only manage that big, but you can go larger on MacOS and Linux.)

Since the iPhone has appeared there's been a lot of confusion surrounding the formats - .PVR is a container, it can contain many different texture data formats. This is useful because it gives you access to other formats e.g. RGBA4444 textures which can still save you half the bandwidth of RGBA8888 even if PVRTC compression is giving you unacceptable artifacts, for instance.

PVRTC comes in two flavours (at the moment) 4bpp or 2bpp and is just one of the data formats that can be in a PVR.

If you're interested in this, look at the PVRTexTool documentation and the white paper by the guy who invented PVRTC, both of which you can get from the Imagination website.

flash Wrote:Sorry warmi - This isn't true. Look at the file sizes and take away the size of the PVR header.

PVRTC works on 4x4 (or 8x4 for 2bpp) blocks stored in Morton order (Wikipedia has a reasonable explanation of this). This allows for POT-dimensioned rectangles to be filled without ambiguity and that's what PVRTexTool does.

The minimum texture sizes are 8x8 for 4bpp and 16x8 for 2bpp.

However, on the iPhone there is a restriction to only allow square PVRTC textures (rectangular ones will be accepted on some SDKs/OSs, but officially they shouldn't be). I believe the maximum size on iPhone that is allowed is 1024x1024, but you may want to check on that. (Incidentally, the Windows version of PVRTexTool currently can only manage that big, but you can go larger on MacOS and Linux.)

Since the iPhone has appeared there's been a lot of confusion surrounding the formats - .PVR is a container, it can contain many different texture data formats. This is useful because it gives you access to other formats e.g. RGBA4444 textures which can still save you half the bandwidth of RGBA8888 even if PVRTC compression is giving you unacceptable artifacts, for instance.

PVRTC comes in two flavours (at the moment) 4bpp or 2bpp and is just one of the data formats that can be in a PVR.

If you're interested in this, look at the PVRTexTool documentation and the white paper by the guy who invented PVRTC, both of which you can get from the Imagination website.

I am perfectly aware of 2/4 bpp compression .... I was talking about using uncompressed non-rectangular textures as PVRT files which is perfectly possible (since I am using them - I store all my textures as PVRT files -compressed or not).
I just don't want to deal with having different loaders for png, jpeg and other files ....
In other words , PVRT is just a container which can store any OpenGL compatible image (RGBA , I , IA etc ) in addition to 2/4 bit compressed files.

PS.
My original post was in response to Skorche post about being able to store non-square textures in PVRT format.

warmi Wrote:I am perfectly aware of 2/4 bpp compression .... I was talking about using uncompressed non-rectangular textures as PVRT files which is perfectly possible (since I am using them - I store all my textures as PVRT files -compressed or not).
I just don't want to deal with having different loaders for png, jpeg and other files ....
In other words , PVRT is just a container which can store any OpenGL compatible image (RGBA , I , IA etc ) in addition to 2/4 bit compressed files.

PS.
My original post was in response to Skorche post about being able to store non-square textures in PVRT format.

And my reply is trying to say that PVRTexTool can encode non-square PVRTC (i.e. compressed) textures. The only restriction is that both dimensions of the texture must be powers of two greater than 8 ( >16 horizontally for the 2bpp case).

The problem bit is when you want to use them on the iPhone as it only accepts square PVRTC texture data. On other POWERVR platforms rectangular PVRTC textures work fine (even with mipmaps).

flash Wrote:And my reply is trying to say that PVRTexTool can encode non-square PVRTC (i.e. compressed) textures. The only restriction is that both dimensions of the texture must be powers of two greater than 8 ( >16 horizontally for the 2bpp case).

The problem bit is when you want to use them on the iPhone as it only accepts square PVRTC texture data. On other POWERVR platforms rectangular PVRTC textures work fine (even with mipmaps).

From what I understand, it is not just the iPhone but any MBX based devices ...