Apr 18, 2012
Posted on Apr 18, 2012 in Hints and Tips | 10 comments
Bitwise operators are those strange looking operators that may look hard to understand… but not any more! This easy to follow article will help you understand what they are and how to use them, with a couple of practical examples as well to show you when and why you’d need them.
Introduction
Bitwise operators are operators (just like +, *, &&, etc.) that operate on ints and uints at the binary level. This means they look directly at the binary digits or bits of an integer. This all sounds scary, but in truth bitwise operators are quite easy to use and also quite useful!
It is important, though, that you have an understanding of binary numbers and hexadecimal numbers. If you don’t, please check out this article – it will really help you! Below is a little application that will let you try out the different bitwise operators.
Don’t worry if you don’t understand what is going on yet, it will all be clear soon…
Recognizing the Bitwise Operators
Let’s take a look at the bitwise operators that AS3 supplies. Many other languages are quite similar (for example, JavaScript and Java have practically identical operators):
- & (bitwise AND)
- | (bitwise OR)
- ~ (bitwise NOT)
- ^ (bitwise XOR)
- << (bitwise left shift)
- >> (bitwise right shift)
- >>> (bitwise unsigned right shift)
- &= (bitwise AND assignment)
- |= (bitwise OR assignment)
- ^= (bitwise XOR assignment)
- <<= (bitwise left shift and assignment)
- >>= (bitwise right shift and assignment)
- >>>= (bitwise unsigned right shift and assignment)
There are a couple of things you should take from this: First, some bitwise operators look similar to operators you’ve used before (& vs. &&, | vs. ||). This is because they are somewhat similar.
Second, most bitwise operators come with a compound assignment form of themselves. This is the same as how you can use + and +=, – and -=, etc.
The & Operator
Up first: the bitwise AND operator, &. A quick heads-up though: normally, ints and uints take up 4 bytes or 32 bits of space. This means each int or uint is stored as 32 binary digits. For the sake of this tutorial, we’ll pretend sometimes that ints and uints only take up 1 byte and only have 8 binary digits.
The & operator compares each binary digit of two integers and returns a new integer, with a 1 wherever both numbers had a 1 and a 0 anywhere else. A diagram is worth a thousand words, so here’s one to clear things up. It represents doing 37 & 23, which equals 5.
Notice how each binary digit of 37 and 23 are compared, and the result has a 1 wherever both 37 and 23 had a 1, and the result has a 0 otherwise.
A common way of thinking about binary digits is as true or false. That is, 1 is equivalent to true and 0 is equivalent to false. This makes the & operator make more sense.
When we compare two booleans, we normally do boolean1 && boolean2. That expression is only true if both boolean1 and boolean2 are true. In the same way, integer1 & integer2 is equivalent, as the & operator only outputs a 1 when both binary digits of our two integers are 1.
Here’s a table that represents that idea:
A neat little use of the & operator is to check whether a number is even or odd. For integers we can simply check the rightmost bit (also called the least significant bit) to determine if the integer is odd or even. This is because when converting to base 10, the rightmost bit represents 20 or 1. When the rightmost bit is 1, we know that our number is odd since we’re adding 1 to a bunch of powers of two which will always be even. When the rightmost bit is 0, we know our number will be even, since it simply consists of adding up a bunch of even numbers.
Here’s an example:
var randInt:int = int(Math.random()*1000);
if(randInt & 1)
{
trace("Odd number.");
}
else
{
trace("Even number.");
}
On my computer, this method was about 66% faster than using randInt % 2 to check for even and odd numbers. That’s quite a performance boost!
The | Operator
Up next is the bitwise OR operator, |. As you may have guessed, the | operator is to the || operator as the & operator is to the && operator. The | operator compares each binary digit across two integers and gives back a 1 if either of them are 1. Again, this is similar to the || operator with booleans.
Let’s take a look at the same example as before, except now using the | operator instead of the & operator. We’re now doing 37 | 23 which equals 55:
Flags: A Use of the & and | Operators
We can take advantage of the & and | operators to allow us to pass multiple options to a function in a single int.
Let’s take a look at a possible situation. We’re building a pop-up window class. At the bottom of it, we can have a Yes, No, Okay, or Cancel button or any combination of those – how should we do this? Here’s the hard way:
public class PopupWindow extends Sprite
{
// Variables, Constructor, etc...
public static void showPopup(yesButton:Boolean, noButton:Boolean, okayButton:Boolean, cancelButton:Boolean)
{
if(yesButton)
{
// add YES button
}
if(noButton)
{
// add NO Button
}
// and so on for the rest of the buttons
}
}
Is this horrible? No. But it is bad, if you’re a programmer, to have to look up the order of arguments every time you call the function. It’s also annoying – for example, if you only want to show the Cancel button, you have to set all the other Booleans to false.
Let’s use what we learned about & and | to make a better solution:
public class PopupWindow extends Sprite
{
public static const YES:int = 1;
public static const NO:int = 2;
public static const OKAY:int = 4;
public static const CANCEL:int = 8;
public static void showPopup(buttons:int)
{
if(buttons & YES)
{
// add YES button
}
if(buttons & NO)
{
// add NO button
}
}
}
How would a programmer call the function so the Yes button, No button, and Cancel button are showing? Like this:
PopupWindow.show(PopupWindow.YES | PopupWindow.NO | PopupWindow.CANCEL);
What’s going on? It’s important to note that our constants in the second example are all powers of two. So, if we look at their binary forms, we will notice they all have one digit equal to 1, and the rest equal to 0. In fact, they each have a different digit equal to 1. This means that no matter how we combine them with |, every combination will give us a unique number. Looking at it in a different way, out result of our | statement will be a binary number with a 1 wherever our options had a 1.
For our current example we have PopupWindow.YES | PopupWindow.NO | PopupWindow.CANCEL which is equivalent to 1 | 2 | 8 which rewritten in binary is 00000001 | 00000010 | 00001000 which gives us a result of 00001011.
Now, in our showPopup() function, we use & to check which options were passed in. For example, when we check buttons & YES, all the bits in YES are equal to 0 except the very rightmost one. So, we are essentially checking if the rightmost bit in buttons is a 1 or not. If it is, buttons & YES will not equal 0 and anything in the if statement will be executed. Conversely, if the rightmost bit in buttons is 0, buttons & YES will equal 0, and the if statement will not be executed.
The ~ Operator
The bitwise NOT operator is slightly different than the two we’ve looked at so far. Instead of taking an integer on each side of it, it takes an integer only after it. This is just like the ! operator, and, not surprisingly, it does a similar thing. In fact, just as ! flips a boolean from true to false or vice versa, the ~ operator reverses each binary digit in an integer: from 0 to 1 and 1 to 0:
A quick example. Say we have the integer 37, or 00100101. ~37 is then 11011010. What’s the base 10 value of this? Well…
Two’s Complement, uint vs. int, and More!
Now the fun begins! We’re going to take a closer look at binary numbers on a computer. Let’s start with the uint. As mentioned before, a uint is typically 4 bytes or 32 bits long, meaning it has 32 binary digits. This is easy to understand: to get the base 10 value we simply convert the number to base 10 regularly. We’ll always get a positive number.
But how about the int? It also uses 32 bits, but how does it store negative numbers? If you guessed that the first digit is used to store the sign, you’re on the right path. Let’s take a look at the two’s complement system for storing binary numbers. While we won’t go into all the details here, a two’s complement system is used because it makes binary arithmetic easy.
To find the two’s complement of a binary number, we simply flip all the bits (i.e. do what the ~ operator does) and add one to the result. Let’s try this out once:
We then define our result as the value -37. Why do this complicated process and not just flip the very first bit and call that -37?
Well, let’s take a simple expression 37 + -37. We all know this should equal 0, and when we add the 37 to its two’s complement, that’s what we get:
Notice that since our integers only hold eight binary digits, the 1 in our result is dropped, and we end up with 0, as we should.
To recap, to find the negative of a number, we simply take its two’s complement. We can do this by inverting all the bits and adding one.
Want to try this yourself? Add trace(~37+1); to an AS3 file, then compile and run it. You’ll see -37 is printed, as it should be.
There is also a little shortcut to do this by hand: starting from the right, work to the left until you reach a 1. Flip all the bits to the left of this first 1.
When we’re looking at a signed binary number (in other words, one that can be negative, an int not a uint), we can look at the leftmost digit to tell whether it’s negative or positive. If it’s a 0, then the number is positive and we can convert to base 10 simply by calculating its base 10 value. If the leftmost bit is a 1, then the number is negative, so we take the two’s complement of the number to get its positive value and then simply add a negative sign.
For example, if we have 11110010, we know it is a negative number. We can find it’s two’s complement by flipping all the digits to the left of the rightmost 1, giving us 00001110. This equals 13, so we know 11110010 equals -13.
The ^ Operator
We’re back to the bitwise operators, and up next is the bitwise XOR operator. There is no equivalent boolean operator to this one.
The ^ operator is similar to the & and | operators in that it takes an int or uint on both sides. When it is calculating the resulting number, it again compares the binary digits of these numbers. If one or the other is a 1, it will insert a 1 in to the result, otherwise it will insert a 0. This is where the name XOR, or “exclusive or” comes from.
Let’s take a look at our usual example:
The ^ operator does have uses – it’s especially good for toggling binary digits – but we won’t cover any practical applications in this article.
The << Operator
We’re now on the bitshift operators, specifically the bitwise left shift operator here.
These work a little differently than before. Instead of comparing two integers like &, |, and ^ did, these operators shift an integer. On the left side of the operator is the integer that is being shifted, and on the right is how much to shift by. So, for example, 37 << 3 is shifting the number 37 to the left by 3 places. Of course, we’re working with the binary representation of 37.
Let’s take a look at this example (remember, we’re just going to pretend integers only have 8 bits instead of 32). Here we have the number 37 sitting on its nice block of memory 8 bits wide.
Alright, let’s slide all the digits over to the left by 3, as 37 << 3 would do:
But now we have a small problem – what do we do with the 3 open bits of memory where we moved the digits from?
Of course! Any empty spots are just replaced with 0s. We end up with 00101000 . And that’s all there is to the left bitshift. Keep in mind that Flash always thinks the result of a left bitshift is an int, not a uint. So if you need a uint for some reason, you’ll have to cast it to a uint like this: uint(37 << 3). This casting doesn’t actually change any of the binary information, just how Flash interprets it (the whole two’s complement thing).
An interesting feature of the left bitshift is that it is the same as multiplying a number by two to the shiftAmount-th power. So, 37 << 3 == 37 * Math.pow(2,3) == 37 * 8. If you can use the left shift instead of Math.pow, you’ll see a huge performance increase.
You may have noticed that the binary number we ended up with did not equal 37 * 8. This is just from our use of only 8 bits of memory for integers; if you try it in ActionScript, you’ll get the correct result. Or, try it with the demo at the top of the page!
The >> Operator
Now that we understand the left bitshift, the next one, the right bitshift, will be easy. Everything slides to the right the amount we specify. The only slight difference is what the empty bits get filled with.
If we’re starting with a negative number (a binary number where the leftmost bit is a 1), all the empty spaces are filled with a 1. If we’re starting with a positive number (where the leftmost bit, or most significant bit, is a 0), then all the empty spaces are filled with a 0. Again, this all goes back to two’s complement.
While this sounds complicated, it basically just preserves the sign of the number we start with. So -8 >> 2 == -2 while 8 >> 2 == 2. I’d recommend trying those out on paper yourself.
Since >> is the opposite of <<, it’s not surprising that shifting a number to the right is the same as dividing it by 2 to the power of shiftAmount. You may have noticed this from the example above. Again, if you can use this to avoid calling Math.pow, you’ll get a significant performance boost.
The >>> Operator
Our final bitwise operator is the bitwise unsigned right shift. This is very similar to the regular bitwise right shift, except that all empty bits on the left are filled with 0s. This means the result of this operator is always a positive integer and it always treats the integer being shifted as an unsigned integer. We won’t run through an example of this in this section, but we’ll see a use for it very shortly.
Using Bitwise Operators to Work With Colors
One of the most practical uses of bitwise operators in Actionscript 3 is working with colors, which are stored typically as uints.
The standard format for colors is to write them in hexadecimal: 0xAARRGGBB – each letter represents a hexadecimal digit. Here, the first two hexadecimal digits, which are equivalent to the first eight binary digits, represent our alpha, or transparency. The next eight bits represent the amount of red in our color (so an integer from 0 to 255), the next eight the amount of green, and the final eight represent the amount of blue in our color.
Without bitwise operators, it’s extremely difficult to work with colors in this format – but with them it’s easy!
Challenge 1: Find the amount of blue in a color: Using the & operator, try to find the amount of blue in an arbitrary color.
public function findBlueComponent(color:uint):uint
{
// Your code here!
}
We need a way to ‘erase’ or mask all the other data in color and just have the blue component left. This is easy, actually! If we take color & 0x000000FF – or, written more simply, color & 0xFF – we end up with only the blue component.
As you can see from above and you learned in the description of the & operator, any binary digit & 0 will always equal 0, while any binary digit & 1 will keep its value. So if we mask our color by 0xFF which only has 1s where the blue component of our color is located, we end up with just the blue component.
Challenge 2: Find the amount of red in a color: Using two bitwise operators, try to find the amount of red in an arbitrary color.
public function findRedComponent(color:uint):uint
{
// Your code here!
}
We actually have two solutions to this problem. One would be return (color & 0xFF0000) >> 16; and the other would be return (color >> 16) & 0xFF;
This is very similar to Challenge 1, except that we have to shift our answer at some point.
Challenge 3: Find the transparency of a color: Using only one bitwise operator, try to find the alpha of a color (an integer from 0 to 255).
public function findAlphaComponent(color:uint):uint
{
// Your code here!
}
This one is a touch trickier. We have to be careful with which right shift operater we choose. Because we’re working with the leftmost digits of a uint, we want to use >>> operator. So, our answer simply is return color >>> 24;.
Final Challenge: Create a color from its components: Using the << and | operators, take the components of a color and merge them in to one uint.
public function createColor(a:uint, r:uint, g:uint, b:uint):uint
{
// Your code here!
}
Here, we have to shift each component to its correct position, and then merge them. We want Flash to treat it as an unsigned integer, so we cast it to a uint: return uint((a << 24) | (r << 16) | (g << 
| b);
Compound Operators
You may have noticed I have neglected to explain the compound bitwise operators. Imagine we have an integer x. Then, x = x & 0xFF is the same as x &= 0xFF, x = x | 256 is the same as x |= 256, and so on for the rest of the compound operators.
Conclusion
Thanks for reading this article! I hope you now understand bitwise operators and can utilize them in your AS3 code (or in many other languages!). As always, if you have any questions or comments, please leave them below.
View full post on Activetuts+
Apr 17, 2012
Posted on Apr 17, 2012 in Hints and Tips | 10 comments
This week, Matt Porter gives us a detailed rundown of a fast-paced arcade Flash jump-and-run game: Survival Lab, developed by Beast Games.
Overview
There is a small number of arcade style platformers that I find truly enjoyable, and Survival Lab is among those few. It includes the greatness that is platforming, the addictiveness of RPGs, and even the prospect of awesome boss battles. It may have its flaws, but Survival Lab is one brilliantly put together game.
Gameplay
The gameplay is simple: you’re put into an arena (single screen size), and you must survive. You need to dodge bullets, homing missiles, buzz saws, lasers, etc. These objects are all introduced as you survive longer, as things get more hectic. You collect coins that spawn randomly to gain experience points and level up, and these points can be spent on purchasing upgrades such as the ability to double jump, or greater defense.
What Survival Lab does right, that most games of this nature would fail at, is to give you decent controls from the start. Generally, when movement is tweaked via upgrades, developers make the mistake of hindering the initial controls, and returning them to normal via upgrades – this is a huge mistake, and often drives players away. If you’re going to tweak the core mechanics, you must make them good from the start, and even better after upgrades, rather than horrible to start with, and normal after upgrades.
The greatest strength of Survival Lab, is that it creates a full fledged game out of very little. There’s not much to the game, yet it’s greatly enjoyable. The game takes place in a single room, with just one boss, yet you have a ton of fun throughout the entire game. It’s extremely hard to come up with a mechanic that will work in such a way, but Survival Lab pulls it off. The most profitable Flash games for developers, are games such as this. You have a simple mechanic, easy to program, and you go all the way with it. Your programming is relatively simple, the game is relatively easy to plan, and the art assets are extremely minimal – which is a major cost saver. With far less work than the average Flash game, Survival Lab accomplishes more than most.
While the game may seem too simple to be successful, it’s exactly this that makes it so popular. The RPG level-up elements keep players addicted, and the simple yet enjoyable gameplay lets virtually anyone enjoy playing. The spaced check-points give the player reward feedback at a decent pace, and are constantly giving the player a noticeable sense of progression. Backgrounds change as levels go on, and this too contributes to the sense of accomplishment.
There’s also a neat combo system in place that is achieved by collecting coins without getting hit. This system does have a flaw in that the combo is reset if you miss any coin (even if you get another that spawned before one disappears), while one would think (and visually feel) that the combo would remain as long as any coin is collected. Either way, this system is a great addition to the game, and helps keep players busy. Rewarding the player is an absolute must for casual web games, and Survival Lab hits almost all the sweet spots.
What Survival Lab lacks is variety. The game is extremely short, and some places stay rather bland, which causes certain mechanics to be abused, or used too often. For instance, the ground terrain of the arena never changes, ever. Since there’s only one arena, and that arena is never physically changing, the few mechanics there are end up being used a bit too much. Bottomless pits, fireballs hopping out of lava, and everything in between, would all be greatly welcomed.
The other biggest flaw of Survival Lab is its lackluster ending. The final boss is an absolute pushover; he’s in every possible way too easy. I played the game again before writing this, and was able to beat him within five seconds on my second try (on the first attempt I was low on health from previous levels). This anti-climactic finish really sticks to players, and can actually backfire on a great game to cause low ratings. A player who may have only played half the game, and voted a 5/5, may finish the game, be annoyed at the ending, and vote a much lower score. It’s extremely important that you please your players all the way through, or that sudden disappointment may result in slightly irrational low ratings.
Graphics
The graphics are quite charming in Survival Lab, and are very well done. There’s not much to them, but what there is, is consistent in style, and pleases the eye. The backgrounds have a bit of polish, as they change color as you progress levels, which is a very nice touch. The player animations are very smooth, and some of them make you feel quite awesome, such as the roll.
The main improvement that could be done, would be to add a bit more contrast between objects and the background. With the background changing color, the red background leaves the homing missiles a bit hard to see, and with the yellow, coins quite hard to see. A bit more attention to this would make the game slightly more enjoyable, but it’s a relatively minor flaw.
With the overall simplicity of the game, there really isn’t much more to be done with graphics; they truly are done as should be.
Audio
The audio in Survival Lab is nothing amazing, but it gets the job done. The main track is a bit compressed, especially since the game itself is very small and has room for a bit more file size.
The sound effects are done quite well, and are very fitting. Everything in the game seems to have a sound in place, which is quite uncommon, despite the fact that it should be seen as an absolute necessity.
Conclusion
Survival Lab is, essentially, the perfect Flash game. It’s not the greatest game by any means, but it’s exactly what this industry calls for. It’s quick fun for the players, and quick cash for the developers. It’s simple, easy to create, but quite cost-effective on the developer’s part.
As developers, we can make Flash games as large as we want, but that won’t mean more money. At the end of the day, we’re almost always selling glorified advertisements, and the smaller the game, the more profitable you’ll likely be.
Parting Thought
While the game itself is great, it feels to me a bit too simple. It’s almost as if it ends before it even begins. I personally feel the game would be more enjoyable with multiple arenas, and a boss at the end of each arena. What do you think?
Your Turn
If you’ve got a browser game that you’d like the Activetuts+ community to do a critique on, submit it here. We’re looking forward to seeing what you’ve made.
View full post on Activetuts+
Apr 17, 2012
Posted on Apr 17, 2012 in Hints and Tips | 10 comments
Code optimization aims to maximize the performance of your Flash assets, while using as little of the system’s resources – RAM and CPU – as possible. In this tutorial, starting off with a working but resource-hogging Flash app, we will gradually apply many optimization tweaks to its source code, finally ending up with a faster, leaner SWF.
Final Result Preview
Let’s take a look at the final result we will be working towards:
Note that the “Memory Used” and “CPU Load” stats are based on all the SWFs you have open across all browser windows, including Flash banner ads and the like. This may make the SWF appear more resource intensive than it actually is.
Step 1: Understanding the Flash Movie
The Flash movie has two main elements: a particle simulation of fire, and a graph showing the animation’s resource consumption over time. The graph’s pink line tracks the total memory consumed by the movie in megabytes, and the green line plots CPU load as a percentage.
ActionScript objects take up most of the memory allocated to the Flash Player, and the more ActionScript objects a movie contains, the higher its memory consumption. In order to keep a program’s memory consumption low, the Flash Player regularly does some garbage collection by sweeping through all ActionScript objects and releasing from memory those no longer in use.
A memory consumption graph normally reveals a hilly up-down pattern, dipping each time garbage collection is performed, then slowly rising as new objects are created. A graph line that’s only going up points to a problem with garbage collection, as it means new objects are being added to memory, while none are being removed. If such a trend continues, the Flash player may eventually crash as it runs out of memory.
The CPU load is calculated by tracking the movie’s frame rate. A Flash movie’s frame rate is much like its heartbeat. With each beat, the Flash Player updates and renders all on-screen elements and also runs any required ActionScript tasks.
It is the frame rate that determines how much time Flash Player should spend on each beat, so a frame rate of 10 frames per second (fps) means at least 100 milliseconds per beat. If all the required tasks are performed within that time, then Flash Player will wait for the remaining time to pass before moving on to the next beat. On the other hand, if the required tasks in a particular beat are too CPU intensive to be completed within the given time frame, then the frame rate automatically slows down to allow for some extra time. Once the load lightens, the frame rate speeds up again, back to the set rate.
(The frame rate may also be automatically throttled down to 4fps by the Flash Player when the program’s parent window looses focus or goes offscreen. This is done to conserve system resources whenever the user’s attention is focused elsewhere.)
What this all means is that there are actually two kinds of frame rates: the one you originally set and hope your movie always runs at, and the one it actually runs at. We’ll call the one set by you the target frame rate, and the one it actually runs at the actual frame rate.
The graph’s CPU load is calculated as a ratio of actual to target frame rate. The formula used to calculate this is:
CPU load = ( target frame rate - actual frame rate ) / actual frame rate * 100
For example, if the target frame rate is set to 50fps but the movie actually runs at 25fps, the CPU load will be 50% – that is, ( 50 - 25 )/ 50 * 100.
Please note that this is not the actual percentage of system CPU resources used by the running movie, but rather a rough estimate of the actual value. For the optimization process outlined here, this estimate is a good enough metric for the task at hand. To get the actual CPU usage, use the tools provided by your operating system, e.g. the Task Manager in Windows. Looking at mine it right now, it shows the unoptimized movie is using 53% of CPU resources, while the movie’s graph shows a CPU load of 41.7%.
PLEASE NOTE: All the movie screenshots in this tutorial were taken from the standalone version of Flash Player. The graph will most likely show different numbers on your system, depending on your operating system, browser, and Flash Player version. Having any other currently running Flash apps in different browser windows or flash players may also affect the memory use reported by some systems. When analyzing the perfomance of your program, always ensure that no other Flash programs are running as they may corrupt your metrics.
With the CPU load, expect it to shoot up to over 90% whenever the movie goes off screen – for example if you switch to another browser tab or scroll down the page. The lower frame rate that causes this will not be caused by CPU intensive tasks, but by Flash throttling down the frame rate whenever you look elsewhere. Whenever this happens, wait a few seconds for the CPU load graph to settle to its proper CPU load values after the normal frame rate kicks in.
Step 2: Does This Code Make My Flash Look Fat?
The movie’s source code is shown below and contains just one class, named Flames, which is also the document class. The class contains a set of properties to keep track of the movie’s memory and CPU load history, which is then used to draw a graph. The memory and CPU load statistics are calculated and updated in the Flames.getStats() method, and the graph is drawn by calling Flames.drawGraph() on each frame. To create the fire effect, the Flames.createParticles() method first generates hundreds of particles each second, which are stored in the fireParticles array. This array is then looped through by Flames.drawParticles() , which uses each particle’s properties to create the effect.
Take some time to study the Flames class. Can you already spot any quick changes that will go a long way in optimizing the program?
package com.pjtops{
import flash.display.MovieClip;
import flash.events.Event;
import fl.motion.Color;
import flash.geom.Point;
import flash.geom.Rectangle;
import flash.text.TextField;
import flash.system.System;
import flash.utils.getTimer;
public class Flames extends MovieClip{
private var memoryLog = new Array(); // stores System.totalMemory values for display in the graph
private var memoryMax = 0; // the highest value of System.totalMemory recorded so far
private var memoryMin = 0; // the lowest value of System.totalMemory recorded so far
private var memoryColor; // the color used by text displaying memory info
private var ticks = 0; // counts the number of times getStats() is called before the next frame rate value is set
private var frameRate = 0; //the original frame rate value as set in Adobe Flash
private var cpuLog = new Array(); // stores cpu values for display in the graph
private var cpuMax = 0; // the highest cpu value recorded so far
private var cpuMin = 0; // the lowest cpu value recorded so far
private var cpuColor; // the color used by text displaying cpu
private var cpu; // the current calculated cpu use
private var lastUpdate = 0; // the last time the framerate was calculated
private var sampleSize = 30; // the length of memoryLog & cpuLog
private var graphHeight;
private var graphWidth;
private var fireParticles = new Array(); // stores all active flame particles
private var fireMC = new MovieClip(); // the canvas for drawing the flames
private var palette = new Array(); // stores all available colors for the flame particles
private var anchors = new Array(); // stores horizontal points along fireMC which act like magnets to the particles
private var frame; // the movieclips bounding box
// class constructor. Set up all the events, timers and objects
public function Flames() {
addChildAt( fireMC, 1 );
frame = new Rectangle( 2, 2, stage.stageWidth - 2, stage.stageHeight - 2 );
var colWidth = Math.floor( frame.width / 10 );
for( var i = 0; i < 10; i++ ){
anchors[i] = Math.floor( i * colWidth );
}
setPalette();
memoryColor = memoryTF.textColor;
cpuColor = cpuTF.textColor;
graphHeight = graphMC.height;
graphWidth = graphMC.width;
frameRate = stage.frameRate;
addEventListener( Event.ENTER_FRAME, drawParticles );
addEventListener( Event.ENTER_FRAME, getStats );
addEventListener( Event.ENTER_FRAME, drawGraph );
}
//creates a collection of colors for the flame particles, and stores them in palette
private function setPalette(){
var black = 0x000000;
var blue = 0x0000FF;
var red = 0xFF0000;
var orange = 0xFF7F00;
var yellow = 0xFFFF00;
var white = 0xFFFFFF;
palette = palette.concat( getColorRange( black, blue, 10 ) );
palette = palette.concat( getColorRange( blue, red, 30 ) );
palette = palette.concat( getColorRange( red, orange, 20 ) );
palette = palette.concat( getColorRange( orange, yellow, 20 ) );
palette = palette.concat( getColorRange( yellow, white, 20 ) );
}
//returns a collection of colors, made from different mixes of color1 and color2
private function getColorRange( color1, color2, steps){
var output = new Array();
for( var i = 0; i < steps; i++ ){
var progress = i / steps;
var color = Color.interpolateColor( color1, color2, progress );
output.push( color );
}
return output;
}
// calculates statistics for the current state of the application, in terms of memory used and the cpu %
private function getStats( event ){
ticks++;
var now = getTimer();
if( now - lastUpdate < 1000 ){
return;
}else {
lastUpdate = now;
}
cpu = 100 - ticks / frameRate * 100;
cpuLog.push( cpu );
ticks = 0;
cpuTF.text = cpu.toFixed(1) + '%';
if( cpu > cpuMax ){
cpuMax = cpu;
cpuMaxTF.text = cpuTF.text;
}
if( cpu < cpuMin || cpuMin == 0 ){
cpuMin = cpu;
cpuMinTF.text = cpuTF.text;
}
var memory = System.totalMemory / 1000000;
memoryLog.push( memory );
memoryTF.text = String( memory.toFixed(1) ) + 'mb';
if( memory > memoryMax ){
memoryMax = memory;
memoryMaxTF.text = memoryTF.text;
}
if( memory < memoryMin || memoryMin == 0 ){
memoryMin = memory;
memoryMinTF.text = memoryTF.text;
}
}
//render's a graph on screen, that shows trends in the applications frame rate and memory consumption
private function drawGraph( event ){
graphMC.graphics.clear();
var ypoint, xpoint;
var logSize = memoryLog.length;
if( logSize > sampleSize ){
memoryLog.shift();
cpuLog.shift();
logSize = sampleSize;
}
var widthRatio = graphMC.width / logSize;
graphMC.graphics.lineStyle( 3, memoryColor, 0.9 );
var memoryRange = memoryMax - memoryMin;
for( var i = 0; i < memoryLog.length; i++ ){
ypoint = ( memoryLog[i] - memoryMin ) / memoryRange * graphHeight;
xpoint = (i / sampleSize) * graphWidth;
if( i == 0 ){
graphMC.graphics.moveTo( xpoint, -ypoint );
continue;
}
graphMC.graphics.lineTo( xpoint, -ypoint );
}
graphMC.graphics.lineStyle( 3, cpuColor, 0.9 );
for( var j = 0; j < cpuLog.length; j++ ){
ypoint = cpuLog[j] / 100 * graphHeight;
xpoint = ( j / sampleSize ) * graphWidth;
if( j == 0 ){
graphMC.graphics.moveTo( xpoint, -ypoint );
continue;
}
graphMC.graphics.lineTo( xpoint, -ypoint );
}
}
//renders each flame particle and updates it's values
private function drawParticles( event ) {
createParticles( 20 );
fireMC.graphics.clear();
for ( var i in fireParticles ) {
var particle = fireParticles[i];
if (particle.life == 0 ) {
delete( fireParticles[i] );
continue;
}
var size = Math.floor( particle.size * particle.life/100 );
var color = palette[ particle.life ];
var transperency = 0.3;
if( size < 3 ){
size *= 3;
color = 0x333333;
particle.x += Math.random() * 8 - 4;
particle.y -= 2;
transperency = 0.2;
}else {
particle.y = frame.bottom - ( 100 - particle.life );
if( particle.life > 90 ){
size *= 1.5;
}else if( particle.life > 45){
particle.x += Math.floor( Math.random() * 6 - 3 );
size *= 1.2;
}else {
transperency = 0.1;
size *= 0.3;
particle.x += Math.floor( Math.random() * 4 - 2 );
}
}
fireMC.graphics.lineStyle( 5, color, 0.1 );
fireMC.graphics.beginFill( color, transperency );
fireMC.graphics.drawCircle( particle.x, particle.y, size );
fireMC.graphics.endFill();
particle.life--;
}
}
//generates flame particle objects
private function createParticles( count ){
var anchorPoint = 0;
for(var i = 0; i < count; i++){
var particle = new Object();
particle.x = Math.floor( Math.random() * frame.width / 10 ) + anchors[anchorPoint];
particle.y = frame.bottom;
particle.life = 70 + Math.floor( Math.random() * 30 );
particle.size = 5 + Math.floor( Math.random() * 10 );
fireParticles.push( particle );
if(particle.size > 12){
particle.size = 10;
}
particle.anchor = anchors[anchorPoint] + Math.floor( Math.random() * 5 );
anchorPoint = (anchorPoint == 9)? 0 : anchorPoint + 1;
}
}
}
}
It’s a lot to take in, so don’t worry – we’ll go through the various improvements in the rest of this tutorial.
Step 3: Use Strong Typing by Assigning Data Types to All Variables
The first change we’ll make to the class is to specify the data type of all declared variables, method parameters, and method return values.
For example, changing this
protected var memoryLog = new Array();
protected var memoryMax = 0; // yes, but what exactly are you?
to this.
protected var memoryLog:Array = new Array();
protected var memoryMax:Number = 0; // memoryMax the Number, much better!
Whenever declaring variables, always specify the data type, as this allows the Flash compiler to perform some extra optimizations when generating the SWF file. This alone can lead to big performance improvements, as we’ll soon see with our example. Another added benefit of strong typing is that the compiler will catch and alert you of any data-type related bugs.
Step 4: Examine Results
This screen shot shows the new Flash movie, after applying strong typing. We can see that while it’s had no effect on the current or maximum CPU load, the minimum value has dropped from 8.3% to 4.2%. The maximum memory consumed has gone down from 9MB to 8.7MB.
The slope of the graph’s memory line has also changed, compared to the one shown in Step 2. It still has the same jagged pattern, but now drops and rises at a slower rate. This is a good thing, if you consider that the sudden drops in memory consumption are caused by Flash Player’s garbage collection, which is usually triggered when allocated memory is about to run out. This garbage collection can be an expensive operation, since Flash Player has to traverse through all the objects, looking for those that are no longer needed but still taking up memory. The less often it has to do this, the better.
Step 5: Efficiently Store Numeric Data
Actionscript provides three numeric data types: Number , uint and int . Of the three types, Number consumes the most memory as it can store larger numeric values than the other two. It is also the only type able to store numbers with decimal fractions.
The Flames class has many numeric properties, all of which use the Number data type. As int and uint are more compact data types, we can save some memory by using them instead of Numbers in all situations where we don’t need decimal fractions.
A good example is in loops and Array indexes, so for example we are going to change
for( var i:Number = 0; i < 10; i++ ){
anchors[i] = Math.floor( i * colWidth );
}
into
for( var i:int = 0; i < 10; i++ ){
anchors[i] = Math.floor( i * colWidth );
}
The properties cpu , cpuMax and memoryMax will remain Numbers, as they will most likely store fractional data, while memoryColor , cpuColor and ticks can be changed to uints, as they will always store positive, whole numbers.
Step 6: Minimize Method Calls
Method calls are expensive, especially calling a method from a different class. It gets worse if that class belongs to a different package, or is a static method. The best example here is the Math.floor() method, used throughout the Flames class to roundoff fractional numbers. This method call can be avoided by using uints instead of Numbers to store whole numbers.
// So instead of having:
anchors[i] = Math.floor( i * colWidth );
// we instead cast the value to a uint
anchors[i] = uint( i * colWidth );
// The same optimization can be performed by simply assigning the uint data type, for example changing
var size:uint = Math.floor( particle.size * particle.life/100 );
// into
var size:uint = particle.size * particle.life/100;
In the example above, the call to Math.floor() is unnecessary, since Flash will automatically round off any fractional number value assigned to a uint.
Step 7: Multiplication Is Faster Than Division
Flash Player apparently finds multiplication easier than division, so we’ll go through the Flames class and convert any division math into the equivalent multiplication math. The conversion formula involves getting the reciprocal of the number on the right side of the operation, and multiplying it with the number on the left. The reciprocal of a number is calculated by dividing 1 by that number.
var colWidth:uint = frame.width / 10; //division by ten
var colWidth:uint = frame.width * 0.1; //produces the same result as multiplication by 0.1
Lets take a quick look at the results of our recent optimization efforts. The CPU load has finally improved by dropping from 41.7% to 37.5%, but the memory consumption tells a different story. Maximum memory has risen to 9.4MB, the highest level yet, and the graph’s sharp, saw-tooth edges shows that garbage collection is being run more often again. Some optimization techniques will have this inverse effect on memory and CPU load, improving one at the expense of the other. With memory consumption almost back to square one, a lot more work still needs to be done.
Step 8: Recycling Is Good for the Environment
You too can play your part in saving the environment. Recycle your objects when writing your AS3 code reduce the amount of energy consumed by your programs. Both the creation and destruction of new objects are expensive operations. If your program is constantly creating and destroying objects of the same type, big performance gains can be achieved by recycling those objects instead. Looking at the Flames class, we can see that a lot of particle objects are being created and destroyed every second:
private function drawParticles( event ):void {
createParticles( 20 );
fireMC.graphics.clear();
for ( var i:* in fireParticles ) {
var particle:Object = fireParticles[i];
if (particle.life == 0 ) {
delete( fireParticles[i] );
continue;
}
There are many ways to recycle objects, most involve creating a second variable to store unneeded objects instead of deleting them. Then when a new object of the same type is required, it is retrieved from the store instead of creating a new one. New objects are only created when the store is empty. We are going to do something similar with the particle objects of the Flames class.
First, we create a new array called inactiveFireParticles[] , which stores references to particles whose life property is zero (dead particles). In the drawParticles() method, instead of deleting a dead particle, we add it to the inactiveFireParticles[] array.
private function drawParticles( event ):void {
createParticles( 20 );
fireMC.graphics.clear();
for ( var i:* in fireParticles ) {
var particle:Object = fireParticles[i];
if( particle.life <= 0 ) {
if( particle.life == 0 ){
particle.life = -1;
inactiveFireParticles.push( particle );
}
continue;
}
Next, we modify the createParticles() method to first check for any stored particles in the inactiveFireParticles[] array, and use them all before creating any new particles.
private function createParticles( count ):void{
var anchorPoint = 0;
for(var i:uint = 0; i < count; i++){
var particle:Object;
if( inactiveFireParticles.length > 0 ){
particle = inactiveFireParticles.shift();
}else {
particle = new Object();
fireParticles.push( particle );
}
particle.x = uint( Math.random() * frame.width * 0.1 ) + anchors[anchorPoint];
particle.y = frame.bottom;
particle.life = 70 + uint( Math.random() * 30 );
particle.size = 5 + uint( Math.random() * 10 );
if(particle.size > 12){
particle.size = 10;
}
particle.anchor = anchors[anchorPoint] + uint( Math.random() * 5 );
anchorPoint = (anchorPoint == 9)? 0 : anchorPoint + 1;
}
}
Step 9: Use Object and Array Literals Whenever Possible
When creating new objects or arrays, using the literal syntax is faster than using the new operator.
private var memoryLog:Array = new Array(); // array created using the new operator
private var memoryLog:Array = []; // array created using the faster array literal
particle = new Object(); // object created using the new operator
particle = {}; // object created using the faster object literal
Step 10: Avoid Using Dynamic Classes
Classes in ActionScript can either be sealed or dynamic. They’re sealed by default, meaning the only properties and methods an object derived from it can have must have been defined in the class. With dynamic classes, new properties and methods can be added at runtime. Sealed classes are more efficient than dynamic classes, because some Flash Player performance optimizations can be done when all the possible functionality that a class can ever have are known beforehand.
Within the Flames class, the thousands of particles extend the built-in Object class, which is dynamic. Since no new properties need to be added to a particle at runtime, we’ll save up more resources by creating a custom sealed class for the particles.
Here is the new Particle, which has been added to the same Flames.as file.
class Particle{
public var x:uint;
public var y:uint;
public var life:int;
public var size:Number;
public var anchor:uint;
}
The createParticles () method will also be adjusted, changing the line
var particle:Object;
particle = {};
to instead read:
var particle:Particle;
particle = new Particle();
Step 11: Use Sprites When You Don’t Need the Timeline
Like the Object class, MovieClips are dynamic classes. The MovieClip class inherits from the Sprite class, and the main difference between the two is that MovieClip has a timeline. Since Sprites have all the functionality of MovieClips minus the timeline, use them whenever you need a DisplayObject that does not need the timeline. The Flames class extends the MovieClip but it does not use the timeline, as all its animation is controlled through ActionScript. The fire particles are drawn on fireMC , which is also a MovieClip that does not make use of its timeline.
We change both Flames and fireMC to extend Sprite instead, replacing:
import flash.display.MovieClip;
private var fireMC:MovieClip = new MovieClip();
public class Flames extends MovieClip{
with
import flash.display.Sprite;
private var fireMC:Sprite = new Sprite();
public class Flames extends Sprite{
Step 12: Use Shapes Instead of Sprites When You Don’t Need Child Display Objects or Mouse Input
The Shape class is even lighter than the Sprite class, but it cannot support mouse events or contain child display objects. As the fireMC requires none of this functionality, we can safely turn it into a Shape.
import flash.display.Shape;
private var fireMC:Shape = new Shape();
The graph shows big improvements in memory consumption, with it dropping and remaining stable at 4.8MB. The saw-tooth edges have been replaced by an almost straight horizontal line, meaning garbage collection is now rarely run. But the CPU load has mostly gone back again to its original high level of 41.7%.
Step 13: Avoid Complex Calculations Inside Loops
They say over 50% of a program’s time is spent running 10% of its code, and most of that 10% is most likely to be taken up by loops. Many loop optimization techniques involve placing as much of the CPU intensive operations outside the body of a loop. These operations include object creation, variable lookups and calculations.
for( var i = 0; i < memoryLog.length; i++ ){
// loop body
}
The first loop in the drawGraph() method is shown above. The loop runs through every item of the memoryLog array, using each value to plot points on the graph. At the start of each run, it looks up the length of the memoryLog array and compares it with the loop counter. If the memoryLog array has 200 items, the loop runs 200 times, and performs this same lookup 200 times. Since the length of memoryLog does not change, the repeated lookups are wasteful and unnecessary. It’s better to look up the value of memoryLog.length just once before the lookup begins and store it in a local variable, since accessing a local variable will be faster than accessing an object’s property.
var memoryLogLength:uint = memoryLog.length;
for( var i = 0; i < memoryLogLength; i++ ){
// loop body
}
In the Flames class, we adjust the two loops in the drawGraph() method as shown above.
Step 14: Place Conditional Statements Most Likely to Be True First
Consider the block of if..else conditionals below, derived from the drawParticles () method:
if( particle.life > 90 ){ // a range of 10 values, between 91 - 100
size *= 1.5;
}else if( particle.life > 45){ // a range of 45 values, between 46 - 90
particle.x += Math.random() * 6 - 3;
size *= 1.2;
}else { // a range of 45 values, values between 0 - 45
transperency = 0.1;
size *= 0.3;
particle.x += Math.random() * 4 - 2;
}
A particle’s life value can be any number between 0 and 100. The if clause tests whether the current particle’s life is between 91 to 100, and if so it executes the code within that block. The else-if clause tests for a value between 46 and 90, while the else clause takes the remaining values, those between 0 and 45. Considering the first check is also the least likely to succeed as it has the smallest range of numbers, it should be the last condition tested. The block is rewritten as shown below, so that the most likely conditions are evaluated first, making the evaluations more efficient.
if( particle.life < 46 ){
transperency = 0.1;
size *= 0.3;
particle.x += Math.random() * 4 - 2;
}else if( particle.life < 91 ){
particle.x += Math.random() * 6 - 3;
size *= 1.2;
}else {
size *= 1.5;
}
Step 15: Add Elements to the End of an Array Without Pushing
The method Array.push() is used quite a lot in the Flames class. It will be replaced by a faster technique that uses the array’s length property.
cpuLog.push( cpu ); // slow and pretty
cpuLog[ cpuLog.length ] = cpu; // fast and ugly
When we know the length of the array, we can replace Array.push() with an even faster technique, as shown below.
var output:Array = []; //output is a new, empty array. Its length is 0
for( var i:uint = 0; i < steps; i++ ){ // the value of i also starts at zero. Each loop cycle increases both i and output.length by one
var progress:Number = i / steps;
var color:uint = Color.interpolateColor( color1, color2, progress );
output[i] = color; // faster than cpuLog[ cpuLog.length ] = cpu;
}
Step 16: Replace Arrays With Vectors
The Array and Vector classes are very similar, except for two major differences: Vectors can only store objects of the same type, and they’re more efficient and faster than arrays. Since all the arrays in the Flames class either store variables of only one type – ints, uints or Particles, as required – we shall convert them all to Vectors.
These arrays:
private var memoryLog:Array = [];
private var cpuLog:Array = [];
private var fireParticles:Array = [];
private var palette:Array = [];
private var anchors:Array = [];
private var inactiveFireParticles:Array = [];
…are replaced with their Vector equivalents:
private var memoryLog:Vector.<Number> = new Vector.<Number>();
private var cpuLog:Vector.<Number> = new Vector.<Number>();
private var fireParticles:Vector.<Particle> = new Vector.<Particle>();
private var palette:Vector.<uint> = new Vector.<uint>();
private var anchors:Vector.<uint> = new Vector.<uint>();
private var inactiveFireParticles:Vector.<Particle> = new Vector.<Particle>();
Then we modify the getColorRange() method to work with Vectors rather than arrays.
private function getColorRange( color1, color2, steps):Vector.<uint>{
var output:Vector.<uint> = new Vector.<uint>();
for( var i:uint = 0; i < steps; i++ ){
var progress:Number = i / steps;
var color:uint = Color.interpolateColor( color1, color2, progress );
output[i] = color;
}
return output;
}
Step 17: Use the Event Model Sparingly
While very convenient and handy, the AS3 Event Model is built on top of an elaborate setup of event listeners, dispatchers and objects; then there is event propagation and bubbling and much more, all of which a book can be written about. Whenever possible, always call a method directly rather than through the event model.
addEventListener( Event.ENTER_FRAME, drawParticles );
addEventListener( Event.ENTER_FRAME, getStats );
addEventListener( Event.ENTER_FRAME, drawGraph );
The Flames class has three event listeners calling three different methods, and all bound to the ENTER_FRAME event. In this case, we can keep the first event listener and get rid of the other two, then have the drawParticles () method call getStats() , which in turn calls drawGraph() . Alternatively, we can simply create a new method that calls the getStats(), drawGraph() and drawParticles () for us directly, then have just one event listener that’s bound to the new method. The second option is more expensive however, so we’ll stick with the first.
// this line is added before the end of the <code> drawParticles </code>() method
getStats();
// this line is added before the end of the <code> getStats() </code> method
drawGraph();
We also remove the event parameter (which holds the Event object) from both the drawGraph() and getStats() , as they are no longer needed.
Step 18: Disable All Mouse Events for Display Objects That Do Not Need It
Since this Flash animation does not require any user interaction, we can free its display object from dispatching unnecessary mouse events. In the Flames class, we do that by setting its mouseEnabled property to false. We also do the same for all its children by setting the mouseChildren property to false. The following lines are added to the Flames constructor:
mouseEnabled = false;
mouseChildren = false;
Step 19: Use the Graphics.drawPath() Method to Draw Complex Shapes
The Graphics.drawPath() is optimized for performance when drawing complex paths with many lines or curves. In the Flames.drawGraph() method, the CPU load and memory consumption graph lines are both drawn using a combination of Graphics.moveTo() and Graphics.lineTo() methods.
for( var i = 0; i < memoryLogLength; i++ ){
ypoint = ( memoryLog[i] - memoryMin ) / memoryRange * graphHeight;
xpoint = (i / sampleSize) * graphWidth;
if( i == 0 ){
graphMC.graphics.moveTo( xpoint, -ypoint );
continue;
}
graphMC.graphics.lineTo( xpoint, -ypoint );
}
We replace the original drawing methods with calls to Graphics.drawPath(). An added advantage of the revised code below is that we also get to remove the drawing commands from the loops.
var commands:Vector.<int> = new Vector.<int>();
var data:Vector.<Number> = new Vector.<Number>();
for( var i = 0; i < memoryLogLength; i++ ){
ypoint = ( memoryLog[i] - memoryMin ) / memoryRange * graphHeight;
xpoint = (i / sampleSize) * graphWidth;
if( i == 0 ){
data[ data.length ] = xpoint;
data[ data.length ] = -ypoint;
commands[ commands.length ] = 1;
}
data[ data.length ] = xpoint;
data[ data.length ] = -ypoint;
commands[ commands.length ] = 2;
}
graphMC.graphics.drawPath( commands, data );
Step 20: Make the Classes Final
The final attribute specifies that a method cannot be overridden or that a class cannot be extended. It can also make a class run faster, so we’ll make both the Flames and Particle classes final.
Edit: Reader Moko pointed us to this great article by Jackson Dunstan, which remarks that the final keyword does not actually have any effect on performance.
The CPU load is now 33.3%, while the total memory used stays between 4.8 and 5MB. We’ve come a long way from the CPU load of 41.7% and peak memory size of 9MB!
Which brings us to one of the most important decisions to be made in an optimization process: knowing when to stop. If you stop too early, your game or application may perform poorly on low end systems, and if you go too far, your code may get more obfuscated and harder to maintain. With this particular application, the animation looks smooth and fluid while CPU and memory usage are under control, so we’ll stop here.
Summary
We have just looked at the process of optimization, using the Flames class as an example. While the many optimization tips were presented in a step by step fashion, the order doesn’t really matter. What’s important is being aware of the many issues that can slow down our program, and taking measures to correct them.
But remember to watch out for premature optimization; focus first on building your program and making it work, then start tweaking performance.
View full post on Activetuts+
