Optimizing Particles in AS3

Hi Guys

I've just moved this question from the AS3 board to here (chances are someone here may have an answer) ;)
I'm in the middle of developing a shooter which has a particle class that is spawning a lot of movieclip instances. Is there any way to optimize particles in AS3 to improve speed/performance? I've noticed things get a little sluggish when there's 800+ instances.

I tried using the "cache as bitmap" option but it seems to affect the motion. For some reason it makes it jerky. I can't figure that one out.

I have managed to increase the speed by between 5 - 9 FPS by replacing the vector particles with photoshopped bitmap particles, but I could still do with a few tips on giving it that extra boost.

The particles are just blobs and don't change shape, form or size once they are "born". A pre-determined number is spawned and they just move constantly and recycle themselves once they leave the screen, thats all.

Any ideas on optimization would be really helpful.

Thanks guys! :)

maybe you shouldn´t work with multiple instances but instead attach bitmap slices to a total bitmap- that way you dont waste resources upon massive instainces but instead just on arrays containing the coordinates + the complete bitmap shape to be rendered.

renderhjs's method is a good one. If you are using the particles for explosions, you can pre-render them and cache the output as arrays of BitmapData objects. All of the particles for each explosion (or other effect) now become one array of bitmaps. You then render each frame of the animation like renderhjs says above. That way you don't have to calculate anything on the fly. The only down side is having to pre-render them in your game initialization.

A more advanced version is to render the first one on the fly, and cache its frames during that first render. The next one and every other one is built like above, from the now pre-cached array of bitmapdata frames.

I have some methods that might help you in an article(s) on my site:

http://www.8bitrocket.com/newsdispla...?newspage=7496

http://www.8bitrocket.com/newsdispla...?newspage=2594

The second one applies to AS2, but the exact same idea can be used in As3

-Jeff

Each particle only needs 4 properties: x, y, xmov, ymov. You dont need MovieClip class for this, instead extend Point class for example or basic Object. Then use 1 single bitmap and copyPixels to draw it on screen at position of each particle.

Also consider using time based movement instead of fixed fram based value, this will make them move at same speed even when fps drops so fps drop becomes less visible.

It is probably not even needed to move them all at each frame, split them in half and move first half in one frame and other half in next frame.

Ok thanks for all the replies guys.
I forgot to mention that its a heavy snow scene, which I'm trying to replicate.
Theres several layers of snowfall with each flake falling at a different speed. Each flake also has a different transparency.

As soon as one flake goes off the screen, its moved back to the top again (rather than killing it)

I think the idea of drawing lots of flakes to a bitmap and then drawing that to the stage every timer-tick would work well, but I'm not sure how I'd go about doing that (I'm still a beginner)

Do you have any easy-to-understand sample code I could look at which demonstrates this or something similar?

I appreciate the help! Thanks! :)

I did a tutorial last year on the subject. It details more than just blitting. It explains how to create a sprite sheet, use a tile editor to create a level, read in the XML for the level into a basic a tiled based engine, and blit all of the tiles to a single bitmap data. It is here:

http://www.8bitrocket.com/newsdispla...?newspage=6077

-Jeff

Quote:

---

Originally Posted by tonypa

use 1 single bitmap and copyPixels to draw it on screen at position of each particle.

---

Could anyone point me to a practical example of this in action?

Thanks! :)

I believe Dave did it that way with this,

http://www.kongregate.com/games/JGOware/retroshoot360

If he didn't then he's got some magic skills to get that much stuff running so quickly.

Squize.

http://www.birchlabs.co.uk/Invasion5CP.swf
http://www.birchlabs.co.uk/Invasion-5.swf

Should be up to pumping out a few hundred easily. :)

Hi,

I have specific question about this technique: how can one modify the alpha of individual tiles or particles?

Yes, copying sprites and their positions to one bitmap data, clearing bitmap data, and re-drawing to it.
If you still get a slow down, you could optimise by slowing down how fast the bitmap data re-draws until its as slow as it can go without looking jumpy.
I will be willing to test if you show a demo on here sometime. I'll mention my pc specs. Infact, might put my pc specs in my signature.

if you want your bobs to be able to fade out individually, you're gonna have to put faded sprites of them into the spritesheet. for example:

http://birchlabs.co.uk/ArrowSpriteSheet.png

these have been pre-rendered to be able to rotate and fade out.

If it's any help, I'm still working on my blitter engine and I've found it quicker to use copyPixel to clean the canvas ( ie copy a background image to it then plot on that ) than fillRect.

Squize.

woah. I'll try that myself. btw, what's your opinion on using object pooling for bobs? the objects being instantiated aren't massive DisplayObject ordeals, they're a tiny class with coordinate, angle and frame information and not much else, so they're pretty quick to make and delete.

Thank you for feedback, everyone!

I have a few working tests running and, wow, I'm impressed! I haven't done any benchmarking but this feels 4-5 times faster than moving Sprites around. I'm loving it!

Vengeanace, Thank you for your feedback regarding alpha/fading!
I spent quite a bit of time trying to figure that out, but don't know the Bitmap/BitmapData classes well enough to know if there was something I was missing. I thought I could use BlendMode.APLHA or mergeAlpha in some obscure way, but I couldn't get anything working. So, that explains - I can't!

I've got it then: just pre-render alpha and rotation in the tile sheet.. makes sense for performance reasons too.

Regarding clearing the canvas.. this is the code I'm using:

_bitmapData.fillRect(_bitmapData.rect, 0);

Squize, how do you clear the canvas with copyPixels... ?

Hey Vengeance, please forgive my ignorance, but what are "bobs" and what is "pooling"?

Thanks everyone! :)

Ah, when you're blitting sprites around a screen, the sprites you are plotting would be your 'bobs' (http://en.wikipedia.org/wiki/Blitter_object).

Object-pooling is a way to avoid the slowdown associated with creating and deleting objects. For example, if I want to make a bunch of sprites fly around, I can create several thousand sprites when I'm setting up the game (so take a few seconds hit on performance while you make all of those), and then just use one of those whenever I need a new sprite. You can recycle them, so if your projectile gets used up (like a shell explodes), you can throw the sprite object back into the pool to be used again.

The problems with it are that you get that bit of slowdown when you're creating the pool (which isn't a big problem, as that only happens once), you need to allocate a pool bigger than you'll actually need (which means your memory usage will always be higher than if you hadn't pooled), it adds a little bit more complexity when you're trying to create objects (which is a big issue if your code is as messy as mine), and it might be that creating a small object with few variables in it would be faster than going through the process of looking up and recycling one from the pool (and this is the bit I want to know... but I guess it wouldn't be a big deal for me to just check myself).

Thank for that excellent explanation, Veng!!

Ah, so it looks like pooling is much like a look-up table, which I use all the time to pre-calculate vectors.

"Bobs"... got it! That was a nice trip back to my Amiga days ;)

I do have one other question:

The last bob drawn appears on top of the others. What's the best way to manage stacking order in this system?

(Thanks for your patience everyone, this is a new topic for me! :) )

Maybe a linked list? So:

objectsArray = [someObject0, someObject1, someObject2];
depthsArray = [1, 3, 2];

Indices of each array correspond to each other, so someObject0 is considered to be at depth 1, someObject1 is considered to be at depth 3, and someObject2 is considered to be at depth 2.

So that's a way of organizing and keeping track of what depth to put them at. As for how to actually draw them at the depth specified... since you'll be using copyPixels() to draw them in, you need to draw them in the order you want them. So go through depthsArray until you find the lowest number, and the array element from the depthsArray that has that number, is the same as the element of the object you currently want to draw from the objectsArray.

Thanks again Vengeance! That's a great place for me to start, I'll take a stab at it!

How my engine works is by emulating the DisplayList, so it does all the depth sorting for me.

Hmmm, rather than re-write it,
http://blog.gamingyourway.com/PermaL...f9fb0c74e.aspx

V, as to pooling, yeah I always use it. It doesn't really matter about the size or complexity of the objects you're creating, by pooling you're saving having to run the constructor code every time and nothing is being flagged up for GC, so now unexpected glitches when the GC kicks in.
Pooling takes no time to set up, just use a Vector list.

dandylion to use copyPixels to clear the screen just set up a bitmap as your background, which can be as simple as a black rectangle the size of your screen, and copy that onto the canvas bitmap which you'd usually use fillRect on.

Squize.

ah, I see. managed to get pooling up for the arrows in Invasion... not convinced that I've gained any framerate (maybe a tiny bit), but it definitely no longer judders every few seconds from the GC. :)

http://www.birchlabs.co.uk/Invasion5Pooled.swf
http://www.birchlabs.co.uk/Invasion5NoPool.swf

(also, fun result from when I forgot to reinstanstiate gravity: http://www.birchlabs.co.uk/Invasion5Fun.swf)

Can you explain this whole BitmapData.lock() and unlock() thing to me? it sounds like it's something I should be using.

Oh, I assumed you would be using it.

Basically locking the bitmap stops it forcing a redraw, so you lock(), blit all your bobs, then unlock();

unlock() also takes a rectangle as a param, so you can use that for dirty rectangle handling on the main canvas.

Squize.

Just implemented that. Not sure if it makes a difference... possibly it does? But is the assumption here that Flash will try to render the bitmap halfway through the frame (or every time we run a copyPixels())? and what does 'render' mean 'draw to screen'?

Thank you Squize!
That's an excellent blog. It's great information which covers a the things I've been puzzling over the last few days.
I will definitely look into pooling, I didn't realise how efficient it was. Now that I'm working on a project that's pushing around a gazillion particles, this stuff is becoming important.

I like your practical take on benchmarking too (from your blog).. That was always my feeling... but I thought I was just being lazy ;) :D "A lot faster" is good enough for me!

Cool, I will try that copyPixel clear screen trick.. it's blindingly simple, I see now! :)

V, in terms of locking a bitmap it means rendering to the bitmapData object, rather than rendering to the screen.

You're not going to get a huge increase in performance, same as pooling, but when you're dealing with lots and lots of bobs then these little things make a difference ( Like marking the class as Final ).
If you're tracking dirty rectangles though you can reduce the number of pixels which need plotting which helps more ( via unlock(rect); ).

No worries dandylion, glad it was some help. I've got some ideas on how to improve the blitter engine for using on the iPhone via CS5, but times against me atm, so it's on the back burner for now.

Squize.

Right. 'Dirty rectangles' refers to something related to damage mapping, I assume?

And what's this about marking a class as Final?

Yeah it's damage mapping.

If you know the largest rectangle which needs updating then you can just unlock() that sized area.

As to final ( Sorry I shouldn't have capped the F ),

public final class myClass{

}

Gives a minor speed increase as it stops the class being dynamic. You can also use it on methods too, but I've got to be honest I've never felt the need to push things that far.
I mainly just use it on particle classes, where I'll be running lots of instances.

Squize.

I thought 'static' was to make something non-dynamic?

Quote:

---

Originally Posted by VENGEANCE MX

I thought 'static' was to make something non-dynamic?

---

"final" means that the class can't be extended.

It means you can't do this:

public function AnyClass extends...

.. it also prevents you from overriding any of the class's methods.

"static" means that any of the class's properties belong just to that class, not its instances.

To be able to add properties dynamically you have to declare a class as "dynamic".

The MovieClip and Object class are dynamic, so you can add properties/variables to instances of those classes on a whim, whenever you need to. This is convenient because you don't have to build a whole class to support those new properties.

Quote:

---

Originally Posted by VENGEANCE MX

Maybe a linked list? So:

objectsArray = [someObject0, someObject1, someObject2];
depthsArray = [1, 3, 2];

Indices of each array correspond to each other, so someObject0 is considered to be at depth 1, someObject1 is considered to be at depth 3, and someObject2 is considered to be at depth 2.

So that's a way of organizing and keeping track of what depth to put them at. As for how to actually draw them at the depth specified... since you'll be using copyPixels() to draw them in, you need to draw them in the order you want them. So go through depthsArray until you find the lowest number, and the array element from the depthsArray that has that number, is the same as the element of the object you currently want to draw from the objectsArray.

---

Someone correct me if I'm wrong, but this is based on AS2 theories. In AS3, even if you add two objects at depth 1 and 3:

Code:

---

stage.addChildAt(mc1, 1);
stage.addChildAt(mc2, 3);

---

mc2 still falls down to a depth of 2 preventing you from creating "holes" in the stack order. Presents a bit of headache when trying to simply swap depths on an isometric engine, for instance (at least it did for me... it was a serious pain in the ass!).

Quote:

---

Originally Posted by dandylion13

The MovieClip and Object class are dynamic, so you can add properties/variables to instances of those classes on a whim, whenever you need to. This is convenient because you don't have to build a whole class to support those new properties.

---

So to say this is to imply that -any- object can be turned into a dynamic object capable of taking on new members?

Code:

---

var s:Sprite = new Sprite();
s.myVar = "Error"; // error here, null reference if memory serves

dynamic var s:Sprite = new Sprite();
s.myVar = "Success"; // this works?

---

Quote:

---

Originally Posted by Squize

Yeah it's damage mapping.

If you know the largest rectangle which needs updating then you can just unlock() that sized area.

---

Don't suppose you can elaborate on this a bit more? Maybe a simple example fla?

Quote:

---

Originally Posted by Squize

As to final ( Sorry I shouldn't have capped the F ),

public final class myClass{

}

Gives a minor speed increase as it stops the class being dynamic. You can also use it on methods too, but I've got to be honest I've never felt the need to push things that far.
I mainly just use it on particle classes, where I'll be running lots of instances.

Squize.

---

But if you wanted optimal performance you'd want to set any classes to final that you were either creating instances of or you didn't want to get over-ridden by the parent classes methods?

Quote:

---

Originally Posted by ImprisonedPride

So to say this is to imply that -any- object can be turned into a dynamic object capable of taking on new members?

Code:

---

var s:Sprite = new Sprite();
s.myVar = "Error"; // error here, null reference if memory serves

dynamic var s:Sprite = new Sprite();
s.myVar = "Success"; // this works?

---

---

I think you can just declare a class as dynamic, not its instances. (Someone please correct me if I'm wrong!) Like this:

public dynamic AnyClass...

That means the code above won't work for Sprites, because the Sprite class is not dynamic. However, you could create a dynamic class that extends the Sprite class so that you could add properties to instances of that new class.

How I handle depths is via my PlayField class. That's just a list of bobs in that particular playfield. If I need to swap depths then I just alter the order of the list.

The Canvas class loops through each playField ( In order, so these can be sorted too ), which then loop through each bob.
It's pretty much how Flash does it anyway.

"Don't suppose you can elaborate on this a bit more?"

In pretend code

*Update sprites position
*Is the sprites x< the current left hand side of our rectangle ?
* Yes, so make the left hand side of our rectangle this x value
*Do the same for all the remaining sides of the sprite

"But if you wanted optimal performance you'd want to set any classes to final that you were either creating instances of or you didn't want to get over-ridden by the parent classes methods?"

I guess so yeah, although for classes which only have one instance it's neither here nor there really, whereas if you've got a 100 pooled instances of your particle class then it's a bit more worth while ( Although nothing major, none of these tips are, it's just when you're doing something really intensive that it makes a difference, like a plasma effect or a voxel engine like the one I did, where the sheer number of things running every little helps ).

Squize.

Hi!

I just ran some tests of my own and clearing the stage with fillRect runs a few frames faster for me than using copyPixels.

But this doesn't mean it always will.. it's worth trying both ways, context might make all the difference.

Has anyone tried adding clipping to their engines yet ?

Say the bob is half on/off the screen, is it worth running a test for that and reducing the size of the copyPixels rect rather than leaving Flash to do it ?

Just wondering if it's worth while.

Squize.

I just discovered this article on basic blitting that was published by Adobe a few weeks ago. It might help someone new to this:

http://www.adobe.com/devnet/flash/ar...itting_mc.html

Not gonna run any tests, but here's my two cents:

It's probably not worth implementing clipping for small objects; let's say you have 5,000 small objects on-stage, chances are very few of them will only be partially on-screen. Let's say 100 are half off-stage... even if we save some time drawing those, we probably had to ask the other 4,900 a pointless question. I can only imagine that being slower.

However, if we're working with big sprites (which by definition are more likely to be half on-screen), like if we're using a copyPixels() engine to draw parallax and background trees and stuff. Then I can see there being a point in checking.

For small objects, it's probably still worth running a check "should I draw it at all", but not running "should I draw it partially"; if your objects could really go anywhere, and have a reason not to get deleted when they leave the stage boundaries, then I can see it being worth running that coordinate check if it's likely to occur.