Hello,
I tried to implement PVR textures to the cocos2d-x. It works on iphone (both simulator and actual device) and on windows (using pvrframe).
To use it, just copy files in attachment to correct location. Use POWERVR_SUPPORT as preprocessor define
And edit these files
CCTexture2D.cpp:509
if( !(CCPlatformConfiguration::sharedConfiguration()->isSupportsPVRTC()) )
replace to
if( !(CCConfiguration::sharedConfiguration()->isSupportsPVRTC()) )
CCTexture2D.cpp:544
if (! CCPlatformConfiguration::sharedConfiguration()->isSupportsPVRTC())
replace to
if (! CCConfiguration::sharedConfiguration()->isSupportsPVRTC())
I found a display issue in the PVR code, but not the bug yet (I’m searching).
Using the attached pvr file, and loading the sprite “asteroid.png”, then displaying it in the center of the screen, you can see glitch on the last vertical line of the sprite.
Using the exact same pvr file on a cocos-iphone sample, is working properly.
So there is a bug somewhere that I’m trying to find.
I’m still trying to figure out where is the issue, if it’s in the texture creation, the pvr reader, or the rendering.
I’ve created a raw file from the data passed to glTexture2D (attached file), but I don’t have any library to write something more useful (if someone know a way to easily write a png or bmp, please tell me :D).
The raw file is simply the pixels (16bits/pixel) written to a file, I don’t know if a software is able to read that.
I am not guy from cocos2d-x team only independent developer and author of pvr texture loader (port only). So wait for their reaction. But it seems like you actually loading “different” data - means that your plist actually points to this “vertiacal” line - which is really presented in texture as part of blue rounded rectangle with yellow flash sign.
The simpliest way how to prove that pvr loader is ok is to convert source pvr texture into png or jpeg. Than load that texture again. I think that you will probably see the same artefact.
Try to measure size of sprite’s bounding box in image and then compare it with plist definition. When everything will fit but artifacts will remain, check that you are not using this “artifact fix” feature (configuration.h) which is actually taking one pixel bigger source rectangle on each side.
I already (yesterday) checked that the texture box in plist is fine (it stops a couple pixels before the next sprite in the sheet). The resources are the same used in the cocos-iphone version, and with the same code it’s working ok in objective-C. The pvr->png convertion is what I’m currently trying to do, but I don’t have an easy to use png lib (I’m trying with pngwriter right now, but it’s not easy).
CC_FIX_ARTIFACTS_BY_STRECHING_TEXEL is not set in my ccConfig.h file.
I debugged the code in parallel with the cocos-iphone version to check values, they are the same (when loading plist rect, and when creating the text coords).
One other thing I forgot, if I move (with CCActions) the sprite, it glitters (it’s not always a green/blue line).
Do you have a way to load my RAW file to check if you can see the artifact, because I don’t know how read it, nor convert it.
But it looks like you are right, it seems to be the pixels from the next sprite in the sheet.
In my screenshot the artifact is exactly placed where the next sprite should be.
I didn’t noticed before because when running the game tutorial, there is a flicker, and not for all the asteroids.
Anyway, the pvr code (and the ccz code I made a patch for) is not the problem
But still, remains the bug that does not happen on the objective-C version. I’ll take a look at my cocos2d-iphone version, maybe the FIX_ARTIFACT is active (when active, it uses 99 of the texture instead of 100, which might explain why I don’t see the pixel).
And, if I take a look at the image, the line appears only if the box of the sprite is 128x128, but the plist parameter clearly specify a rect of 127x127, and I checked by debugging that the text coords are correct (and the same on iphoneOS)… I don’t understand where is the problem, I’ll wait for the official devs to take a look or answer.
Thanks anyway,
Chris
By looking at the spritesheet loading code in cocos, the “frame” and “sourceColorRect” keys are a rect (x,y,w,h).
The “frame” defined in the plist is x=0, y=0, w=127,h=127. So the last pixel included in the asteroid should be 126 (starting from 0), which leave 1 pixel free between the 2 sprites. But it looks like the asteroid is rendered using 2 more pixels.
I’ll check again the text coord tomorrow, now it’s time for bed
The behaviour of premultiplied alpha PVR textures has been dramatically changed:
In cocos2d-iphone, it’s OFF by default, and you have to tell yourself (before loading your texture) if you want it enabled or not. This choice applies to all subsequent load, until you change it again.
In cocosx, it’s ON by default, and you have to enable/disable it for every texture you load.
This is a change of semantic, and can cause errors when porting code from objC to c++.
I suggest the following patch to fix that (and return to the same semantic): CAUTION: it breaks compatibility with previous cocosx version for PVR textures, BUT it returns to cocos2d-iphone compatibility! (but since pvr texture support was not pushed to current stable release, it might not affect too many people)
I get the following message by loading the PVR file.
>
“Unsupported PVR Pixel Format: 0x19. Re-encode it with a OpenGL pixel format variant”
>
Which OpenGL Pixel format exactly is meant? What should I specify in PVRTextTool?
Please read this http://stackoverflow.com/questions/9695077/pvrtextool-cl-not-generating-standard-header
Or add -legacypvr options to PVRTexToolCL
