Strange (2d) alpha behavior

[classawarrior]

When I call makeColorKeyTexture using black rgb 0,0,0 and render it with draw2dimage, it appears with proper transparency in the pure black areas, as expected. A sprite with a black background is rendered perfectly.

Code: Select all

//Once
driver->makeColorKeyTexture(image, video::SColor(0,r,g,b));

...

//Each loop
driver->draw2DImage(image, position2d<s32>(x,y), rect<s32>(0,0,image->getOriginalSize().Width,image->getOriginalSize().Height),0,SColor(alpha,255,255,255) ,true); }

When I use pink rgb 255,0,255 and render in exactly the same way, the pink areas are non transparent! The pink pixels have definately been affected by makeColorKeyTexture as they are now black (but without the desired transparency). My sprite on a pink background has just become a sprite on a black background. This appears to be true when using any non-black colorkey.

Why am I getting different results simply by using a color other than black as a color key? Any help or advice is appreciated.[/code]

[classawarrior]

Also, rgb 1,1,1 or 2,2,2 are also recognised (incorrectly) as 0,0,0
This seems like a bug to me?


If I do:

Driver->makeColorKeyTexture(image, video::SColor(0,255,0,255));
Driver->makeColorKeyTexture(image, video::SColor(0,0,0,0));

Then the pink areas will be transparent, but only because the first call makes them all black. (This also leaves unwanted transparency in previously black pixels)

[JP]

Well what should the background colour be? What are you drawing the image on top of? Do you still call beginScene and endScene?

I guess 1,1,1 and 2,2,2 are interpreted as 0,0,0 due to a sort of threshold around the defined colour, otherwise the colours would have to be perfect whereas sometimes they're not.

[classawarrior]

Thanks for the reply.

Here is an image to better describe this strange behavior:

Well what should the background colour be? What are you drawing the image on top of? Do you still call beginScene and endScene?

The background should be transparent and I should see whatever is underneath instead of a black "bounding box" around the sprite. This is exactly what happens when I apply a black colorkey to an image with a black background.

My problem here is that the behavior seems to be inconsistent as only a 0,0,0 colorkey actually affects the alpha of the image, whereas other colorkeys leave matching pixels black, but still opaque! I am still calling beginScene and endScene, between which all of the drawing occurs.

Basically I have an image of a character on a magic pink (255,0,255) background, and then I apply a colorkey with makeColorKeyTexture and each loop draw it all over the screen many times. I see no pink, but the black bounding box of these images is clearly visible, especially when they overlap each other.

If, however, I open the exact same image in an image editing program and flood fill the background with (0,0,0), and then alter the call to makeColorKeyTexture to use a black colorkey, I see proper transparency and none of these ugly overlaps. If I want black opaque parts of the image, I have to manually lighten them to above 5,5,5 or so, so they don't match the colorkey. I don't want to use black as a colorkey.

I have tried drawing on top of a 3D scene, and also just a blank screen (i.e. without creating a camera scene node):

Code: Select all

//At "sprite" creation
Driver->makeColorKeyTexture(image, video::SColor(0,r,g,b));

driver->beginScene(true, true, SColor(255,10,10,10));

// Loop thru "sprite" objects, drawing their images with draw2dimage
...
Driver()->draw2DImage(image, position2d<s32>(x,y), rect<s32>(0,0,image->getOriginalSize().Width,image->getOriginalSize().Height),0,SColor(alpha,red,green,blue) ,true); 
...

driver->endScene();

The off black background color used in beginScene (10,10,10) means these "transparent" pixels are clearly visible as pure black.

I guess 1,1,1 and 2,2,2 are interpreted as 0,0,0 due to a sort of threshold around the defined colour, otherwise the colours would have to be perfect whereas sometimes they're not.

I can see why this would happen and might be useful, but as far as I know this is not the described behavior of the function and so is not, strictly speaking, correct behavior? The API documentation even makes a point of saying that because you might not have the perfect match needed makecolorKey(image, 2dlocation) can be used instead. I'd prefer to match exact colors unless I specify otherwise, but this is not really a big problem.[/code]