[Flash8] particles using bitmaps

Quote:

---

Originally Posted by BlinkOk

i would highly recommend that when you do the movieclip one have a shape (that is the same as the gun) and make the fill the gun bitmap. in cases like your demo it will run much faster

---

ummmmm, how so?

i'm simple attaching a bitmap to an empty movieclip, giving it a vector shape will only slow it down??

EDIT - sorry didn't see the "ahh, my bad" bit ;)

Malee, you're living in the past again! First the particles, then the reply to blink =D

to malee nd blink: what you two are saying is both partially true. A good while back one of those dirty little hacks was discovered to gain that tad more performance. Its basically about this:
-placing a raster image with transaprent area (so png,gif..) will have the more negative impact on performance the bigger the transparent area in that image is. That´s because flash will treat that area the same way as it would treat areas with vector fill where the fill features transparency. (So grab the color of elements behind and merge with colors in front and transparent values,so its a quite calculation power demanding calculation).
Now here comes that find in place: You could break the raster image apart and that way turn it into a vector shape with bitmap fill (what can be done via code in similar fassion with f8,too) and then cut away the transparent areas in that shape. Essentially you´d remove the transparent areas drawing heap for flash player.
But vector shapes are made up by flash by getting its corner points,connecting those and then filling that with the defined color(s) or bitmap fill. That´s calculated in realtime,too and so the more corner points a shape has,the more tedious becomes the calculation and the more performance it costs.
So all your nice "no use of alpha area" performance gain would be lost if you made your vector shape up of too many corner points. So yeah,its one of those dirty hacks which can lead to performance gain in some cases but also loss in other cases (if you have a complex shaped raster base image and then want to cut the transparent part away precisely for example) so meanwhile i wouldn´t suggest that to anyone anymore ;)
(Besides what i listed it can quickly become painful to cut away areas of tons of images and also doesn´t work well together with concepts like dynmic loadin of assets etc ;) )

Well said.

and that is why tomsamson is tomsamson

haha,thanks mates,makes me happy after beeing compared to a pothead yesterday (and the comparison wasn´t even that off besides me not having smoked anything ;) )

So ( Not willing to give up on this yet :) ), is the mc version wildly faster then ( malee your post implied that your test had proved much quicker than preds ) ?

Sorry, in work, got deadlines, so not really got the time to d/load and compare. Keep in mind that there's nothing clever at all happening in my code. There's no damage map ( btw I guess everyone is aware that Flash itself doesn't use a damage map ? You alter one pixel on a cached bitmap and it has to re-cache it. Nasty if you've cached nested mc's ), or multiple buffering etc.

Also blend modes may have a use for wiping the screen quickly ( ? ). All this stuff really needs playing with. I remember doing 3D stuff back on the Amiga, and such a huge chunk of your display time would be spent clearing the screen every frame it was unreal, and the same is kinda applying here.

I still think there's a lot of possability of using bobs ( Blitted objects ) instead of sprites ( mc's ) for things like bullets and particles in games, think it's just a case of refining it.

Squize.

About 20+ fps difference on this computer.

As for cached bitmaps, caching an MC with a bitmap attached doesn't make it any quicker, it infact hurts speed, if for example, you cacheAsBitmap a scroller which is updating the whole screen a few times a second.

As for implementing dirty rects, sure it could help, but still doesn't get around scrolling, once the screen moves, you either have to have a bitmap big enough to compensate, or scroll the bitmap, which is slow.

As much as I like BitmapData, I'm finding it harder to find uses, except for replacing the graphics inside MovieClips, the filters are too slow for full screen use also =(

That said, lots of fun can be had for animating between scenes in a menu etc, taking a screenshot of the screen, fading it out, chopping bits off, blurring it.

Quote:

---

Originally Posted by Squize

I still think there's a lot of possability of using bobs ( Blitted objects )

---

Bobs... I remember those from Amos Professional. Those were the days :)

"About 20+ fps difference on this computer."

Hmmm that's arse. It's tricky, part of me thinks this could be a winner, the other part thinks it's a complete waste of time, esp. when there's a million other projects to do.

"As for cached bitmaps, caching an MC with a bitmap attached doesn't make it any quicker, it infact hurts speed"

Yep, although still see the odd post here where it seems caching is treated like instant fast forward.
Just wasn't sure if people realised that if they had nested clips, with the top most clip with cache on, any single pixel alteration in any clip would cause a total re-draw.

"but still doesn't get around scrolling"

True. I guess the only way would be to use the damage map approach and blit directly to your scrolling bitmap, but that would mean a process of
paste
copy
plot
( Or similar )

Seems a bit long winded when sprites do this for free. I guess the saving there would come from only running the bobs every other frame, but that may mean running the swf at 50fps, to handle the bobs at 25.

Squize.