Erwin Verdonk @ 7:55 - February 16th, 2009

On line #132 you are adding the ‘historybm’ bitmap to the ‘holder’ sprite. Then you draw the ‘holder’ into a bitmap data object. Later you add the strokes to that same ‘holder’ sprite, while the original bitmap is still in there. That way they overlap and so create what what looks like a black border.

To solve this you should remove all children from ‘holder’ or make it a reference to a whole new sprite before you are going to add the strokes. I guess a good place would be on line #140 above the handler assignment for the ‘enter frame’ event.

- Erwin

Ronny @ 13:14 - February 16th, 2009

Hey Erwin,

the stroke-mask isn’t the real problem. Even when completely removing that thing the black borders still remain.

The real problem is described in Mario’s article on premultiplied alpha ( http://www.quasimondo.com/archives/000665.php ).
I posted it here too btw ( http://flashfocus.nl/forum/showthread.php?t=50892 )

Erwin Verdonk @ 14:20 - February 16th, 2009

I’m not talking about the stroke-mask. Please do not think I follow-up on Mario, Peter, or Ralph. I got it working here without black borders, so I think I indeed did fix the problem.

A simple test: Remove line #132 that says “holder.addChild(historybm);”.

When this solved your problem, please read my other reply more carefully. It explains why it happens and how to solve it .

Ronny @ 15:01 - February 16th, 2009

Hi Erwin

You’re right!
The black stroke SEEMS to be gone. It still is visible in some spots, but it’s mostly gone!

Thanks. I’m a bit confused though what was happening now. I’ll take a closer look at it tonight. Thanks a lot for your help!

I really appreciate that!

Erwin Verdonk @ 16:11 - February 16th, 2009

You’re welcome! However here there are absolutely no back spots visible, just as it should be. I’m home now and had time to test it a little more. This is what you’re doing and what causes the problem:

1. Load image
2. Make bitmap data of loaded image.
3. Make bitmap from bitmap data of loaded image.
4. Add bitmap as child to ‘holder’.
5. [...] some other non important executions.
6. Create another bitmap of the bitmap data of the bitmap of the loaded image, by copying pixels within an enter frame handler (I didnt make this up, its your code).
7. Next in that enter frame handler you add this other bitmap to ‘holder’ and so overlap the loaded image you added at point #4 of this list.
8. Now you draw the content of ‘holder’ into a bitmap data, later on at this bitmap data to the bitmap ‘animator’ and add it to the stage.

In short you’re overlapping within the ‘holder’ before you’re copying it to bitmap data and use it. That way what is transparent lets the loaded image a level deeper shine through which made it appear there was a black border.

I can only give you one piece of advice here; clean up your code before starting to debug or never make such a mess in the first place. This mess is what is causing these kind of mistakes and are very easy to prevent when keeping it more clean. Nothing to feel ashamed about, just something to keep in mind .

- Erwin

Ronny @ 16:22 - February 16th, 2009

You are definitely right about the mess in the code…
However when using another PNG image (with more different alpha values, i still see the black border (way less, but it’s still there))

http://shots.nocreativity.com/231fb72484c32977b7db8eb3e6ab79e5.jpg

That still seems to look like a result of that premultiplied alpha problem…

Erwin Verdonk @ 16:30 - February 16th, 2009

Can you email me your latest project? Also the slower one (before all the changes), so I can see what it should look like? e.verdonk at google mail .

Kris @ 17:29 - February 16th, 2009

Interesting and strange problem.
My ’solution’: use the new drawing API, very fast, no problems with alpha channels

a basic example:
http://www.neuroproductions.be/uploads/ff/eazvoorbeeld/
source: http://www.neuroproductions.be/uploads/ff/eazvoorbeeld/srcview/

Erwin Verdonk @ 20:10 - February 16th, 2009

The rest of the problem is not caused by premultiplied alphas. It is caused by overlapping as well. On line #217 you are drawing into a bitmap data object. But you keep drawing over everything already drawn. Which results in multiple transparencies on top of each other, which results in less transparency. When you have one bitmap with transparency 50% and put another over it with 50% the result will be 25% transparency. You do this a total of 360 times!

This is caused by the Tweener stroke alpha/scale animation, because it has a delay before it removes the strokes again from ‘holder’. So had to disable the Tweener stroke alpha/scale animation to make it work without overlapping. You can find the adjusted Tien.as here: http://blog.erwinverdonk.com/babyc/Tien.as (search for [TheDutch] in code)

For the animation you have to think of something else. But first I suggest you clean up the code and make it work smooth and well without stroke alpha/scale animation. Then it is time to think about how to work with a delayed removal of the strokes and stroke alpha/scale animation .

- Erwin

Ronny @ 20:44 - February 16th, 2009

I see where you are going with this, and I really understand the problem right now.

I think I figured out the solution to this problem too.
Thanks for helping me out!

I’ll keep you posted!