PVRTC4s from PC tools on iOS?

This topic contains 4 replies, has 2 voices, and was last updated by  Gordon 7 years ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #30294

    Ninjah
    Member

    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

    #34351

    Gordon
    Moderator

    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.

    #34352

    Ninjah
    Member

    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

    #34353

    Ninjah
    Member

    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! 🙂

    #34354

    Gordon
    Moderator

    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

Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic.