Why should you care? 96% to 6% CPU usage, that’s why.
Flash Player 8 opened up a lot of boilerplate code via the new Bitmap drawing classes in ActionScript. Usually confined to the nether regions of Director via Lingo, one had to utilize the standard vector drawing tools in Flash. With the combination of runtime drawing with the sprite like nature of MovieClips, Flash enabled pretty powerful tile-based & other gaming engines to be created that were very flexible, and eased a lot of the coding pain that was harder in other graphical engines.
Painful meaning, you had to write a lot more code to get the same result.
Performance Bottlenecks – Many Objects
The one issue, however, is performance. The Flash Player has a few performance bottlenecks, 3 of which tile-based games suffer from. The first is object overhead. Because of the way Flash Player 8 handles prototypes of classes, each Object class has a series of slots for functions and properties, 1 of which is for the proto and prototype properties. These allow the class to know what methods and properties he inherits from his base class as well as who his base class is. Walking up this chain of prototype objects to the main parent (Object) is how inheritance works when you call methods on an extended class; if it doesn’t find it on the immediate prototype, it walks up the chain until it does.
There is significant overhead in creating objects, memory wise. Keeping track of all of the objects slot information, etc. results in a extreme downgrade in performance the more objects you create in Flash, specifically MovieClips. The more MovieClips you create, the slower things get, both in code response time and render time.
Vector Drawings – less detail, high CPU cost
A common response is to simply draw everything dynamically. Why create a tile class object directly (extending MovieClip) or indirectly (extending Object, use MovieClip instance via Composition in class’ constructor), when you can just draw the tiles via the runtime drawing tools into 1 movieclip, and handle mouse interactions via hitTest? Since most tilebased games are event-based, using the keyboard as the primary means of interactivity, the only real hardcore math you are doing is keeping track of where the characters are on the screen, the sprites, and determining if they are allowed to move to another tile.
Utilizing meta-tiles, like Grant Skinner & Brandon Hall have spoken about before, you can significantly reduce collision detection if you need it for a smaller area of objects and tiles, thus lowering the amount of code needed to run for collision detection.
This, however, leads to the 2nd issue. The drawing operations, while fast, are vector only. Most tile-based games utilize bitmaps. Drawing bitmaps would require pixel-precision to duplicate in vector, and vector images are extremely CPU intensive. Another option is to merely just attach bitmap tiles as MovieClips, but then you are back to the same problem of too many MovieClips. Even if they are in no way associated with a class (beyond MovieClip by default), you still incur the overhead.
Bigger vector images do not scroll well either. Even if you don’t utilize strokes (since strokes are rendered differently fills, fills being more efficient when compared to strokes), you will notice the larger and/or more complex you make your vector drawing, the lower your framerate gets. The bigger and/or more complicated the drawing, the less responsive your scrolling maps and code gets.
Bigger Drawing Area, Less Performance
Finally, both of the above are contigent upon size of the drawing area. How big is your map, and how much are you displaying. Unfortunately the 2 play extremely little in performance. For example, if you’re drawing is 600×600, and you utilze a mask to only show 200×200, performance isn’t significantly improved, even if the stage itself is 200×200. The reason for this is even MovieClips with their visibility set to false, non-shown, or off-screen are still rendered. While the combination of visibility to false and putting them helps, it doesn’t gain you very much.
Bigger images render slower, as do many small images taking up the same size area. A larger stage size renders slower than a smaller one. Both of the above have an extreme curve; I don’t have the trig for it, but basically significant performance gains can be gleaned from smaller drawing areas and smaller stage sizes.
This doesn’t necessarely bode well for Flash Lite 1.1/2 either. While utilizing vector drawing tools sounds attractive for a runtime that only gives you 1 meg or less of RAM to play with, you must understand the phones CPU’s are not extremely powerful.
Blitting
Solving the 3 problems above can be solved via blitting & double buffering in combination with cacheAsBitmap and scrollRect.
Defined succintly, blitting is taking 1 or more bitmaps, and combining them into 1 bitmap. So, if you remember the arcade game Pac-Man, imagine the game itself as 1 big bitmap and each element; the maze walls, the dots, the ghosts, the score text, and Pac-Man himself, as individual bitmaps, or pixels. Each is painted onto the same background, in order: walls, dots, Pac-Man, ghosts, and score. To the end viewer they appear is different elements because every frame some of the elements appear to move. In reality, it is just redrawn every frame, and only those areas that have changed.
This is important for Flash Player because of a few reasons. First, Bitmaps take far less CPU to render. While Flash Player since day 1 has been a vector-to-pixel renderer, you now have true bitmap objects that are just that; a series of pixles with different colors on the screen. Drawing & displaying these on todays machines takes very little system resources. In all fairness, bitmaps take more RAM to display vs. CPU.
Secondly, to create a scenario like the above, you are still just drawing and displaying 1 bitmap for what would of been a large number of sprites in Flash Player 7 or below. While sprites (Flash Player’s MovieClip) offer an easier way to animate and code, they are not efficient, ecspecially for an exteremely small runtime web player that utilizes no hardware acceleration, excluding some for newer Macs.
Double Buffering
You can accomplish blitting in Flash by using the new Bitmap classes. You can accomplish blitting for games by using something called Double Buffering.
Defined succinctly in a Flash Player context, double buffering is a technique used display a bitmap on screen that contains a plethora of other bitmaps. One bitmap is drawn in RAM, with additional bitmaps blitted, (copied) onto it. Then, you copy the finished bitmap from RAM and display it on screen as one bitmap.
This is done in screen drawing in other applications to prevent redraw issues, such as seeing the drawing as its being drawn. However, because of Flash’s single-threaded nature, this is mainly done to simplify coding and still getting the performance increase of only displaying 1 bitmap to the screen.
Conclusion
Thus, a developer has the opportunity to create some really compelling tile-based games in Flash Player now that the performance bottlenecks can be overcome via blitting and double-buffering.
Part 2 will show how you utilize blitting and double-buffering in ActionScript 2 in Flash Player 8, and ActionScript 3 in Flash Player 8.5. Additionally, I’ll show you used to do things, and how you can get your CPU usage while scrolling the map to go from 96% to 6%.
