ePVRTVarTypeUnsignedByteNorm did not make any difference but setting depth from 32 to 1 did somehow solve the problem. What value is depth supposed to have?
I diffed 2 files created with the “old” and the “new” version of the lib and got some changes in the header - the rest seems to be identical. The changes are that the mask bits (dwRBitMask etc) are all 0 instead of set to a useful value (e.g. 0xff000000 like it was before).
Ah sorry, didn’t actually notice the depth of 32 there… This value is for 3D textures, not pixel depth. It’s basically the number of z-slices in a texture. The old PVR2 format doesn’t support 3D textures so it’s unable to save to this type - 1 is thus the correct value in this case. The number of bits per pixel are instead taken care of in the PixelFormat in PVR3.
The “Norm” designation should also be necessary - if it’s not returning false without “Norm” then I need to look over the code, as this is not a valid combination for this function. If it’s not returning false then it will probably be giving you an invalid texture. If it is saving, could you try opening it in PVRTexTool to see what’s being output?
The bit masks were always rather unnecessary - the pixel formats have always been handled by the pfFlags in PVR2. The recommendation for reading PVR2 files is generally to just ignore these masks for this reason, which is the same reason that they won’t be set when using the legacy format save.
I am now tying to save data as RGB565. pixeltype = PixelType(‘r’,‘g’,‘b’,0 ,5,6,5,0);
The file writes and everything seems to be ok - result is true for conversion & writing data.
But now I get 0xffffffff in the dwpfFlags field. Which means that the complete file is invalid.
This is really frustrating. While the new API adds nice new features you removed some really important stuff like useful error messages. I currently have no chance to know what is going wrong.
And how am I supposed to print useful error messages if the API says that everything is ok?
The 565 issue is a known problem, I've fixed this in the next build and it should be available shortly. Equally I'll check the other two formats but the fix I've done should cover all of them. The fact that it's outputting any file at all is a bug which shouldn't have happened. I assume you're using UnsignedShortNorm for all of these?
PVRTEX_ALPHA was included before for PVRTC textures as that was its original purpose - to differentiate between RGB and RGBA - an OGLES1.x consideration. Maintaining it generally meant scanning the entire texture for any non-opaque blocks and setting the flag at various points - which was an unnecessary slowdown.
With PVR3 the idea is that the header stores only data that is necessary to load the format into any given API. Further data, such as whether any transparency is present should be stored into the meta data. The meta data was added mostly for cases like this, where a user wants to store data that the format doesn't specifically support. So if you wish to use similar functionality, create a MetaData type to store it in, and scan for alpha data. Alternatively if you only wish to know if a format supports alpha, checking for the "a" character with a switch statement to mop up compressed formats will also work. I can add in a "scan for alpha" function in the next release - I'm already planning on adding functions to tell you various facts about a texture so this should fit nicely.
The main reason I fell back to true/false returns instead of error messages was because often, functions only had one error message anyway - with too many of them being just "failed to do function". At some point I plan to expose a debugging interface that will produce a log of various events and any problems that might occur, but sadly there was no time to get it into this release.
Just realised that my advice about the MetaData is moot as you're still using PVR2 files. As with the bit masks, the PVRTEX_ALPHA is technically unnecessary and a bit of a pain to support properly. When using the specific alpha PVRTC formats the PVRTEX_ALPHA flag is set - which is the only time it actually becomes technically necessary.
Otherwise, the advice remains the same about the scanning for alpha data, you'll just need to check if your alpha byte is less than the maximum value. Assuming you're using RGBA8888 data, for similar functionality, just check every fourth byte to see if its value is less than 255. Unfortunately as this is legacy it will mean manually editing the file though.
If you're having too much trouble, it might be worth suggesting that you use the 2.9 library instead as this still has full support for PVR2 files, unless there is any specific functionality you need from the new library? If you'd like to pursue this instead then I can provide you with a drop of the 2.9 library if you email us at devtech@imgtec.com.
