# Large Sprite Performance

I've got a large Sprite generated using a set of vertices(x,y coordinates) and a bitmap pattern (using moveTo, lineTo, beginBitmapFill, endFill ...etc). It's about 15000 pixels wide and between 1500 - 2000 pixels high depending on the level -it's the terrain for a 2D game.

My question is: what is the best way to display/move it on the stage - performance wise?

Currently I'm just adding it to the stage as is...I get decent frame rate/ memory/ cpu usage but I want to optimize it for slower PCs. Any ideas? I've been reading a little about blitting but I'm not sure how to implement it in my case.

Thanks.

• Make sure it is a bottleneck before splitting it into tiny pieces. Time the top frame rate with and without that sprite. If it does present a problem in performance, split it up to bitmapData objects the size of one game screen and render only four of these at each time. good luck. Blitting is not useful in cases like this for AS3, it is good for situations where you have many (hundreds) of tiny sprites on the screen at once. – AturSams Oct 2 '12 at 19:35

I was thinking about this and finally realized your problem with performance is drawing alone - you redraw whole screen everyframe when terrain is scrolled, that's an overkill for weak CPU. And that's where Starling makes miracles.

I'm not sure how well flash optimizes it behind scenes, it changes a lot with time (notice that in every update there is "significantly increased performance" or something like that), for example, nowadays blitting don't give you as much as it used to years ago.

I think the most up-to-date solution to spare CPU is to use GPU, that is stage3D. I know, I know, your game is 2D, but stage3D is just about GPU (graphics-card) rendering. There is Starling 2D framework, that uses stage3D. But you should know that you can't draw vector graphics below stage3D (you can only draw them on top of GPU rendered graphics, unless you draw them to a bitmap, rasterizing it, and then use in Starling)

Other solutions are to divide the bitmap to smaller parts, or as you said - blitting, that is using copyPixels method.

• Thanks. I know about Starling. I was wandering about ways I could optimize it without porting all of my code to a new engine (Starling.. Flash Player 11, wmode=direct,etc..). I'm going to try splitting it into smaller bitmaps first and see what happens. – Iansen Oct 2 '12 at 17:52
• Actually it would be easier to try blitting first - you would simply copy a rectangle of pixels being a current view of the area. That seems like copying a lot of data every frame, though. – Markus von Broady Oct 2 '12 at 17:58

Edit: I think I misread your question. I thought you were asking for a looping background. In case you might find this useful anyways I'll my answer here. Correct me if I'm wrong though!

You can either create a bitmap with a resolution of your stage size and process the edges to loop ( takes a bit a of a script for this but they are out there).

Or you create 9 sprites/bitmaps that are repositioned depending on the cameras position. Creating an illusion of endless loops.

I hope this makes any sense:

Direction is the movement of your camera, thus the position of the camera changes.

The base is the center of your camera or character ( if it's in the center at least). So basically you define the position of each background piece by dividing the position by the width and height of the screen

 var baseX:int = int(center.x / cellWidth) * cellWidth; // Ensures a clean integer;
var baseY:int = int(center.y / cellHeight) * cellHeight;


Now you loop trough your sprites/bitmaps with a double forloop( because you are working with rows here)

I might have made a mistake but it looks something like this

for (var y:int = 0; y < 3; y++)
{
//Each column
for (var x:int = 0; x < 3; x++)
{
bitmaps[y][x].x = baseX + (y * cellWidth); // Cell width and height
bitmaps[y][x].y = baseY + (x * cellHeight);// are the sizes of the pieces
}
}


Use a 2D array, it's easier due to the nature of your rows and columns.

Here is an example of a 4x4 grid. Obviously the cells are suppose to be bigge so that you don't see them jump around:

4x4 example

Use arrow keys.

• +1 but isn't the bottleneck at drawing the bitmap, not positioning it? – Markus von Broady Oct 2 '12 at 19:04
• Since you're just using 9 bitmaps or sprites there is virtually no bottleneck. This way you're eliminating the need to have one giant bitmap (Which is a waste of memory anyways, considering he does a bitmap fill on it which loops his pattern). And there is no need for a copypixel on update ( if you were going to blit it ). In flash it's easy to split up a looping background image into 9 smaller pieces for this purpose. It's basically a win win. Im not saying this is the best method. Surely there are other methods. Flash does bitmaps pretty well. This shouldn't even cause a performance issue. – Sidar Oct 2 '12 at 19:15
• @MarkusvonBroady You know what, I think I totally misunderstood his question. I thought he was asking for moving a background. Totally misread it. At least I think...Now i'm just confused... – Sidar Oct 2 '12 at 19:22
• You assumed his big background is made of smaller, repeated pieces. If yes, your code will optimize his memory; still what makes his game slaw is CPU drawing probably, and that's what I called the bottleneck. – Markus von Broady Oct 3 '12 at 6:33
• @MarkusvonBroady I didn't assume his background is made out of smaller pieces. I understood it as a repeating background. And no, this technique I'm giving for repeating backgrounds isn't going cause any bottlenecks. It's 9 bitmaps. Flash has absolutely no problem with drawing 9 bitmaps. It's trivial. – Sidar Oct 3 '12 at 9:02