Posted on December 15, 2006
Right now, Steve is putting the final touches on the technical design for our 8bitrocket.com site. It won’t be spectacular looking, but that is because we want a pretty basic site. While he is doing that, I am finishing up my latest game called Retro Blaster. It is basically Asteroids, but I have put a lot of work into the Actionscript animation engine, so it is more of a tech demo that has ballooned into a much larger game.
Retro Blaster uses a relatively new Flash 8 technique that I call bitmap animation caching. It is an idea that I got from a short optimization conversation I had with Jobe Makar (http://www.electrotank.com/) about blitting objects on the screen in Flash. One of the largest resource hogs in Flash is the rendering engine. Complex animations, with many points, use up an incredible amount of resources. For example, I am using Steve’s particle engine to create explosions. These explosions use a small version of the object that is exploding as a base particle. The objects can have many points, and the particle engine will create individual particles from these small versions of the objects. Basic Movieclip bitmap caching is fine for objects that are simply moving across the screen, but if an object needs to run through an animation sequence, Movieclip bitmap caching is completely useless because it will cache each animation change each frame and because the screen is invalidated on each frame, you derive absolutely not benefit from the cache. In some cases, the system runs even slower than without Movieclip bitmap caching.
My solution was to copy each frame of an animation into a Bitmapdata object. All of those objects are pushed into an array. When played back in sequence by copying each frame in the array to a MovieClip you eliminate much of the resource use (not all, but about 75%) compared to rendering on the fly. Basically this amounts to pre-rending all of the animations needed for game play. Everything from explosions to asteroids rotating can be cached in a BitmapData array and displayed when needed.
My first attempts at this amount to simple tech demos where I places as many as 1000 objects on the screen, and displayed their cached and non-cached animations. I calculated the frame rate.The frame rate for 1000 non-cached objects never rose about 7FPS on my Dual Core 3Ghz machine.
See a demo of 1000 objects rendered with plain vanilla Flash rendering
The frame rate for 1000 cached objects would hover around 18FPS. That means I could put nearly 3x the number of objects on the screen with my new method.
See the demo of 1000 animation cached objects<.
Since a decent Asteroids clone would probably never need more than 100 objects moving and animated on the screen, I decided that I could lover the number to 300 and check the frame rate. At 300 objects, the frame rate stayed at a comfortable 30FPS and didn’t budge. That made me feel secure that I could sustain at least 25 FPS, even in the most hectic of Asteroids games.
See the demo of 300 animation cached objects.
All three of these frame per second calculations will be slightly lower when played in a web browser. I timed these inside of the Flash IDE. This problem can be aleviated in a number of ways. The best is to set your movie FPS to 100, and then use setInterval to run your game loop. If you must use onEnterFrame, then make sure to play with the wmode propeties of the imbed code to see which value works for the specific browser you are targeting.
Retro Blaster was born out of this. I started with my own rudimentary graphics, but after being completely unimpressed with my artistic ability, I asked a co-working named Marc Manalli to help out. He is a very gifted illustrator and was able to whip up some great stuff in just a few hours.