Alright attached you'll find a patch for a current SVN version of ORX.
In the meanwhile I've rewritten the whole code for loading pvr textures.
I no longer use the PVRTexture class that was written in objective-c and part of an example by apple.
In this step I also included the whole loading code into orxDisplay.m of the iphone plugin.
Is there any other platform supporting PVR texutres? If so, it could easily be moved somewhere else. The only iphone specific code is the byte swapping, but I hope it shouldn't be to replace that.
the rest has been "orxified". meaning I have replace ios/objective-c API stuff with calls to the orx API. (e.g. using orxFile)
The code also performs a check whether the require opengl extension is present. if not it will fallback to a file named the same, but ending in "png".
it get's a bit trickey if you want to support multiple platforms with the same config files, while using PVR on the one and PNG on the others. In this case you need different config files. (Or the more hackish version: changing the loading code on one architecture to rename the incoming file name)
Beside the support for normal compressed architecutres I also added support for ARGB4444, ARGB1555 and some others. The reason for that is that the PVR compression is not very suitable for comic style textures, because of the artifacts it causes. However reducing the bit depth is quite a good method to save memory. Furthermore even if using ARGB8888 the loading time should be reduced, as the raw image data can be transfered to the video memory rather then first decoding/uncompressing a like, as it is in the case of PNGs.
I'll try to do the integration as soon as possible. I don't know if PVR is used on other platforms, but if you're looking for the OGL extension before using it, I might as well add it to the other plugins.
Lastly, I'm ok with doing on-the-fly file renaming to try loading different textures. That's what happens with plugins with the whole debug/release thing. That sounds like an easy way to support different formats on different platforms. Maybe the suffix could be changed in config to give flexibility to the user? But I'm not sure this is really needed.
I'm in the process of merging your code but the patch only contains changes for orxDiplay.m, no other files. As it looks like you're adding stuff to the orxView class, my guess is that I'm missing at least one file in the patch.
Last question: I've noticed you don't do any vertical flip nor alpha-demultiplication when loading a PVR texture, is that normal (ie. will it be consistent with regular textures)?
when "orxifying" the pvr loading code I incoporated everything in that one file, so that should be fine. (so a png and a pvr created with pvrtextool can be used interchangably)
I don't do any alpha demultiplication because it's never premultiplicated in the first place.
I don't do any y-flipping, because the PVRTexTool, that creates the pvr files, will by default store y-flipped images.
I mentioned something in the wiki. Also added some note to the PVRTexTool now.
although I'm anyway wondering if anybody finds this article in the wiki ^^
maybe we should include the (useful) arcitles of others somehow in the whole wiki structure.(most of mine are just notes to myself )
I don't know when I'll find some time for integrating the new version of orx. but I'll let you know if I encounter any bugs after integrating.
Comments
Anyway, it's not like orx had hundreds of users...
In the meanwhile I've rewritten the whole code for loading pvr textures.
I no longer use the PVRTexture class that was written in objective-c and part of an example by apple.
In this step I also included the whole loading code into orxDisplay.m of the iphone plugin.
Is there any other platform supporting PVR texutres? If so, it could easily be moved somewhere else. The only iphone specific code is the byte swapping, but I hope it shouldn't be to replace that.
the rest has been "orxified". meaning I have replace ios/objective-c API stuff with calls to the orx API. (e.g. using orxFile)
The code also performs a check whether the require opengl extension is present. if not it will fallback to a file named the same, but ending in "png".
it get's a bit trickey if you want to support multiple platforms with the same config files, while using PVR on the one and PNG on the others. In this case you need different config files. (Or the more hackish version: changing the loading code on one architecture to rename the incoming file name)
Beside the support for normal compressed architecutres I also added support for ARGB4444, ARGB1555 and some others. The reason for that is that the PVR compression is not very suitable for comic style textures, because of the artifacts it causes. However reducing the bit depth is quite a good method to save memory. Furthermore even if using ARGB8888 the loading time should be reduced, as the raw image data can be transfered to the video memory rather then first decoding/uncompressing a like, as it is in the case of PNGs.
so long,
Tobi https://forum.orx-project.org/uploads/legacy/fbfiles/files/orxDisplay.gz
I'll try to do the integration as soon as possible. I don't know if PVR is used on other platforms, but if you're looking for the OGL extension before using it, I might as well add it to the other plugins.
Lastly, I'm ok with doing on-the-fly file renaming to try loading different textures. That's what happens with plugins with the whole debug/release thing. That sounds like an easy way to support different formats on different platforms. Maybe the suffix could be changed in config to give flexibility to the user? But I'm not sure this is really needed.
I haven't tried the code myself, so if you find any mistake I made, please feel free to fix it directly on the svn.
when "orxifying" the pvr loading code I incoporated everything in that one file, so that should be fine. (so a png and a pvr created with pvrtextool can be used interchangably)
I don't do any alpha demultiplication because it's never premultiplicated in the first place.
I don't do any y-flipping, because the PVRTexTool, that creates the pvr files, will by default store y-flipped images.
Ah yep, going directly through OpenGL ES calls.
Good to know. Is there any other way to produce PVR images that wouldn't do the Y-flipping? If so, a note on the wiki might be helpful.
Let me know if I made some mistakes when integrating your code.
although I'm anyway wondering if anybody finds this article in the wiki ^^
maybe we should include the (useful) arcitles of others somehow in the whole wiki structure.(most of mine are just notes to myself
I don't know when I'll find some time for integrating the new version of orx. but I'll let you know if I encounter any bugs after integrating.