In Actionscript 3 there are usually different coding methods to achieve the same output (this can be said of any programming language). Variables can be declared in different ways, math equations can be performed in different ways, you can move code into functions, perform things on single lines or multiple lines, and so on and so forth. While different methods may achieve the same output, certain methods are often faster than others. This post is dedicated to finding as many performance tweaks and enhancements as I can, and I will update it as I find more.

Methodology: For each test, I use the following loop to determine the relative duration of processing time. I use 500,000 iterations (or more in some cases) so that small differences in performance between code are exacerbated. Usually, any variables that I use in the test are initialized before the timed loop, to eliminate their initialization time from the test. That is unless I'm testing the performance including initialization. I also run the test multiple times to get the average time.



Continue reading...

Functions are useful tools that allow you to reuse code, reducing file size and keeping your application better organized. There is a trade-off however, and that is function overhead. An Actionscript 3 application will take a small hit in performance when moving a section of code out of the normal flow of the program and into a function.

This hit is very minimal in most cases, so you shouldn't avoid using functions by any means. For example, if you're only calling a function once per frame the overhead will be non-existent. Code organization is more important in these cases.

A case where function overhead could become a problem is when a function is called many times per frame. Perhaps you have a function that calculates a vector for projectiles, and you have thousands of projectiles being created per frame at times. In this case, it may be better to include the vector calculation in with the normal flow of code and avoid using a function, even if that vector calculation needs to be in a couple different areas.

Unfortunately the actual performance difference is difficult to measure. The following test took 572 milliseconds:


Continue reading...

Unsigned integers are integers that can be positive values only. They are useful to have in programming languages because they can hold a higher maximum positive value than a signed integer, without using additional memory. For example, int in Actionscript 3 is a 32-bit signed integer and can hold a range from -2,147,483,648 to 2,147,483,647, while uint is a 32-bit unsigned integer and can hold a range from 0 to 4,294,967,295. It is useful to use unsigned when dealing with large counters that will never be negative, as it gives you a higher maximum.

Logically, you would want to use uint when dealing with integers that will never be negative; however, Actionscript 3 throws us a curve ball. It turns out math operations on unsigned integers are noticeably slower than operations on signed integers (at least using CS3, haven't tested it in CS4 or CS5). Here's the performance test I ran for int:



Continue reading...

Object pooling is a technique where, instead of deleting object instances when we're done with them, we store them in an array until we need them again. This avoids the overhead related to object instantiation, which can make the game run smoother at the cost of storing a little more data in memory.

It is generally a good idea to use object pooling for instances of commonly used classes, such as projectiles, particles, enemies, etc. Basically, when an object instance is done, we remove its event listeners and remove it from the stage, like normal, but at the same time we add it to an array. This reference from the array prevents the garbage collector from garbage collecting that object. When we need the object next, we use a custom cleanup function that we created for that class, which resets all of the important variables for the object and adds it back to the stage with any necessary event listeners.

This is a very brief example that just shows the basics of this technique. You should be able to get the idea from looking at the below code and then be able to implement it into your game.

Below is the code corresponding to the object class:


Continue reading...

While creating a dynamic music player for the web in flash (AC3) I ran across a bit of an issue. When attempting to get the length of a song using the .length function, flash only returns the length of what it has loaded so far. Until the sound is fully loaded, flash is unable to tell you the length in seconds of that sound file. I found a solution that works well and doesn't rely on the length being manually inputted or pulled from the ID3 tags.

Utilizing Actionscript 3's .bytesTotal and .bytesLoaded functions, we can obtain the total file size of the sound file in bytes and how many bytes have been loaded thus far. Then using the .length function we can obtain the length in seconds that have been loaded. After that it's just a quick math equation and we get the total length of the song in milliseconds. soundLength = mySound.length / mySound.bytesLoaded * mySound.bytesTotal. Keep in mind that the total seconds won't be completely accurate for the first 1%~ of the sound. Just have it display a loading message first. For fast connections they likely won't even notice it.

Continue reading...