sh*tty quality with pvrlegacy and oglpvrtc4?

PowerVR Insider
1

I found that the only way I can get Apple’s GLKTextureLoader to play nice with pvrtc4 files from PVRTexTool is by using -pvrlegacy and -oglpvrtc4. The resulting files compress worse (~500 bytes when gzipped vs ~400 bytes when gzipped for a 64x64 texture) and look much worse (lots of compression artifacts vs almost no compression artifacts) than pvrtc4 files made by Apple’s texturetool.

So my question is: Do either of those options cause PVRTexTool to use a very old/bad compression algorithm? Does GLKTextureLoader load them incorrectly? Is it more sensible of me to copy the texture loading code from cocos2d instead of using Apple’s GLKit? Obviously I’m rather new at this…

2

Hi Minthos,

The -pvrlegacy flag should only affect the file format, nothing to do with the actual texture data should be affected. However I’ll take a look at the issue and see if there does exist a bug in the encoding tool.

Out of interest, are you using the version of the tool direct from the utilities page or the version which is packaged with the SDK? If you’ve not got it direct from the utility page on our website I suggest you update to the latest version and see if that works for you:
https://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp

I’ll let you know if I find anything in the meantime.

Thanks,

Tobias



3

Hi Minthos,

I had a go with a couple of test images I have lying around, but I saw absolutely no difference in how the two versions of the file looked, and there’s nothing in the code that looks like it should be doing anything like that. I’ll await your response on which version you’re using.

If you are using the most up to date version, is there any chance you could send some images with this issue to DevTech@imgtec.com and I’ll see if I can reproduce the issue. In that case if you could also tell me the exact arguments you’ve used that would be helpful.

Thanks,

Tobias



4

I’m using the version from the download page you linked. When I run it without arguments it outputs this at the end:
          4.04

          SDK Build: 2.10@905358

I’ll mail you with more details.

5

Hi Minthos,

Unfortunately it seems your email was discarded by our spam filters. I’ve got our systems team to allow your emails through now, is there any chance you could re-send the email?

Thanks,

Tobias



6

Done.

7

Hi Minthos,

I've had a look at this and in this particular case it seems that Apple's texture tool actually does a better job. The reason for this is mostly just that small sprites tend to be the worst case scenario for PVRTC - as it tends to be a lot of detail in a small area. In this case it seems that PVRTC is capable of doing something with it, but both versions have distinct differences to the original, it just so happens that the artifacts in Apple's compressor seem to be a bit less intrusive.

There are some quality gains to be had by upscaling the image, if that is something you'd be able to do? There' s a lot of empty texture in that sprite which is why I've suggested it, though I assume it will be part of a larger texture atlas at some point?

I've forwarded this to our PVRTC compressor team, but for now I'm afraid I'll have to suggest you might be better off using Apple's texture tool for this texture.

Thanks,

Tobias



Tobias2012-07-02 16:07:57
8

Thank you, that is good news. The texture is just one I use for testing, the real ones will indeed be bigger. This means I should be able use your tool in good conscience, which is a great plus since your tool is cross-platform :slight_smile:

9

Ah good to hear, If you do run into any more problems though please let me know :slight_smile:

Thanks,

Tobias