Actionscript 3.0 Discovery – Going Old School
by Paolo on May.20, 2009, under Experiments, Programming
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.
May 22nd, 2009 on 3:00 pm
Very interesting, but the arrows demo is not holding around 30fps it’s holding at 19fps, still pretty impressive. I might do double buffering from now on instead of doing the whole addChild() way.
May 23rd, 2009 on 2:59 pm
Hi Joseph,
The performance of Flash is largely determined by the speed of the client processor. On my work machine and gaming machine, they both held at about 30-34 fps – but both are pretty “beefy” computers. I will have to check on some older computers to see how fast they perform.
May 24th, 2009 on 12:38 pm
Yeah, I tried it on another computer and it managed to hold a little bit higher, about 21fps… I suppose your right that it depends on the processor. Although when I lowered down the amount of arrows being generated to 10 instead of a 100 it shot up to 34fps, and held there
And just tested it with 50 arrows per frame and it held at 26 fps, not bad at all. I wonder if this sort of rendering could speed up the 3D engines out there made for flash… Hm.
May 24th, 2009 on 9:05 pm
Also keep in mind that the Flash file is 1024×768. An 800×600 bitmap would perform better.
I don’t know what kind of 3D rendering techniques the 3D engines use, but it also crossed my mind that this level of blitting and double buffering could be used for 3D games. But CS4 already uses quite a number of 3D transforms that it may be a bit redundant trying to program a 3D engine all over again in AS3.
But this is perfect for particle effects.