A fast, easy to use, free, and community supported 2D game engine
Hi,
When using pvr texture (created from a 32bits png file in TexturePacker in RGBA8888 format), i found that i have a bad (sharper) anti aliasing render compared to the same sprite with a png RGBA8888 texture...
Look below:
I first think of a texturePacker problem, but when opening pvr file in PVRTextTool, antialising is fine...
I made a basic cocos2d project (from 99.5.rc1) and included the original / converted files:
The problem is on simulator and device.
Any idea ?
thanks
Just one thing: i forgot the link to the sample project: download zip
The funny thing is that in case of RGBA88888 (and BGRA8888) TexturePacker simply passes the data directly to the PVRTexLib without changing a single bit...
I'll try to build a tool to extract the PNG back from the .pvr / .pvr.ccz
Update:
I took your project and converted your original assets using PVRTexTool (needed to resize the texture to 512x512 this is why the pig is stretched)
So the problem seems to be located in the PVR format or cocos handling it and not TexturePacker.
@CJ: I hacked cocos to set
static BOOL PVRHaveAlphaPremultiplied_ = YES;
But this is not the solution for the problem:
Update: I checked the CCTexturePVR which seems to do exactly the same as in PNG case.
The only strange thing I found (which is not related to this problem) is that kPVRTextureFlagTypeA_8 is defined as 0x1B which is not specified in the PVRTexLib manual...
I am currently investigating on it.
I calculated MD5 sums before passing the texture buffers to GL - for the red squate both are identical - so there should be no difference - but there is.
The pig's texture differs... so either the PVRTexLib is messing with the data or the UIImage used for loading the data...
I found a solution you could perhaps live with: Use setAliasTexParameters on the PVR texure and everything is fine:
@riq:
But I still don't understand why both red rectangles render different when using PVR vs PNG even with 100% identical texture data. I also swapped the positions but the problem is stuck to the sprites - it's not position dependent.
The only difference I saw is that setting alias parameters is done before calling glTexImage2D in PNG and after it in PVR case.
I'm guessing it's still an issue with pre-multiplied alpha stuff...
changing the blend mode to various different settings, I could not remove the black border around the PVR texture... I had experienced the problem before with pngs, but never with PVRs...
I've tried both
{GL_ONE, GL_ONE_MINUS_SRC_ALPHA};
{GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA};but still can not remove the black outline artifacts...
Look at this one here:
2 of them are PVRs, the other 2 are PNGs (sharing same data because of same file name)
I compared the data buffers before passing them to glTexImage2D - they are identical - but the render result is different - even between the shared textures.
I'll focus on the pixel differences I found between the pig's PVR and PNG tomorrow.
But I think we have to accept that with anti aliasing on results may be different - even with identical textures - so spending more time on the red squares is a loss of time.
fg1921
Member
By the way - I saw black outlines round some of the PVRs I created yesterday with TexturePacker. I then read some post on this forum about setting a '4 pixel' border round frames. Did that and that resolved all issues for me. I no longer see black outlines or other artifacts with a 4 pixel border round each frame.
I found the problem!!!
The problem is cocos2d's different handling of PVRs and PNGs during loading.
PNGs are copied to an intermediate buffer to enhance the textures to POT and to access pixel data. While this is happening cocos is premultiplying alpha and the settings for premultiplied alpha are added to the texture.
PVRs don't use premultiplied alpha out of the box (except you tell the tools to create them with it) and its deactivated in cocos.
This is why the anti aliasing for the textures is on rampage.
I created premultiplied PVRs with TexturePacker - but this makes things worse in the beginning because now every sprite gets a black border unless you don't patch cocos and set static BOOL PVRHaveAlphaPremultiplied_ = YES;
If you do both - my PVRs and set the flag everything works exactly like using PNGs. But this makes the PVR loader incompatible with PVRs created using PVRTexTool unless you use -premultalpha while creating them...
The other problem is that there is no way to detect if premultiplied alpha is turned on or not - there is no flag in the PVR format. In one of the screenshot above you can see what happens if you set the flag to ON without using premultiplied textures (its the nice image with the white border around the pig)...
So we have several choices:
1) Leave textrues as they are, set PVRHaveAlphaPremultiplied_ = YES and apply premultiplication during loading.
Pro: "old" textures will work too
Contra: Additional overhead and loading time which can be reduced. Image quality will suffer for 16 bit textures since the quantization error for applying the pre multiplication is much bigger than when applying it before color reduction.
Textures with alpha already premultiplied will get "overmultiplied"...
2) Create all textures with premultiplied alpha and set PVRHaveAlphaPremultiplied_ = YES
Pro: Fast since we don't need to modify the values after loading them.
Contra: Textures without premultiplied alpha will need rebuilding.
3) Find a way to tell the PVR loader that premultiplied textures are used. E.g. by setting a default value like with the pixel format.
I would suggest to go for variant 3
@CJ: I think we should shift this thread to cocos2d development until we agree about a solution.
Yes, all images loaded with UIImage will be alpha-premultiplied at loading time.
And cocos2d is optimized to render alpha-premultiplied images, since the default blending mode is for premultiplied images.
As you mentioned, it is possible to premultiplied the images using PVRTexTool.
I strongly suggest to create alpha-premultiplied PVR images because:
-> premultiplied images has the benefits (discussed in another thread, but I can't find it)
-> It will render a bit faster
I suggest adding alpha-premultiplied for PVR images in TexturePacker. Ideally it should be the default behavior for PVR images. There is no need to alpha-premultiplied other images like PNG, BMP, etc, since they will be premultiplied at loading time.
The user should call this method before loading them:
[CCTexture2D PVRImagesHavePremultipliedAlpha:YES];Oh - I totally missed that function ;-)
So for all TexturePacker users: I'll try to make a fixed intermediate version available over automated updates today - (starting with TP 2.0.2 you can turn automated updates including beta versions on in the Preferences of the GUI).
Official release will be announced here http://www.cocos2d-iphone.org/forum/topic/11051 soon.
whats the command for texturetool to create pre-multiplied alpha pvr's?
I don't see any mention of that flag on apples dev page:
http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TextureTool/TextureTool.html
@jordo:
I think that Apple's texturetool doesn't support alpha-premultiplied.
But you could use PVRTextTool: http://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp
Not yet - sorry. I am in the release phase now but still got 2 minor problems to fix before the new release.
I hope I get it done today.
@Andreas : I have just tried your latest version.
But things are going worst : now, with AND without premultiplied alpha are bad...
Look:
For the premultiplied one, i use of course [CCTexture2D PVRImagesHavePremultipliedAlpha:YES];
I don't understand why the one without premultiplied alpha isn't as the original pvr from the start of this topic : have you made some change ?
Did you try it with the newest development version of cocos?
I used your example with upgraded cocos and it was fine.
For the one with no premultiplied alpha, it seems to be a bug in my project (i start a new project from my sample_png_vs_pvr.zip, update it with last develop branch, and then the pig is now like the original one of this topic).
But for the premultiplied alpha: i have always a black border...
I have published my updated sample here
Sorry. I found a bug :-(
If you work with the GUI and change settings the premultiplication may get applied several times. Fix is on the way.
I ran into this problem this week, but couldn't easily correct it since I was using Zwoptex for my PVR files rather than TexturePacker. Zwoptex currently exports PVR files without premultiplied alpha. I wrote a quick Mac program to convert the files. While I can't easily post the program, here's the core of it:
typedef struct PVR_TEXTURE_HEADER_TAG
{
unsigned int dwHeaderSize;
unsigned int dwHeight;
unsigned int dwWidth;
unsigned int dwMipMapCount;
unsigned int dwpfFlags;
unsigned int dwDataSize;
unsigned int dwBitCount;
unsigned int dwRBitMask;
unsigned int dwGBitMask;
unsigned int dwBBitMask;
unsigned int dwAlphaBitMask;
unsigned int dwPVR;
unsigned int dwNumSurfs;
} PVR_TEXTURE_HEADER;
- (void)openFile:(NSString *)strFileName
{
FILE *fpFileIn = fopen([strFileName UTF8String], "rb");
fseek(fpFileIn, 0, SEEK_END);
int nLength = ftell(fpFileIn);
if (nLength < 1)
{
return;
}
fseek(fpFileIn, 0, SEEK_SET);
int nHeader = sizeof(PVR_TEXTURE_HEADER);
NSString *strNewFile = [strFileName lastPathComponent];
FILE *fpFileOut = fopen([strNewFile UTF8String], "wb");
unsigned char *data = malloc(nHeader);
fread(data, nHeader, 1, fpFileIn);
fwrite(data, nHeader, 1, fpFileOut);
int nValue;
for (int i = nHeader; i < nLength; i += sizeof(int))
{
fread(&nValue, sizeof(int), 1, fpFileIn);
unsigned char A = (char)((nValue >> 24) & 0x000000ff);
unsigned char B = (char)((nValue >> 16) & 0x000000ff);
unsigned char G = (char)((nValue >> 8) & 0x000000ff);
unsigned char R = (char)(nValue & 0x000000ff);
R = (R * A) / 255;
G = (G * A) / 255;
B = (B * A) / 255;
nValue = (A << 24) | (B << 16) | (G << 8) | R;
fwrite(&nValue, sizeof(int), 1, fpFileOut);
}
fclose(fpFileIn);
fclose(fpFileOut);
}
Maybe this will be helpful to someone.
To fix some small black borders I had around some of my sprites I changed all my pvr images to premultiply-alpha. I also set [CCTexture2D PVRImagesHavePremultipliedAlpha:YES].
This works pretty well and the thin small borders are gone. But on one scene I get another problem. I have two batch nodes. Each one has a pvrtc4 texture. This was generated with TexturePacker and --premultiply-alpha. There is a thin white frame around the sprites.
This was not the case when I used pvrtc4 textures without --premultiply-alpha and without setting [CCTexture2D PVRImagesHavePremultipliedAlpha:YES];
You must log in to post.
