Possible bug in BitmapFontAtlas - color and opacity on device, simulator is fine

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Possible bug in BitmapFontAtlas - color and opacity on device, simulator is fine

(7 posts) (3 voices)

Started 2 years ago by Nalin
Latest reply from AkumaStreak

Tags:

BitmapFontAtlas

Nalin
Member

Hi,

I have encountered a problem with BitmapFontAtlas that only seems to show up on a device, it works fine with the simulator.

After creating a label and set it to be transparent, and say coloured yellow, I then run an action to fade it in. On the simulator it works perfectly, while on the device it initially appears to be opaque, but it comes out white, not yellow.

Here is some sample code which is present in a layer that should exhibit the problem. I managed to work around the opacity bug by fading out the label immediately

BitmapFontAtlas * label = [BitmapFontAtlas bitmapFontAtlasWithString:@"Hello" fntFile:@"wisten22.fnt"];
label.color = gcYELLOW;
label.position = pos;
[self addChild:label z:1];

label.opacity = 0;
id fadeaction = [Sequence actions:
[FadeOut actionWithDuration: 0], // fade out to fix opacity bug
[DelayTime actionWithDuration:d], // text appears in White not yellow here, but only on the device!
[FadeIn actionWithDuration: t],
nil];
[label runAction: fadeaction];

Has anyone else come across this?

Thanks,

Nalin

Posted 2 years ago #
AkumaStreak
Member

Did you ever figure out what was up with this? I am having identical problems. Thanks.

Posted 2 years ago #
AkumaStreak
Member

Are I realize now that this is the premultiplied alpha bullshit again (which has bit me at least once before). Time to go did/refresh myself on what's up with this, I guess.

Posted 2 years ago #
riq
Key Master

@akuma: if you use libpng (search for "libpng" on this forum) you won't have this kind of issues.

Texture2dTest.m shows how to load .png images using libpng

Posted 2 years ago #
AkumaStreak
Member
I might switch to libpng if performance is the same. I don't usually like delta-ing my stuff away from the standard cocos2d way of doing things though. :-(

I like to understand what I'm working with, and this opacity stuff is annoying mostly because I never came to terms with what's going on with these various issues.

I go in and try to understand it, and it's logic fails all over the place.

Ex.:
1) Everything on the phone (device) is premult. Fine.
2) This means that modifying opacity will modify RGB. Check.
3) Let's look at setOpacity:
```
-(void) setOpacity:(GLubyte)opacity
{
	// special opacity for premultiplied textures
	opacity_ = opacity;
	if( opacityModifyRGB_ )
		color_.r = color_.g = color_.b = opacity_;
}
```
How can red, green, and blue simply be set to the opacity value (such as 255) with working results, ever? I assume it is correct -- it's been like this for a long time. Can anyone explain how this works for me? Shouldn't the math take the existing color into account?
Posted 2 years ago #
riq
Key Master

There is a bug regarding this:
http://code.google.com/p/cocos2d-iphone/issues/detail?id=600

Also, the v0.8.0 release notes explains how it works internally:
http://www.cocos2d-iphone.org/wiki/doku.php/release_notes:0_8#premultiplied_images

Posted 2 years ago #
AkumaStreak
Member

Ok, I realized while standing around in the shower (ha) why my last statement was off. Thanks for the links Riq. I think I am in the realm of understanding this again (if only for a while, hehe).

You *can't* get the existing (original) RGB values (they are tainted by premultiplied alpha process) for the math. That's why you have to use a less than 100% accurate blend func. (approach) and tell it not to modify RGB for these types of images when tweaking opacity.

I assume that blatantly setting RGB values to opacity is a means of letting the developer know at runtime that something's not right (like a "Missing Texture" texture). It's rather obvious, as opposed to just having texture loading check it the image is premult. via the info flag, and then telling it not to modify RGB and use the diff. blend func. automatically (with blending results that might possibly be a little off, unbeknownst to the developer?). Is that the idea?

Thanks.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.