Rockthesmurf
Advanced Member
Hi there,
For some reason attempting to use PVR textures seems to give me a segmentation fault on the Pandora. Up till now I have just been disabling my compressed texture path, but I thought it is about time I investigated further. I am querying what texture extensions are available, and the Pandora appears to be reporting that ETC1 and PVR textures are supported. The first texture that happens to come in is PVR compressed, so it goes through my PVR texture loading path. The exact same code is used on the IPhone, and it works correctly there.
Essentially, what I end up doing is reading in the PVR header, and the compressed data block. In this case the texture is 256x256 and is compressed using PVR4A (4 bpp with alpha on/off support). The raw data size is 32,768 (256width * 256height * 4bpp / 8bytesPerPixel). I have confirmed this is what the Pandora is reading in by printing it to the console. Once the data has been read in, I attempt to create the texture using:
Of course normally width/height/internal format/image size are controlled by variables, but for this I have expanded them to actual values so it is clear what is being passed in.
Upon calling the function, I get a segmentation fault.
Has anyone else used PVR compressed textures? Was there any trick to it? As I say, I used the exact same code on IPhone and it works correctly there. The compressed texture path supports ETC1, ATC and PVR textures, the ETC1 and ATC texture paths get used on Android, and again, they work correctly there. So this issue feels specific to Pandora, although I'm not sure why/how. Perhaps Pandora only supports some of the PVR formats?
Look forward to your help,
Steve
For some reason attempting to use PVR textures seems to give me a segmentation fault on the Pandora. Up till now I have just been disabling my compressed texture path, but I thought it is about time I investigated further. I am querying what texture extensions are available, and the Pandora appears to be reporting that ETC1 and PVR textures are supported. The first texture that happens to come in is PVR compressed, so it goes through my PVR texture loading path. The exact same code is used on the IPhone, and it works correctly there.
Essentially, what I end up doing is reading in the PVR header, and the compressed data block. In this case the texture is 256x256 and is compressed using PVR4A (4 bpp with alpha on/off support). The raw data size is 32,768 (256width * 256height * 4bpp / 8bytesPerPixel). I have confirmed this is what the Pandora is reading in by printing it to the console. Once the data has been read in, I attempt to create the texture using:
Code:
glCompressedTexImage2D(
GL_TEXTURE_2D, // target
0, // level
0x8C02, // internal format
256, // width
256, // height
0, // border
32768, // imageSize
data // pixel data, essentially a pointer to the uncompressed data block I read in
);Of course normally width/height/internal format/image size are controlled by variables, but for this I have expanded them to actual values so it is clear what is being passed in.
Upon calling the function, I get a segmentation fault.
Has anyone else used PVR compressed textures? Was there any trick to it? As I say, I used the exact same code on IPhone and it works correctly there. The compressed texture path supports ETC1, ATC and PVR textures, the ETC1 and ATC texture paths get used on Android, and again, they work correctly there. So this issue feels specific to Pandora, although I'm not sure why/how. Perhaps Pandora only supports some of the PVR formats?
Look forward to your help,
Steve
