PVRTC4s from PC tools on iOS?

PowerVR Insider
1

Hi - I am in the process of adding compressed texture support to our iOS

engine (iPhone/Touch, GLES 2.0). Our data pipeline is PC-based, so we

are using the Windows version of PVRTexTool.exe (command line) to create

compressed image data from standard 32-bit TGA files.  (We strip off the 52-byte header and grab the image data bytes).





I am seeing unexpected distortion when we render the textures, and I am

wondering if there is some kind of incompatibility between PVRTC4

textures created via the PC tools versus the Apple iOS SDK

"texturetool"?





As a test, I tried using texturetool’s raw output instead of our PC-generated PVRTC4 data and it renders perfectly.





I noticed the distortion pattern seems similar to the "twiddling"

described in the PVRTexTool documentation, but it seems that there’s no

way to turn the option off via PVRTexTool (according to another forum

post). Or is this something I need to do manually in our data builder?





This image shows the difference between source and render (ignore the green background):



Thanks!

justin

2

PVRTexTool outputs .pvr files which have a descriptive header before the actual texture data. This is descrbed in the PVRTexTool documentation. Apple’s tool will output these as well as raw pvr data which, unfortunately, they also put in a .pvr file - are you interpreting this header correctly?

If this doesn’t explain the problem then please send these two examples to devtech@imgtec.com so that we can investigate the issue here.

3

Hi Gordon - thanks for the reply! 

I believe I’ve done everything according to the documentation. Let me show you what we do with the PVRTexTool’s   .pvr files created via the PC command line tool.

This snippet of code is from our PC build tool:

FILE* pvrFile = fopen(pvrFilename, “rb”);
       
if (pvrFile)
{
    unsigned int pvrImageDataSize = 0;

    fseek(pvrFile, 20, SEEK_SET);  //Skip to data size variable
    fread(&pvrImageDataSize, 1, sizeof(unsigned int), pvrFile);
    fseek(pvrFile, 28, SEEK_SET);   //Skip to image data (52 bytes from file start)

    imageData= (BYTE*)malloc(pvrImageDataSize);    // Memory to hold PVRTC4 image data
    int bytesRead = fread(imageData, 1, pvrImageDataSize, pvrFile);

    // …
}


That chunk of image data (unmodified) eventually gets loaded by our iOS game code, and put into the GPU memory like this:

if ( type == GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG )
{
   glCompressedTexImage2D(GL_TEXTURE_2D, 0,  type, width, height, 0, texSize, texData);
}

I will also send you the TGAs and PVR files for the test cases I’ve been messing with.

Thanks!
justin

4

Hi - I wanted to follow up since I figured out the problem with the PVR header-reading code. The distorted image was caused by a file reading misalignment:

The line
fseek(pvrFile, 28, SEEK_SET);
should instead read
fseek(pvrFile, 28, SEEK_CUR);

Amazing that the image was so visually coherent, considering the mistake! :slight_smile:

5

I suspected as much, but I was still adding a feature to on eof our tools which would have made this analysis much easier and got a little bogged down in an implementation problem…

I’m glad you worked it out Smile