One of the biggest reasons to go to Actionscript 3.0 is a massive performance boost you gain from older versions of Flash.  Michael James Williams sent me this link to a forum post to prove the point:

Over 5000 Arrows at 30 fps

Mike Grundvig posted on his blog how he got this to work and after reading it over twice, it is very “old school” in how it is accomplished.

The way Flash does programmatic animation is pretty simple.  You take a MovieClip instance on the screen and you simply adjust the x,y values to get it to move.  Flash takes care of the redrawing of the screen for you with no flicker. What Mike Grundvig did was do all the drawing himself.  Instead of using Flash to draw the final output on the screen, he takes all the calculations on the back-end, draws onto a BitmapData object and swaps out the resulting BitmapData with the Bitmap currently being displayed.  In other words, he is doing a kind of low-level “double buffering” using Flash Bitmaps.

When I was a kid programming in BASIC in the Apple II+, I would wonder how computer games made smooth animations.  My problem was when I created a picture and I wanted to “flip” to the next frame of the animation, I had to clear the screen and draw the next frame.  The clearing of the screen caused a moment of blackness before the next frame was rendered.  What I didn’t understand was how to “double buffer” which is something much lower level than I could have achieved in BASIC.  I had to understand assembly language to accomplish that.

Effectively what “double buffering” does is skip clearing out the screen.  Instead of working on 1 screen, you are working on 2 screens.  First you draw the screen.  And instead of clearing it off for the next screen, you do all your drawing logic on the second screen while the first screen is being displayed.  Once drawing is completed, you simply flip from the first screen to the second screen like a flip-book.  That removes the flicker effect of having to draw, erase, and draw again.

Modern graphical engines like Flash take care of this logic for you and are incredibly efficient.  Thus, instead of having to figure out how to draw when you move your MovieClip 10 pixels to the right on the next frame, Flash does all the drawing for you.  But it comes at an expense of CPU cycles to figure out all that drawing logic for you.  You can see the effects of this drainage in Space ROX when I started adding particle effects and Asteroids.

Space ROX V 0.5

Now compare the performance of only a couple hundred particles in my Space ROX demo to the thousands of arrow particles shown in Mike Grundvig’s demo here.

Sometimes it pays to go back to the basics.

I just discovered the “Bitmap” and “BitmapData” classes in Actionscript 3.0 from this blog tutorial on FlepStudio.

Here is an example of what his tutorial and sourcecode looks like:

Actionscript 3.0 - Bitmap and BitmapData Tutorial

This class could have saved a ton of performance and speed in Strike Eagle.  In Strike Eagle, the moving background is a series of movieclips placed side-by-side and continually scaled which is a huge performance hit in the system.  It would have performed so much faster if I was simply blitting onto a bitmap.

Also, all the particle effects in Space ROX could have used the bitmap treatment saving tons of processing power and reducing the total number of movieclips.