Why did we move to a new PVR file format (v3)?
From SDK version 2.10 onwards, we’ve supported a new texture file format - PVR version 3. Whilst the old version 2 format is still supported as legacy, we are moving toward full reliance on the new version as it has many new features that the old texture format is unable to support. Additionally, any new texture formats added to the SDK’s tools will only be supported in the PVR v3 container.
We moved to a new version with several compatibility breaks to address a number of issues that would cause problems going forwards:
1. Unintended Redundancy
The original PVR file had both pixel formats and bit masks, either of which could have been used to specify the pixel format. However, the bit masks were not really supported and trying to identify a format with these was fairly difficult. PVR3 Addresses the issue by having a flexible system while avoiding bit masks. As well as this, the bits masks were used to differentiate between PVRTC RGB and RGBA textures, when there was also an alpha flag which did the same job.
2. 3D, Cube Map and Array Support
The version 2 PVR file had one “numSurfs” variable which had different meanings based on flags. It could either represent an array, a 3D texture or a cube map. Whilst no API currently allows a mix of these anyway, the possibility is there, so each now gets its own value to future proof it.
3. Meta Data
Any information supplementary to the texture file would have to be stored separately when using an older PVR file. A clear need for this data exists in our new Print3D, when fonts are rendered to textures. Various data is needed alongside the image, such as texture atlas information to locate each individual character within the texture, or kerning data to properly align them. Without meta data this would have been fairly ugly to implement. This also allows any information to be stored in the texture, however the user desires.
Overall we feel the new file format is cleaner, simpler to use, more flexible and future-proof.
