Wednesday, 3 November 2010

In defense of MovieClips, Sprites and the display list (...the case against blitting?)

“This is why I always run a raster pipeline. The DisplayObject API is a trick played on the gullible and the trusting…” — @bengarney
Ben Garney is a very smart game/engine developer with a background in C++ and known for developing the Torque engine, who has now moved into the Flash world with Pushbutton Engine and games like Social City. I come from the complete opposite direction. I’m a Flash guy with a background in quick turn-around, design driven creative Flash projects, who now focuses on game development. This difference in backgrounds, and dare I say *ideologies* is why I thought I should write a response to Ben’s recent post about blitting, and stick up for the display list a bit. If you haven’t read Ben’s article, I suggest you go do that, but for the sake of clarification, blitting is basically using copyPixels to manually draw your graphics to a single bitmap data object that you display via a single Bitmap object on the stage.

Firstly, there is a lot of truth in what Ben says. Here are the advantages I see for blitting:
  1. Renders faster if you have thousands of sprites.
  2. Although Ben didn't mention this, if you use the Flixel, Flashpunk or Pushbutton engines you get some other game engine functionality for free, although most of the benefits of e.g. Flixel are nothing to do with the fact that it uses blitting.
  3. Erm...
Now here are the advantages for using MovieClips, Sprites and Bitmaps in the native Flash display list:
  1. You get rotation, scaling, alpha, filters and colour effects for free. Want to add a glow or blur to something? It’s one line of code, and adds no filesize to your app. If you use blitting you have to somehow prerender all these effects, either as pngs that will increase the filesize of your game, or prerender at runtime, which will add a lot of complexity to your code and add to your development time, and in the cutthroat world of Flash games, time is money. If you combine the display list’s built in effects with an engine like TweenMax, you can make amazing animated effects in just a few lines of code.
  2. You can work easily with interactive designers. Most creative agencies have designers who are experts at using the Flash IDE to create beautiful layouts and animations that you can easily breathe life into with ActionScript. If you are working from flat PSDs for all your assets, you will spend a lot of time laying screens out in code, which is something you never really want to do. The reason Flixel etc are never used on advergames, e-learning games or other client projects is that there is no workflow for designers to add their branding magic.
  3. You get mouse events. You can easily create buttons and more complex interactive elements with complex hit areas. Now in a game it is very possible to use blitting on your gameplay area but still use the display list for all menus/gui, and I would definitely recommend this option over blitting *everything* like Flixel does. However, sometimes you want to have interactive menus and buttons inside the gameplay area, in which case it will be much easier for you to use the display list in your game rather than recreate all that functionality from scratch inside your blitted area.
  4. You can nest things inside other things. This is very useful for things like menus, but is also very a great way to create dynamic animations that can be altered at runtime. For example, if you have an animated character holding a weapon, if the weapon is a sprite inside the character sprite, you can easily swap out the contents of the weapon sprite to change weapons. If you are using blitting, this feature will be time consuming to recreate.
  5. It’s not as slow as people think. If you are just moving Bitmap objects around in the display list you will easily be able to have hundreds of sprites on screen, in a typical game. And as only displayObjects within the viewable stage area are drawn, you can actually have a game play area with thousands of sprites, so long as you can only view hundreds at a time. Turning off mouse interaction for the display objects (mouseChildren = false, mouseEnabled = false) makes everything run significantly faster too. I have a demo with 40,000 tiles scrolling on the display list smoothly at 120fps – as Flash only renders those tiles inside the viewable area of the stage. You can also use a hybrid blitting / display list approach by having a Bitmap objects on the display list which you animate by changing the value of the bitmap.bitmapData property. This is very fast and you still get all the advantages of the display list effects. The best of both worlds!
So ultimately it becomes a question of how much rendering speed ya needs versus how much development time ya gots (read that last sentence in the style of the Clint Eastwood). From what Ben says about Social City, it looks like a poster child for blitting – it’s a scene with thousands of sprites drawn at once (although Ben’s claim that his display list tests were running at less than 1 frame per second suggests to me that he had not correctly optimised by turning off mouse interaction). Either way, display list *will* always render slower for a thousand sprites. But pretty much every Flixel game I have seen would have run perfectly using the display list. Ben says that the display list is the darkside of the force. In equally mischievous tone, I propose that blitting is for people who don’t actually like Flash, and they see everything that makes it unique and interesting, like the excellent Flash IDE and the vector display list renderer, as a negative. I will get some benchmark demos of both approaches up soon. Of course display list will lose, but it won't be as bad as people think. Comments appreciated!


Hugo Larcher said...

I agree with your advantages on using the displayList but for the majority of those advantages you're assuming the hypothetical developer is starting the game from scratch. Now if you have a framework or engine that solves most of those "disadvantages" of blitting then there's little to gain from the display list.

In my opinion it is not so much about comfort or time saving, its more about what you're trying to build, does it need blitting or not? That's the real issue.

Just my 2 cents.

Anonymous said...

I migrated to blitting over traditional work with MCs several weeks ago because of mobile flash/air.

Anonymous said...

i would love to see the benchmark... with the sample code :) Regards

vitaLee said...

"Turning off mouse interaction for the display objects (mouseChildren = false, mouseEnabled = false) makes everything run significantly faster too." - somehow i missed that fact and am actually surprised to learn that.

Anonymous said...

I came from C++/BASIC (think QBASIC) background, so blitting is the natural way to do stuff for me, and DisplayList is just hindering me (believe me :D). But I acknowledge it advantages, which is why all my UI is MC/Sprite :D. But in all seriousness, in a non hundreds of sprite/MC situation, I have been able to rise my FPS from 20-60 just by caching the animation from MC to Tileset (cache and blit it by code), and saves memory too. That is *huge*.

Sunjammer said...

I don't see why you'd have to choose. Hell, you can mash the two approaches up fine; Sprites/MovieClips are fine for animated agents and such that you don't necessarily need a billion of, while blitting is great for tiled based worlds. There is no reason one can't play nice with the other.

Generally speaking I'm partial to blitting simply because i like how the code looks and feels, and I don't typically need lots of rotations or effects on sprites that I can't work in with a forward rendering pipeline that implements applyFilter at some step.

Flash and rendering performance is a strange beast. Sometimes you'll find stuff you thought would run like shit running quite acceptably. It all depends on the demands of your game design in the end.

Keith Peters said...

I've seen a huge movement towards optimization in Flash in the last year or two. You can't go to a conference without running into 2-3 sessions devoted to explaining why uint is faster than ByteArray (joke, but you get the point) and long lists of boring comparisons and charts. I see the blitting argument as an extension of that. I think stuff like this encourages people to write bad, overengineered or unreadable code. I'm sure Ben writes perfectly fine code, with a great framework behind it. But the new guy coming in reading that the display list is bad and he must blit gets himself into a godawful mess when he could have done perfectly fine moving a couple of sprites around. In short, yes, I agree with you.

Ricky Haggett said...

Completely agree Iain. And Flash is pretty good at caching stuff to bitmaps internally these days, so that if you're pushing lots of vector stuff and *not* scaling or rotating them, you can get away with a lot. I think there have been some decent hardware-based optimisations in FP10 which speed things up a lot.

Hohokum ( is written in Flash, and runs fullscreen at a reasonably solid 30fps on my 3 year old PC. When I show it to people, they are often surprised that it's flash, and then I have to remind them that it's finally 2010.

Byron Atkinson-Jones said...

I'm one of the people who saw Hohokum running the other night and was surprised it was Flash running full-screen with what seemed a perfectly stable frame-rate.

Most of my surprise comes from the fact that I have been using Flash since version 3 and up until now it's been consistently slow on a vast range of hardware. The fact that it is now running fast may be down to improvements in hardware (in which case does it still run fast on legacy machines?) or Adobe finally gave the player code a kick up the arse it desperately needed.

Either way, what this does show is that we need to keep testing speed and not rely on old habits as being truth.

I would still like to see benchmarks run on a variety of hardware since a lot of people who play flash games may still be running on hardware that even a palaeontologist would have difficulty recognising.

ChevyRay said...

Good write, Iain :) it's important that people realize the differences between the two approaches to graphics, and not just assume one or the other is better. I personally have used (and still use) both systems depending on which kind of project I am working on.

I wouldn't recommend writing up your own blitting engine unless you're just totally interested in doing it for practice, or you actually are certain your game needs such a thing. Even so, the popularity of engine's like Adam's Flixel and my FlashPunk have hardly anything to do with rendering speed, I just think people make assumptions because of the way we wrote our respective engines anc jump to the conclusion that blitting is for some reason better.

Hardly; like you say, the DisplayObject classes in Flash are extremely powerful, and have tons of filtering, blending, drawing, and other event/transformation methods available. In fact, I'd say that's the stronger aspect of using Flash's native classes - rendering. Flash was (and still is) an animation tool first and foremost, and is to this day still an amazing piece of software for working with vector graphics.

When I was first working on FlashPunk, actually, I was going to use Flash's display list to render the graphics, but to achieve a certain set of features I wanted, it was much easier and more comfortable for me to code in a blitting engine with some optional draw() parameters. The result, extremely fast Z-ordering, very memory-efficient game objects, breaking graphics into multiple components helps organize games and synchronize these classes with their respective collision components, and when you're used to coding game engines with the update/render loops separated, it's really helpful to have strong control over the order of events (including rendering) in your game.

So there's pros and cons to both systems, as is already established; Flash's display list undoubtedly offers a much broader expanse of event and rendering capabilities, custom rendering engines are probably easier to port into different languages as well, but I can't vouch for that.

It's a fairly interesting subject, but for me, not really news at all; I doubt it is for Adam as well, I don't think we really share the same opinion as Mr. Garney.

Like I said, blitting is such a small portion of what engines like Flixel and FlashPunk offer, it's hardly a point of discussion, since their framework setup is more about design patterns and ease-of-use than anything else.

Nathan said...

I think the main reason blitting needs to be discussed and emphasized is that Flash's display list is the default. It's great for lots of things, but you really have to dig around to even understand that there are alternatives.

For example, when I made Sparks and Dust, I used display lists. Had I known about blitting, the game would have been much faster... Live and learn, I guess.

From my perspective, I actually really appreciate the high quality flash renderer at level load time - so I can keep file sizes small, draw lots of stuff at high quality (with scaling, rotation, and filters), and then use blitting for cached stuff with per-frame drawing.

jpauclair said...

I did talk with ben many time already, and I think each single discussion ended at some point on the "blitting vs MCs". Pretty fun discussion.

Bottonm line is, I think blitting is a great solution, faster than MC and easily exportable and manageable.


Some thing are hard to do with blitting. Like animation. you rarely see a good animation made out of blitting. Using the natural displaylist hierarchy, you can create a "skeleton based" avatar animation that look amazing while keeping a very small file size.

You can also use that structure to manage customization.

I love both solutions. I think it really depends on what you have to do.

check out or for exemple of avatar animation/customization using MCs.

gludion said...

In an ideal world, we could also add the benefits of movieclip as multi-frames container, ie "timelines". It "was" (see below) a convenient and logical way to store graphical states of an object, animated or not.
Unfortunately the gotoAndStop (an essential instruction for going from a frame A to a frame B) didn't survive well with the transition to as3 (type "gotoAndStop" in Adobe FP bug system, and consider not the most famous bug but also the others). It has really hurt many flash integrators, and programer/artists.
I know it's totally off-topic, but what could have been a strong point in favor of clip timelines, and perfectly worked in as2, lost a lot of its reliability in as3.

LSaridina said...

Ha.. so it's called blitting. Thanks for show the name of that method, I seek the name for almost these two weeks (maybe at the wrong places, I don't know).
I come from Display Object API user to Blitting as the standard display object is so troublesome on the mobile area. And because any other languages beside Actionscript are clearly not use them. Working with Display Object is good for learning, but at some level you need to go back to traditional rendering.
Another thing that should be note are blitting is so close with bitmap, and many sample arts/working artist I found from google images are in bitmap. So perhaps, it's only flash artists that ready with Movie Clip animations.
This is a never ending discussion as there are no exact benchmarking that will prove the theory. Any programmer will try to prove from their own side. One thing to be considered is when you don't want to only work with flash and as, you really need to start learn this blitting methods.

Anonymous said...

Thank you for an good article. I am making a new game for a client and was looking into game engines for flash.

There is no way I want to spend several days rasterizing all the effects the flash artists lay on the graphics so blitting is simply not an option.
My question is: Are there any good game frameworks out there that supports the normal display li
How about making a HUD and all intro/outro screens in normal flash, and make the moving parts in flixel, is that even possible?


Novacoder said...

You write "I have a demo with 40,000 tiles scrolling on the display list smoothly at 120fps"

Can you please allow me to see this demo and the source code is appresiated as well?

I'm developing game like social city but when I do scrolling fps falls significantly :(