Learn to Optimise your AS3 Code for Speed and Performance

Optimisation is about making your code more efficient. Usually you’ll optimise for speed — not to make the *gameplay* faster, necessarily, but to keep the game running smoothly, with no lag.

(If your SWF is a few MB larger than you’d like, you’d want to optimise for *size*, but that’s a different topic for a different post.)

The hundreds of tricks and techniques to do this boil down to one principle:

###Don’t make Flash do more work than it needs to

For example, suppose you have a line like this:

var newX:Number = ( 47 * Math.sin( Math.PI * 23 / 109 ) / 121.88 ) + player.x;

…and you run that line every tick or every frame. Look at all the work you’re making Flash do!

It’s got to get the value of pi and multiply it by 23, then divide that by 109, then get the sine of that number, then multiply that by 47, then divide it all by 121.88, and *finally* add the player’s x-position.

If you grab your calculator, you can find that 47 * Math.sin( Math.PI * 23 / 109 ) / 121.88 is 0.237317256. That’s not going to change; we don’t need to make Flash keep calculating that over and over again. So that line can be rewritten:

var newX:Number = 0.237317256 + player.x;

Suddenly, Flash has much less work to do — you’ve done the work for it.

Let’s look at some better examples…

###Creation is slow

Whenever you write someObject = new Whatever(), Flash has to do a whole bunch of stuff behind the scenes involving memory and references and goodness knows what else. This takes time. Learn from eco-protesters and recycle, instead.

For example, in my avoider game I create new enemies at the top of the stage, move them down every tick, and remove them when they reach the bottom.

So, Flash has to deal with a call to new Enemy() every few ticks — slow!

Instead of removing the enemies that reach the bottom, I could *move* them back to the top, and reuse them:

This requires more code (and more work on our part); rather than writing:

newEnemy = new Enemy( startX, startY );

…we’ll have to keep track of old enemies that have moved off the screen, then pick one when it’s needed and call:

oldEnemy.x = startX;
oldEnemy.y = startY;

It’s a trade-off; working out all the new code logic requires time and work on our side, but reduces the time and work required by Flash — though we only have to write the code once!

###Drawing is slow

Any time there’s a change on the screen, remember: Flash has to redraw all those pixels. Sometimes, setting your game’s frame rate to 24fps can actually make it run more smoothly than at 30fps, because there’s a little extra time each frame to do all the drawing work.

Alpha is a source of lag. If you’ve got a semi-transparent object (object.alpha = 0.5) then Flash has to draw that object *and* the object behind it:

Graphical filters require a lot of work on Flash’s part, too. Calculating (and then drawing) a glow, a shadow, or a blur is a heavy operation.

Do you need to apply these effects on the fly? Often you can generate them in Photoshop beforehand.

When you’ve got a lot of objects on-screen at once, it can even be faster to bypass Flash’s built-in drawing routines altogether, and write your own. (I have a tutorial on “blitting” like this lined up for next week.)

###Pixel-perfect collision detection is slow

Flash’s DisplayObject.hitTestObject() method is a simple way to detect whether the axis-aligned bounding boxes of two objects are overlapping:

…but this isn’t always good enough:

We can use a pixel-perfect collision method (such as this one), but these are very slow — you’re making Flash check every single pixel of one object against every single pixel of the other, to see if any overlap. If there are a lot of potential collisions, this can take a loooong time.

Since each method has its advantages (speed vs. accuracy), we can use a combination of the two: use hitTestObject() to see if any two objects are overlapping, and if they are, use a pixel-perfect method to see if they’re actually colliding. It’s slower that just using hitTestObject(), but much faster than using only the pixel-perfect method — and you get the accuracy of the latter.

###Optimise your design, too

You know what’s faster than using the two-stage collision detection routine outlined above? Not needing to use pixel-perfect collision detection at all.

If all your objects fit snugly inside rectangles, you’ll be fine just using hitTestObject.

Likewise, if you use simple line-art, you probably won’t need alpha transparencies or fancy graphical filters. If you only have eight objects on-screen at any one time, you don’t have to worry about creating new ones.

Sometimes it’s OK to let restrictions alter your design.

###Avoid premature optimisation

Optimising code as you write it is a waste of time.

That first draft should be loose and easy to change; focus on getting it working and trying out new features before you worry about making it lightning fast.

If you try to make every line perfect as you write it, it’ll slow you down. Plus, you’ll be reluctant to change it later.

Also, don’t *over*-optimise. Consider this:

if ( player.x > playingField.rightEdge.x )
{
    player.x = playingField.rightEdge.x;
}

It would be faster to run:

if ( player.x > 150 )
{
    player.x = 150;
}

(…assuming that playingField.rightEdge.x is 150, of course.) But the speed gains here are minimal, and we lose flexibility; what happens if we move the playing field at some point in the game’s development? We’ll have to go back and change all those values of 150 to the new value — manually.

You don’t have to optimise every single piece of code. Concentrate on the slowest ones.

###Links

There are a lot of quirks to memorise. For instance, value = value / 5 is much slower than value = value * 0.2. Fortunately, a number of awesome people in the community have already listed these:

– ActionScript 3 Optimization Techniques (PDF) by Joa Ebert
– Quick as a Flash by Grant Skinner (this is a presentation; click it, then press left and right to move through the slides).
– Code Optimization category of ActionScript Wiki, also run by Joa Ebert
– Tips on How To Write Efficient AS3 by Shane McCartney
– AS3 Speed Tests, a community-maintained page which itself contains links to yet more lists

If you want to run your own tests (and you should), check out Grant Skinner’s AS3 Performance Testing Harness. Lee Brimelow posted a screencast explaining how to use it here.

Got any tips, techniques or links that I’ve missed? Stick them in the comments 🙂

Tagged as: coding, optimisation, performance, speed