I'm trying to make a sidescrolling game in Flash that will run on a low performance laptop.

While studying the subject from Tonypa I saw that he builds a Bitmap by making copys of the BitmapData of each tile from the Tile Sheet and placing it on the bigger Bitmat with the size of the screen.

But when I came to think on how to scroll my map I ran into some optimization doubts. I came up with two choices:

  1. Create a MovieClip, place a Bitmap instance for each tile that is shown on the screen + 1 row in it, then move them all. Then when the tile ran off the screen I would move it to end of the MovieClip and replace their BitmapData for the next row in my map.

  2. Use a Bitmap with copys of each tile in it (as shown in Tonypa's tutorial) but 1 extra row, move the whole Bitmap, and when it comes the time to replace rows, redraw the whole Bitmap and move it back to the origin position.

The first idea is how a co-worker of mine suggested, the second one is my own, but none of us has enough technical knowledge to be sure on a technique that would be optimal in performance, can anyone help?

  • 2
    \$\begingroup\$ Have you tried implementing either one yet? I suggest trying one out, see if you even need to worry about performance with this aspect. \$\endgroup\$
    – House
    Commented Mar 28, 2012 at 19:00

2 Answers 2


The second idea would be much, much faster. Rendering dozens of DisplayObjects every frame is going to be slower than occasionally re-blitting to a Bitmap.

Depending on the speed/memory tradeoff you want to make, you can make the background Bitmap wider to make your redraws less frequent. Keep in mind that there is a maximum size for Bitmaps, depending on which Flash player you're targeting, but that size is at least 2048 pixels in every direction.

  • \$\begingroup\$ Thanks for answer, so in general it's always worse to have multiple objects on the screen than having only one, even that they have the same size right? The big question I had was about what yould be more "expensive", redrawing the Bitmap or just moving the smaller ones. Again thank you. \$\endgroup\$
    – Galvas
    Commented Mar 29, 2012 at 19:44
  • \$\begingroup\$ That's correct. Each additional DisplayObject (like a Bitmap) on screen has to be transformed and blended using Flash's more powerful but slower display stack. Frameworks like Flixel and FlashPunk, which are designed to show large numbers of non-vector objects at once, go around the Flash display stack by drawing objects to a single Bitmap object that serves as their display buffer. \$\endgroup\$ Commented Apr 1, 2012 at 17:09
  • \$\begingroup\$ or even better, use textures and stage3d \$\endgroup\$
    – ansiart
    Commented Jul 16, 2012 at 19:46

The second is way better / efficient.

The 'old' way (when you really didn't have much processor speed and no GPU) was to use what was called a 'scroller', take your second example and instead of redrawing everything when you have moved one tile (say the game is a Mario clone moving to the right which means you move the bitmap to the left):

Just continue to move the big bitmap and instead of brawing All new tiles, you draw the new tiles to the Left of the bitmap and draw the bitmap a second time to the right of the first draw:

this is the map:


you see this:


because the bitmap is like this:


Now we move 1 whole tile to the right, which means the big bitmap moves to the left (well, you can move it pixel by pixel but here you have moved one whole tile):


(the brackets is the screen)

What you proposes, so that we can continue moving another tile) is to redraw the whole bitmap like this: 23456

but you just need to redraw one tile here (or one tile-column) so the new bitmap looks like this:


draw it twice, first:

62[345 ]



and there you are.

You can obviously use this when moving up / down and left too.

  • \$\begingroup\$ I think in order to do this in AS3 you'd either need to have two bitmaps with the same BitmapData instance or do a two-step process where you draw the tiles to a "backbuffer" and then draw that buffer twice to an additional bitmap. Either way would work. \$\endgroup\$ Commented Mar 29, 2012 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .