100 Movie clips vs BitmapData... why are MCs faster?

I'm currently in the process of trying to make a faster version of Invasion 4, since in the later levels there's an incredible number of objects flying around, and it kills most computers.

The main problem, I thought, was that Flash doesn't like having lots of movie clips to keep track of.

I plotted for a while, and then came up with this solution: have just one movie clip, but draw it 100 times into a BitmapData object!

So here's the code I used:

PHP Code:

---

import flash.display.BitmapData;
import flash.geom.Rectangle;
import flash.geom.Matrix;
var stageW:Number = 700;
var stageH:Number = 400;
// Make my BitmapData...
var myBmp:BitmapData = new BitmapData(stageW, stageH, true, 0x00000000);
createEmptyMovieClip("bmp", getNextHighestDepth());
bmp.attachBitmap(myBmp, getNextHighestDepth());
// Make an array of all the infantry that are walking.
walkingInfantry = [];
onEnterFrame = function () {
    // Clear the BitmapData.
    myBmp.fillRect(new Rectangle(0, 0, stageW, stageH), 0x00000000);
    // Make sure infantry is on walking frame, since frame 2 is his attacking animation, and frame 3 is his death animation
    infantryClip.gotoAndStop(1);
    // Loop through the array of all the infantry that are walking
    for (i in walkingInfantry) {
        w = walkingInfantry[i];
        // Add soldier's xspeed to his _x
        w[0] -= -w[3];
        // Make soldier move between -.5 and .5 pixels on the _y axis.
        w[1] -= -0.5+Math.random();
        w[2]++;
        if (w[2]>infantryClip.anim._totalframes) {
            w[2] = 1;
        }
        var translateMatrix:Matrix = new Matrix();
        // Translate BitmapData to the coordinates of this soldier
        translateMatrix.translate(w[0], w[1]);
        // Make infantry MC go to the frame that this soldier's on
        infantryClip.anim.gotoAndStop(w[2]);
        // Draw this soldier
        myBmp.draw(infantryClip, translateMatrix);
    }
};
for (i=0; i<=100; i++) {
    infantryClip.gotoAndStop(1);
    walkingInfantry.push([-50, 290+random(20), random(infantryClip.anim._totalframes)+1, 3+Math.random()*5]);
    // ^^^ [x, y, frame, xspeed] ^^^
} 


---

Compared to the 100 movie clips code, which is this:

PHP Code:

---

infantryClips = [];
onEnterFrame = function () {
    for (i in infantryClips) {
        w = infantryClips[i];
        w._x -= -w.speed;
        w._y -= -0.5+Math.random();
    }
};
for (i=0; i<=100; i++) {
    infantryClips.push(attachMovie("infantryClip", "infantryClip"+getNextHighestDepth(), getNextHighestDepth(), {_x:-50, _y:290+random(20), speed:3+Math.random()*5}));
} 


---

But the '100 movie clips' method ran at a higher framerate than the '1 movie clip drawn in 100 different positions' method. What gives? Surely the BitmapData technique would mean that Flash doesn't have to render as much, and wouldn't have to store the properties of all those movie clips?

You can view the BitmapData file at:
http://www.birchlabs.co.uk/InvasionOptimized.swf
And the 100 movie clips at:
http://www.birchlabs.co.uk/WithoutBMPData.swf

Is there any way I can use BitmapData to make 100 troops move at a higher framerate than with 100 movie clips? I'm sure there's got to be. Is the lag linked to Redraw Regions? The BitmapData fills the whole stage (I'd narrow it down to just the strip of land the infantry walk on, but arrows will be able to appear pretty much anywhere in the final game), whereas the 100 movie clips use a much smaller redraw area.

It's a process called "Blitting", and the sprites are Blitter OBjects ( Or bobs ).

I tried playing with it for my current game, as I need to move a ton of data around.
I found even when using a double buffer display I could only get it running at roughly the same speed as the same number of mc's, and for the time and effort it was taking, the lack of an easy hitTest amongst other things, it's easier to stick with mc's.

Really disappointing as I've had it in my head since F8's launch that bobs would be quicker.
There may be some tricks like damage maps and only updating movement every other frame ( By burning the bobs into the bitmap ), but to be honest it's a lot of effort just to see if it could be quicker.

Sorry it's not better news mate ( I was planning to write this up as part of the post mortem of the current game ).

Squize.

Ahh, shame. There's still a lot I can do to optimize the code, but I get the impression that it's the graphics rendering that's slowing down the Flash Player most. Speeding up the code would probably only gain me about 1-3 FPS after a complete rewrite, so it's not worth the effort for a game that's already been released.

Although I am pretty proud that I thought up an optimization like that without having heard of it before. Also surprised to hear that it's already been used and given a name.

Pardon my French, but I'm pretty p*ssed off that there's no evidence of the Mac Flash Player 8's OpenGL rendering speeding either of these SWFs up. They're both still running faster on my brother's PC (although admittedly, it is quite a high-end one). What is it that Macromedia added in Flash Player 4 that made the Windows version so much faster? And do we still not have it on Macs?

Some time ago I made a ticker for one of the games and in the beginning I did it by scrolling some mc.

Later I decided to make it smoother and got better berformance by copying part of a bitmap data from the image that was located in the library to a stage. If you are interesting

I can post here two types of tickers to prove my words (with a source code). As far as I know the BitmapData works faster then MC, but it really depends on what you do and how you write a code.

Actually, if you came to another results and I suppose you came (according to what was written in the subject of this thread), I'll be happy if you post here a link to some test.

Now I feel that I missed something important :)

Already posted links to the tests I did:

You can view the BitmapData file at:
http://www.birchlabs.co.uk/InvasionOptimized.swf
And the 100 movie clips at:
http://www.birchlabs.co.uk/WithoutBMPData.swf

I came to the conclusion that, odd as it seems, 1 MC printed 100 times in BitmapData is slower than 100 MCs.

@ The Helmsman:
please post some samples if you can,- I am up this topic myself as well soon enough and i´d be interesting what other found out so far.

@ VENGEANCE MX
I think the bitmapData version would run faster without the anti-aliased alpha data of the objects (maybe using pre- drawn pixelated frames). Also on this old computer here the movie runs a lot faster turning the rendering quality to LOW

When both the swfs are in low quality, the movie clip one still gets a better framerate, though. :(

render, I was just using 8 bit images, no blended alpha.

Like I said, some speed up may be possible, but it's a case of how long do you want to spend re-inventing the wheel ? mc's can do everything and a ton more than bobs can, and from the little I know in F9, sprites will be even quicker again as "dumbed down" mcs.

Would be interested in seeing some examples from other people though, more than happy to be proved wrong on this one :)

Squize.

Maybe the problem is that by using 1 huge bitmap you force Flash to redraw whole screen completely at every step. When using lots of small movie clips you still have some areas on screen that are not being redrawn and as such saves valuable time.

Quote:

---

Originally Posted by renderhjs

@ The Helmsman:
please post some samples if you can,- I am up this topic myself as well soon enough and i´d be interesting what other found out so far.

@ VENGEANCE MX
I think the bitmapData version would run faster without the anti-aliased alpha data of the objects (maybe using pre- drawn pixelated frames). Also on this old computer here the movie runs a lot faster turning the rendering quality to LOW

---

Here are some samples you've asked for: link to view samples together with a source code :)

Hope you'll see the difference ;)

BitmapData ticker is faster in my Flash Player. :(

Tonypa, that is one thing I did consider. Perhaps a test where a smaller stage size is used would be in order?

I think I have another idea - it's possible that Flash is converting infantryClip from vectors to bitmap each of the 100 times it copies it into BitmapData. Perhaps if I used draw() to create a bitmap of the infantryClip, then used copyPixels() 100 times to move that BitmapData into the main one, it'd be faster?

"it's possible that Flash is converting infantryClip from vectors to bitmap each of the 100 times it copies it into BitmapData. Perhaps if I used draw() to create a bitmap of the infantryClip, then used copyPixels() 100 times to move that BitmapData into the main one, it'd be faster?"

Yep :)

copyPixel is quicker anyway, so by copying the vector data to a bitmap once you're removing all the overhead of having to convert a lot of vector data to bitmap, and then blit it.

Squize.

Aha! Using a BitmapData buffer for the blitting, I was able to get about 15 fps, where the 100 MCs gave me about 6 fps. :D

Good work!

I think I must have done something really wrong to only get very similar results in my tests. Oh well, something to try for a different game one day :)

Squize.

http://www.birchlabs.co.uk/InvasionBuffered.swf

There's my buffer test. Compare your framerate to 100 MCs:

http://www.birchlabs.co.uk/WithoutBMPData.swf

So what's happening this time is that I'm using draw() to transfer the movie clip into a BitmapData buffer. Then I'm using draw() again to draw that buffer into 100 diferent positions on the battlefield. I was originally using copyPixels(), but there's a small problem with copyPixels() - if a transparent pixel overlaps an existing pixel, it'll replace it rather than going on top of it, so the transparent square around the troop was overlapping parts of other troops (resulting in only about 3 soldiers being visible).

[EDIT] Just noticed that the sky was being bitmap cached, even though it's animated. Stupid me. Now I've uploaded everything with faster backgrounds; the buffered version runs at up to 22 FPS, and the 100 MCs... runs at up to 8 FPS. :mrpimp:

I only get 5 FPS on your new buffered one. Then again I only get 1 FPS on the 100 MCs. So my comp suckorz

Try again, I posted faster versions of both a few seconds ago.

Now I get 8 FPS on the buffered one and 2 on the 100 MCs. go 5 y/o comps

The iMac G5 downstairs got the optimal framerate of 31 FPS in the buffered version when running in the standalone player with no other applications open. Comapre that to the 6-8 fps it got on 100 MCs. Nice!

Y'know what, I think I believe in FP8's OpenGL rendering again. :)

this is a real nice test/discussion......

vengeance, thanks for bringing this up.....but I'm not very clear about your second/last step in the process.....are you saying that once you drew the MC for the soldiers into the bitmapdata buffer, then you use draw() again to "move" the mc/soldiers on the screen, whereas before you used to use copypixels() to "move" that on the screen??......
trying to understand exactly what you're doing. :)

thanks,

paul.

In the first BitmapData test I did, I had one BitmapData object. I had an array of different troop properties, and used draw() 100 times, translating it to draw at the coordinates of each troop in the array.

In the second BitmapData test, I had two BitmapData objects - the main one, and the buffer, and I had an array of troop properties. The buffer was 35x50 pixels, and I used draw() once to put a rasterized version of the soldier's movie clip into it. Then I used draw() 100 times to put the buffered image into the main BitmapData in the positions of each troop in the array.

The difference between them is that in the first one, I was converting the movie clip to a bitmap each of the 100 times I drew it, whereas in the second one, I only converted it to a bitmap the first time, then copied that bitmap onto the battlefield 100 times.

I see.....I thought you used copypixels() though, somewhere......was it instead of draw() on the last step?...

thanks,

I was told to use copyPixels(), and tried it out, but it turned out that copied pixels replace the pixels I want to draw into, instead of being drawn over them. A small difference, but it means that if there's a 0% alpha pixel in the buffer, it makes the corresponding pixel in the main frame 0% alpha as well, instead of drawing 0% of that buffer pixel's colour on top of the main bitmap (like draw() does).

In other words, copyPixels() replaces areas of the image, whereas draw() puts pixels on top of the existing ones. So using draw() to insert a 100 by 100 pixel square of 0% alpha pixels wouldn't change the main bitmap at all, but using copyPixels() to insert the same square would clear that area of the main bitmap. This means that copyPixels() wouldn't allow troops to overlap each other - they'd just get wiped off the battlefield if they intersected any transparent copied pixels.

[EDIT] Added depth sorting. With BitmapData. How did I do it? Wouldn't you like to know. :)

nice work Vengeance.

i guess you sorted an array based on a z value ;) then draw into a bitmapData. I've used this sort of thing before as well. I was thinking of making a nice little class to manage it, maybe later ;)

One more thing to test: Instantiating objects takes a lot of time, so you can test take out the "onEnterFrame" the two instantiations you have:

do a:
var rect:Rectangle = new Rectangle(0, 0, stageW, stageH);
var translateMatrix:Matrix = new Matrix();

and inside the loop:
myBmp.fillRect(rect, 0x00000000);
...
translateMatrix.translate(w[0], w[1]);

EDIT:
Also, are you sure about the "transparency" problem? I had the same problem when tried some bitmap scrollers, and the problem was that the buffer was not transparent "initialized" (you have to do a buffer.fillRect(new Rectangle(0,0, bufferWidth, bufferHeight), 0x00000000); prior to do any draw).

Correct, mr_malee. I did this:

PHP Code:

---

addTroop = function() {
    if (walkingInfantry.length==1) {
        if (suggestedY<=walkingInfantry[0][1]) {
            walkingInfantry.push(troop);
        } else {
            walkingInfantry[1] = walkingInfantry[0];
            walkingInfantry[0] = troop;
        }
    } else if (walkingInfantry.length>1) {
        for (j in walkingInfantry) {
            w = walkingInfantry[j];
            if (suggestedY<=w[1]) {
                walkingInfantryHalf1 = walkingInfantry.splice(0, j);
                walkingInfantryHalf2 = walkingInfantry;
                walkingInfantryHalf1.push(troop);
                walkingInfantry = walkingInfantryHalf1.concat(walkingInfantryHalf2);
                return;
            }
        }
    } else {
        walkingInfantry.push(troop);
    }
};
for (i=0; i<100; i++) {
    troop = [-50, 290+random(20), random(infantryClip.anim._totalframes)+1, 3+Math.random()*5]
    addTroop();
} 


---

Long story short, it checks the _y position I'm telling the troop to spawn at, and sorts it into the appropriate place in the array based on that value. The for..in loop goes from the last element in the array to the first one, so the higher the index of the element is, the lower down that troop will be on the battlefield.

And no, MVolmaro, I'm not sure about it. But I cleared the buffer at the end of every frame with that script, so even if it didn't start off with an alpha channel, it would've had one by the second frame.

In any case, draw() is a lot easier to use. CopyPixels() I was using for about half an hour before I got it putting the troops in the right place (translation matrices are a lot easier to use than the Point object, and you don't have to specify how much of the area you want to copy, or what coordinate to start copying from, when you're using draw()).

And about the instantiating objects thing - I'd already worked that one out on my own by the time I was writing the buffered test. :)

Is it good or bad that my pc pushed a stead 25-30 fps for both test? lol

Very cool Veng. The bitmap one ran at a steady 10FPS and the movieclip one ran about 15 then to about a 22 when they started to get off the screen then back to 18 when they were gone.

ImprisonedPride, it's not unheard of. One other guy I know had an equally fast computer, which was able to handle both at optimum speeds.

Walsher, I think you're playing the wrong version. The bitmap one should be running up to 4 times faster than the movie clip one, rather than being slower. You probably clicked the links in my first post, rather than the ones later on in the topic. Try this bitmap test instead:

http://www.birchlabs.co.uk/InvasionBuffered.swf

Far, far, FAR faster than the InvasionOptimized file you were probably on.

no kidding....not sure what kinda of computer you're all running, but I run both at 29/31 fps constant.......so I was really suprised to hear people are getting only 10 fps??!....or so on them.......I'm running a 2ghz laptop with 1 gb of ram.......

I'm running on a Mac. That's my excuse.

Ya, that was my bad. Was playing the wrong file. The new was playing alot fast now

Squize,

Didn't I go through this with you last time there was a BitmapData thread, actually blitting to BitmapData is slow.

Vengeance, if you want the fastest way, store the graphics of the sprite as BitmapData, and use attachBitmap().

I made an example previously, ParticleEffect was made by Squize, blitting sprites onto a BitmapData the size of the screen. ParticleSystem is simply BitmapData MovieClips.

Quote:

---

Originally Posted by iopred

Squize,

Didn't I go through this with you last time there was a BitmapData thread, actually blitting to BitmapData is slow.

Vengeance, if you want the fastest way, store the graphics of the sprite as BitmapData, and use attachBitmap().

I made an example previously, ParticleEffect was made by Squize, blitting sprites onto a BitmapData the size of the screen. ParticleSystem is simply BitmapData MovieClips.

---

this is an interesting way of doing it....I can see the difference in speed....but I'm curious, using this method, how do you deal with animated/multi-frame sprites then?......do you create a bitmapdata through which you load every graphic frame of a sprite, and pass it on to/into an MC that will then cycle through them bmpdata frames??.......

just curious :)

paul.

You could do it a few ways, have the sprites and cycle them, through attachBitmap() and forcing it onto the same depth. Or you could attach a large tile sheet bitmap and use scrollRect to change its position for the frames (this is the method I currently use)

"Didn't I go through this with you last time there was a BitmapData thread, actually blitting to BitmapData is slow."

Mate, you should know how stubborn I am when I have an idea rattling around my head :)

The performance wasn't too far off, but yeah having to double buffer the sprite holder mc and all the other painful stuff that went with it stopped me trying to optimise it any further. Also 2 days out of a 30 something day dev time is more than enough for an experiment :)

"Or you could attach a large tile sheet bitmap and use scrollRect to change its position for the frames (this is the method I currently use)"

Hmmm that feels like it's going to be quicker than my method of just constantly attaching a bitmap at the same depth. May give that a bash too.

Squize.

That method works really well, but it completely screws with the width and height property of the MC, so (at least in AS3) I just override the width/height getter/setter and send out the width/height of the scrollRect instead. Also it's dead fast :)

Quote:

---

Originally Posted by VENGEANCE MX

I'm running on a Mac. That's my excuse.

---

With your last file i'm getting between 25 and 32 fps (seems to be stuck at 25 but jumps at a regular interval, something like every second, up to 32)

2x2Ghz, 10.4.8, safari of course i want a Mac Pro anyway

Quote:

---

Originally Posted by iopred

Or you could attach a large tile sheet bitmap and use scrollRect to change its position for the frames (this is the method I currently use)

---

I think I know what you mean, but I'm not 100% clear on it....do you mean, load the tile sheet with all the sprite frames as a bitmap, attach it to an MC, and then, within that MC using scrollRect with a window size to move the tilesheet/bmp around to show the correct fram for the sprite??

if you could post an example of that, it would be great :)

also I wonder how that would work with the bitmap.hitTest method....meaning if when hitTesting it against say another sprite to find pixel-level collision, it would take into account the entire bmpdata Sheet, or just what's in the scrollRect window........haven't had the chance to test it so I'm thinking out loud.....but was curious if you looked into that....

thanks,
paul.

I don't like the idea of making a sprite sheet for everything, but it would make a lot of sense, and also be an easier way of solving the 'synchronized march' issue that the troops have (since with this method I can only have them being on the animation frame that the buffer uses).

It's still not going quite as smoothly as I want it, so I think I'll try the spritesheet thing when I get some more time. Should be fun. :)