Saturday 14 February, 2009
World360 update, now with PNG bug!
Yesterday I decided to get back to my so called ‘World360′ experiment. I wanted to speed up the pre-rendering engine. I managed to do that, with some amazing results: Up to 3 times faster overall. Peaks of 800% speed gain!
You can view the previous version here.
The latest version can be viewed here.
I’m very happy with that, but there’s one little problem. I started to notice a very ugly black border around redrawn PNG transparency (which happens when the animation is pre-renderd).
Result without redrawing bitmap (aka: real time rendering)
Result when redrawing the bitmap (aka pre-rendering)
I have no clue what is going on… I have been looking into this issue all day, to no avail… If anyone knows what is going on, feel free to enlighten me.
The PNG file is fine, it’s not corrupt or badly exported, since it works just fine in different versions of the render engine. I do however wonder if redrawing a bitmap over and over again doesn’t create some kind of noise.
If you feel like giving it a shot you can download the .as file here, or get the complete Flash project (.fla + .as + assets) here. (The code is quite messy… Just so you know 
)
If anyone can point me into the right direction, your help would be much appreciated (and you shall be remembered forever)!
To illustrate the difference I uploaded 2 more versions.
Check out the previous version here (longer render time, but no PNG problem).
See the latest version here (using the faster implementation, generating very ugly black borders).
Edit: You can download the sources for V9 and V10 here to see the difference of the result.
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
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 ).
( http://flashfocus.nl/forum/showthread.php?t=50892 )
I posted it here too btw
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
.
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!
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
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…
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
.
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/
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
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!