Flash performance for game dev: native render VS BitmapData framebuffer

flash actionscript-3 performance
oshyshko picture oshyshko · Jun 19, 2009 · Viewed 8k times · Source

I develop a 2D shooter game with lots of objects and aggressive scrolling.

QUESTION: which way is better?

CHOICE 1 - use native Flash rendering:

  • derive game objects from Bitmap, use existing x, y, width, height, bitmapData
  • add all objects as children UIComponent.addChild(...) to sccreen
  • clip visible area using "scrollRect"

CHOICE 2 - write custom rendering using "bitmap + copyPixels"

  • use own game object with x, y, width, height, bitmapData
  • add a Bitmap to a screen, take bitmapData from it
  • redraw every ENTER_FRAME: bitmapData.lock(), iterate over game objects and copyPixels() into bitmapData, then bitmapData.unlock()
  • custom clipping: do not render out of screen objects

Here in this question some people complain that "bitmap + copyPixels()" is slow.

EXPERIMENT: I have implemented both techniques:

Please, try them and tell which one is better (faster, smoother, eats less CPU).

Wait until there will be at least 250 enemies (counter above the screen).
UPDATE: Try to open Task Manager (or $top) and see overall CPU usage

UPDATE 2: I've changed the code, now creeps spawn much faster.

Answer

fenomas picture fenomas · Jun 19, 2009

Update: thanks for the high-stress version. Again, I couldn't really see a difference just running around. But I cleverly figured out that "r" drops turrets, and when I dropped 20-30 turrets, the native version was somewhat slower than the manual one, so maybe I was wrong. (I saw no difference in memory usage.) It still seems like doing things natively ought to have the potential to be faster, but it may well be that it would require specialized handling of some opaque sort.

Since this was accepted I'll add a note to make explicit what I said in a comment to a different answer: If all your assets are bitmaps themselves, then as HanClinto points out it's not surprising to find that compositing them manually can be faster than making native objects and letting Flash do the work, since it eliminates the overhead associated with display objects, like event structures.

However there are probably situations where doing things manually might win out, such as if you have vector contents that need to be rendered into bitmaps, or lots of animated sprites, or if you need to detect mouse events on your actors (which you'd need to do manually, perhaps painfully, if you do your own compositing).

So if you don't need to do anything that would slow down manual compositing, it appears to definitely be the best answer, and if you do, then trying both approaches is the best way to be absolutely sure. (A hybrid model is also possible, where you make one layer of native objects that need mouse events, and overlay or underlay it with a layer of manually composited bitmaps.)

Related questions

For VS Foreach on Array performance (in AS3/Flex)

Which one is faster? Why? var messages:Array = [.....] // 1 - for var len:int = messages.length; for (var i:int = 0; i < len; i++) { var o:Object = messages[i]; // ... } // 2 - foreach for each (var o:Object in messages) { // ... }

Read More
What are the major performance hitters in AS3 aside from rendering vectors?

In ActionScript 3, using vector graphics is a guaranteed way to cause massive damage to the performance of your project. Using a single Bitmap for all graphics by using .copyPixels() through its BitmapData object in place of all vector graphics will …

Read More
how do I delete/gc an object in Actionscript 3?

I want to delete/force garbage collection on a class instance from inside itself. Obviously, this = null and delete this don't work. Is it any way I can do that, or am I barking up the wrong tree? I'm basically …

Read More