1. Code
  2. Effects

Squeezing More Juice Out of the Flash Player

Read Time:33 minsLanguages:

In this tutorial you'll build an extreme particle system whilst learning how to squeeze more efficient goodness out of the Flash Player than you ever thought possible!

Republished Tutorial

Every few weeks, we revisit some of our reader's favorite posts from throughout the history of the site. This tutorial was first published in December of 2010.

Final Result

Here are a couple of examples of what we'll be working towards:


Please don't view this demo if you are likely to suffer from epileptic attacks or loss of consciousness, particularly when looking at some types of strong flashing lights, rapid succession of images, simple geometric shapes, flashes or explosions.

Introduction: What Will You Learn?

Many users, from beginners to advanced, can still be seen using less than efficient Actionscript 3.0. In all likelyhood, this is because the efficient ways are made to sound a bit more difficult and aimed at highly advanced users. This tutorial will show you that these methods can be used by everyone, and they're more useful than you may think!

The aim of this tutorial is to let you tackle those tasks that require working with a lot of data, very fast, with ease.

Helpful Hint: This tutorial will feature a lot of coding so I recommend using a more user friendly coding interface. I recommend FlashDevelop, it has some of the best code hinting around and best of all, it's completely free! But I'm sure most of you will just copy and paste if do anything at all :)

Step 1 Check out That FPS!

At the heart of making all things efficient in the Flash Player is the FPS (Frames Per Second) of your SWF. The proffered target of your SWF can be set in the Flash Professional interface or, a new feature in Actionscript 3.0, you can change the FPS of the stage at runtime.

However, this will only ever get and set the target FPS (what the Flash Player will attempt to play at), which makes it pretty useless for preformance testing. You might think that the lovely folks over at Adobe would made a nice neat way to find you real FPS but, nope. You've got to do the math for yourself. Let's take a look.

FPS can be defined as the time difference between the current frame and the last.
So all we need is some way to track the time difference from this frame to the previous frame of the SWF. This uses the document class feature. If you are unsure how to use this, check out this Quick Tip on how to use a document class.

We will use this function as the benchmark for comparing the efficiency of different methods from here on. As you might have noticed, we use the function to calculate the time difference, not the FPS. This is because tracing the time difference is actually much more useful and easier to read when we get to the speed tests. Calculating the FPS only becomes useful when we are putting everything together at the end.

Tip #1 Arrays vs. Vectors

Have you ever needed to store a whole bunch of numbers, strings or objects in a list? Of course you have! But the question is - have you been doing it right?

If the first thing you think think of when making a list in AS3 is an Array, then this tip is for you. A Vector is exactly the same as an ordinary Array except for one fact, it is a typed Array. This means that you can only populate it with one type of item. For instance, you can put a number and a string in the same Array, but not in a Vector.

Let's take a look at the only difference between an Array and a Vector, declaring the Vector.

As seen above, declaring the vector is the only difference between the two types. To have the Vector hold another object, just replace String with your object. For holding MovieClips for example:

How does this make it more useful? If all the elements in a Vector are the same type then the Flash Player can zip through them much much quicker because it knows what's coming up and doesn't have to test the next element every time (this is true even when declaring a variable type, so never leave it out!).

How big is the difference? Surprisingly big actually! Let's take a look at our first speed test.

Speed Test #1 Array vs. Vector

This outputs the following:

You shouldn't get exactly the same results as what I have here of course, you will almost never get the same set of values yourself even as this depends on how much effort your CPU can push into this at runtime.

The first pair of values comes from writing into the array and vector respectively. We can see that the Vector shaved off almost 0.6 seconds, quiet a substancial amount if we need to do something similar 24 (standard FPS for flash movies) times a second. After all, 1/24th of a second is just over 0.04 seconds.

An even bigger percentage difference can be found when you are reading from an Array vs. from a Vector, and this is luckily what you will need to do most of the time every frame.

Hopefully, after reading this section you should be comfortable with using Vectors in your projects for that extra kick of efficiency.

Tip #2 Event Listeners

Like all things in Flash, there's more than one way to solve a problem, Event Listeners are no exception. In this tutorial we will look two methods of attaching the Event.ENTER_FRAME listener to your particles.

Method #1 One Listener per Particle

The idea behind this approach is that you attach a listener to each of your particles and direct them to a set function. This isn't ideal for what we have in mind but remember a particle, in terms of programming, doesn't have to be a single dot. For instance, this method might be preferred when going between Flash based webpages or objects that are treated differently in the listener function. Let's take a look.

Method #2 One Listener to Rule Them All...

The second method is the one that we will be using and the preferred method when dealing with a lot of similar objects. The idea here is to attach a single listener to only one object - usually the stage - which then loops through each of the particles and tells each one what to do on each frame. This method is slightly more complex as we need some way to reference the particles, so we put them into a Vector. Let's take a look.

Speed Test #2 Methods of Using Event Listeners

Unfortunately there is no hard and fast way to accurately check the difference in speed between these two methods because of the inconsistencies of the calling process while using method one (at least not an accurate method that won't require its own complete tutorial!)

Take my word for it, using method two is far better for use in particle systems because of two major factors:

  • Huge speed increase
  • Much easier to reference other particles from particles

After reading this section you should now know how to comfortably keep track of and reference many particles. Remember, method one for objects that should treat their listener function differently and method two for many objects that all should be treated in exactly the same or a very similar way in their listener function.

Tip #3 Building Your Particle

The next step towards our complete particle system is building the right particle for ourselves. It might so happen that you'll need a full MovieClip for each particle, to make use of frames and such, but for us, a MovieClip is a huge overkill. All our particle is is a placeholder for a bunch of values that need to be kept together and relate to each other. This allows us to drastically reduce the size of the class used.

The following is the basic class we can use for our particle.

Notice that it does not have any base class (i.e. it does not extend anything) and therefore it is 'born' without properties that you might use regularly, for instance the 'x' and 'y' values. To correct this, we use build our own getter methods to read these values. These values are then passed into a Vector3D object. A Vector3D object is basically a Vector which holds three variables and an optional fourth variable. The difference is that you can reference these values as 'x', 'y', 'z' and 'w' respectively, The 'w', which is optional, could be used to old a rotation value for example. This makes this type of holder perfect for what we need.

(We could even create these properties as public Number variables within the class directly, without using any Vector3D objects at all... but let's stick with what we've got.)

But how exactly does creating our own class help? Let's make a quick memory test to find out! Remember to save this, your document class and the Particle class in the same destination.

This Outputs something like the following:

Speed Test #3 Our Particle vs. Movieclips

As you can see, there is a massive difference between the size of our class and the movieclip. Freeing up all this space allows more space on your RAM and so it allows the whole Flash Player to run quiet a bit faster. How much faster? Let's take a look at that too! Much of this code is the same as our Array vs. Vector Speed test.

This should output something similar to the following:

As you can see from these results the real difference is in the writing times; this is because the Flash Player has to draw on more resources (the base classes of the MovieClip and each subsequent object) to complete this. In our main project this isn't any real issue since we only need to create new Particles at the beginning but we will see an example later on when pushing new Particles in all the time becomes necessary. The difference in reading times is almost neglectable since both classes use their getters for the 'x' property in the same way.

After reading this section you should be comfortable with building your base class for your particle's needs.

Tip #4 Introduction to Bitmaps

Bitmaps, and their partner in crime BitmapData, are usually some of the two most confusing steps for a beginner, mainly because what they are generally used for is higher level stuff. Here I will give a short introduction on some of the basic and most used methods regarding the Bitmap and BitmapData classes.

What are They?

In the quickest explanation possible:

  • The Bitmap class represents display objects that represent bitmap images
  • The BitmapData class Let's you work with the data (pixels) of a Bitmap object

Basically, the Bitmap class displays what the BitmapData class tells it to. They go hand in hand practically always.

Drawing with Bitmaps

The BitmapData class does not have a graphics property of its own, yet it remains one of the most important classes for Flash graphics! How? It draws the shapes of other classes. Let's take a look at how to draw a simple circle using Bitmaps and BitmapData.

This results in a simple grey circle touching the top left corners of the stage when run. The draw() method is simply a snapshot of the movieclip at that time so in theory we could move the circleShape object around an continue to draw it to give the effect of many circles. This is how a lot of drawing within bitmaps is done.

The setPixel() Method

Because at the base of all graphics are raw pixels, this method becomes very important for creating effects using the Bitmap and BitmapData classes. It allows you to change to color of a pixel inside the BitmapData area. Heres how that's done.

You should end up with something that looks like this, with more dots appearing on every frame:

This is the graphics style we will use for our system. Don't worry if it looks kinda terrible right now, at the end you'll see how we can make these look much better with a whole bunch of effects.

The lock() and unlock() methods

These methods are some of the least used but most helpful regarding bitmap. In fact I would have never known about there existence if it wasn't for a great little site called WonderFl where members regularly boast massive particle systems, the truth is that these were the inspiration of this tutorial!

You might be hard pushed to find a similar set of methods to use together, this is how they work:

In essence, you wrap the lock() and unlock() methods around the point in which your code is changing the appearance of a Bitmap. While for the situation shown above they aren't all that useful, in a large scale system with many thousands of changes to the bitmap they speed up the process by a long shot. This is because the Bitmap and BitmapData classes like to have a lot going on at once, the more changes you can cram into a single step the better they become! These methods are great for that as they put on hold all changes made to the locked bitmap until it is unlocked, and this means it isn't re-rendered during that time, which speeds up the process.

Clearing Your Bitmap

The BitmapData class doesn't offer a clear cut method to create wipe its data, so here are two common ways to do so. We can reuse all the the code from learning about the setPixel method.

If you use the clearRect method, it simply draws a completely new grey rectangle over everything else. This isn't as careless method as it sounds at first because remember all you are ever doing with a Bitmap is changing the color of a set of pixels; overlapping items makes no difference what so ever.

The second option blurs out the dots by merging them into the background. We will use this later to create more interesting effects. You should note that this method requires a significantly longer compute time and should be avoided if efficiency is your only concern. We will leave this until the last bit of the tutorial where we are not aiming for maximum efficiency.

Speed Test #4 Bitmap Drawing vs. MovieClips Drawing

This is our final speed test and here we will test the speed difference between drawing multiple shapes using the Bitmap classes and the MovieClip class. Here is is:

CAUTION: The regular createMovieClipCircles() method is so inefficient that you should not let it run for more than a few seconds. The Flash Player will continue to slow down until it eventually grinds to a halt.

What you should find after using both methods is that:

  • The createMovieClipCircles() method grinds to a halt after a few seconds
  • The createBitmapCircles() can keep running all day at 24/24 FPS and not slow down

The createMovieClipCircles method is so inefficient because it needs to add each circle to the display list which leaves the Flash Player struggling to hold the weight of them all. This is why we must use the Bitmap and BitmapData classes in our particle system.

From reading this section you should now be familiar with many of the methods we can use from the Bitmap and BitmapData classes to build our particle system. I have covered much of what we need to know to build such a system so now I think its time we dive in!

Building the System

Our system won't be pretty, but dang it will be fast! It will be composed of two classes, the Particle class we made earlier and the controller class that keeps check of everything. Our aim is to build a system that will brush off 100k particles, laugh at 150k particles and take on 200k comfortably. Of course this depends on your system, but mine is about six years old and hasn't blown up yet so I'm sure most of you will be okay.

First we will start with the basic Particle class, much of the code that you will see will be the same as in the steps previously described.

In keeping with OOP traditions, our particle is as encapsulated (self-contained) as possible. It defines its own x- and y-positions to keep clutter and unneeded variables from the controller class and only needs the update() method to be called for it to be ready for the next frame.

Next is the Controller class. This class is the brains of the operation doing all the looping and drawing on each frame.

Thats it! You have what you saw in the first demo.


Please don't view this demo if you are likely to suffer from epileptic attacks or loss of consciousness, particularly when looking at some types of strong flashing lights, rapid succession of images, simple geometric shapes, flashes or explosions.

Unfortunately there is a problem. If you run this code inside the Flash Professional IDE it will never run at 24/24 FPS. This is because when you run it here, the Flash IDE tries to connect with Flash Player to read many different things off it, this is how you get your error reports when something goes funny. However, luckily for you, your clients probably never have to see this side of things and on its own, the Flash Player works beautifully, running easily at 24/24 FPS. Its just slightly more difficult to read the FPS. I recommend making a small dynamic text field and output what we are should be tracing to that, this is outside the scope of this tutorial and is something that is pretty straightforward so I can leave that with you.

So now that you have made your particle system, wouldn't it be nice to show it off to your friends and clients? Coming from experience all you will get from showing this one is some weird glances with some squeezed praise on the side from all of those but seasoned programmers. Let's make something pretty.

Over 9000?! Playing it Safe With so Many Particles.

Before moving on any further I recommend tinkering around a bit with the above particle system and see how far you can push it. On my less than average system I can go to about 200,000 at 24/24 FPS and at 250,000 its at about 18/24 FPS, just as a reference. Get a grip for how far you can push your own system and heck, even boast about it in the comments! :)

Let's look at some of the things you should avoid when playing around with systems such as this.

Trace statements. One of the most useful things in a Flash Developer's arsenal is actually a big task for Flash Player. Once per frame is okay, but make sure you don't shove it into one of your particles when you have 200k of them running. This will simply instantly crash the Flash IDE and you'l spend the next couple of minutes pressing all the exit buttons. A good way to test something in a particle is just to drop the number of them to something between one and ten.

Everything matters when you're doing something 200,000 times 24 times a second so be sure to keep looking through your code and never make any big changes without putting the number of particles down to a single number.

Making Something Pretty - A Basic Waterfall Effect

This will be a very basic example of building something that looks mildly attractive.

This is the updated Particle class which is used to create the waterfall:

As you can see there need to be no major changes to the Particle class because it will always stay as a just a placeholder for a group of related numbers and funcions.

Next is the Controller class. Again, there is no need for any major changes. Let's take a look:

You should end up with something like this. If you've just found this, you might want to hit refresh in your browser to see the start of the waterfall to better understand how the particles move.

Needless to say that you can run and run with the basic ideas here and great some amazing effects, a lot of which pop up on WonderFl quite often, or even to create this kind of effect. (shameless self plug :) ) A very 'cool' thing to try out is to have the particles interacting with the mouse in some way, the effect can be ne beautiful when done correctly. The perlinNoise() method of the BitmapData class might also be worth mentioning here as it sometimes used in particle systems to create a flowing effect, which can also be very beautiful.


I hope after reading this that you can take away a number of things from how to get the most out of Flash Player in your code to an introduction to building particle effects. Most of all, I hope I ignited a little flame of curiosity somewhere and gave you a new set of boundaries for Flash itself. Hopefully, an 'extreme' particle system won't seem too extreme anymore :)

Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.