Hundreds of Entities with no lag?

[DavidHan]

Hi. if you've ever played Coinbox Hero (great game), you'll notice that there are literally hundreds of coin entities on screen at a time with gravity and collision, but there doesn't seem to be any lag. How did Jmtb02 accomplish this?

Is it in the code? Is his code super efficient? Is it the way he displayed the coin graphic? What is the most efficient and processor friendly way to display graphics, especially for something that doesn't change, like a coin?

I am interested, because I want to rain down lots of blocks in my game. All they need to do is fall at a constant velocity, then if it detects ground, it snaps into place. right now, I think My code is as efficient as it can get, with ONE hittestPoint function and some math to figure out where its final landing zone will be.

If at all you have any experience and have tips on performance management with lots of entities, please comment. Right now, I'm seeing frames drop from 60 at around 80-90 entities.

[MintPaw]

I've wondered this too, they're all vector art too hence quality options modifying them.

[MSGhero]

At 3/1/13 12:04 AM, MintPaw wrote: I've wondered this too, they're all vector art too hence quality options modifying them.

Stage.quality affects bitmaps as well, just not as noticeably from what I've tried. It might just be toggling smoothing or something, though.

BitmapData and blitting is the way I've been working with for a while now. You could have thousands of entities with no lag (if the rest of the code is optimized as well). You use the copyPixels function of bitmapdata to copy and paste other bitmapdata (image file data is a bitmap/bitmapdata) to one central one and display that. Animation is just pasting the next frame in the animation over the previous one. The problem is that it doesn't support rotation or scaling, so you'd either have to have the rotated or scaled image as another part of the image file, or you'd have to use the draw function of bitmapdata, which is slow and will give bad performance with a lot of entities.

[MSGhero]

For clarification, this is an example of a spritesheet that you'd copy pixels from. It doesn't have to be organized into rows and columns like this one, but it makes finding the rectangle that contains the image much easier.

Each row is an animation in this case.

[Fooliolo]

At 3/1/13 12:14 AM, MSGhero wrote: The problem is that it doesn't support rotation or scaling, so you'd either have to have the rotated or scaled image as another part of the image file, or you'd have to use the draw function of bitmapdata, which is slow and will give bad performance with a lot of entities.

Or you could just have the base image to keep download small, expand the original bitmap, tell the user's computer to render rotated/scaled copies of the image once (loading screens, yey!), and then blit it just like any other blittable image. You'll want to use the matrix class to do the rotation or whatever other fancy transformation you want.

[OmarShehata]

You could always PM him and ask. I'm sure he'd love to shed some light on his efficient coding techniques.

[GeoKureli]

MSGhero is correct, it involved drawing bitmaps to a stage bitmap. The idea is that Flash's native displayObject classes have a lot of fluff in there for rotation and scale and whatnot that it uses a lot of memory. if you guys haven't messed with http://flixel.org/ I would recommend it.

[DavidHan]

At 3/1/13 09:58 AM, ImpotentBoy2 wrote: MSGhero is correct, it involved drawing bitmaps to a stage bitmap. The idea is that Flash's native displayObject classes have a lot of fluff in there for rotation and scale and whatnot that it uses a lot of memory. if you guys haven't messed with http://flixel.org/ I would recommend it.

I've tried flashpunk, and I really like it, but there was one big thing that keeps me from using it. The art making workflow and limitations are just too much. Especially as I like to do my art myself, I really like, and am used to the flash IDE workflow where I could draw something, then press control + enter and see it immediately after. Also, it allowed me to nest mc's inside each other to have custom gear and whatnot. Creating and exporting new sprite sheets was just really annoying.

Anyways, back to the main topic, is selecting "export as bitmap" the same as blitting? Also, since the graphic of my block can easily be drawn with the as3 drawing tools, would that be less intensive than a bitmap image? All i need is a square with a solid fill.

[DavidHan]

At 3/1/13 09:58 AM, ImpotentBoy2 wrote: MSGhero is correct, it involved drawing bitmaps to a stage bitmap. The idea is that Flash's native displayObject classes have a lot of fluff in there for rotation and scale and whatnot that it uses a lot of memory. if you guys haven't messed with http://flixel.org/ I would recommend it.

I've tried flashpunk, and I really like it, but there was one big thing that keeps me from using it. The art making workflow and limitations are just too much. Especially as I like to do my art myself, I really like, and am used to the flash IDE workflow where I could draw something, then press control + enter and see it immediately after. Also, it allowed me to nest mc's inside each other to have custom gear and whatnot. Creating and exporting new sprite sheets was just really annoying.

Anyways, back to the main topic, is selecting "export as bitmap" the same as blitting? Also, since the graphic of my block can easily be drawn with the as3 drawing tools, would that be less intensive than a bitmap image? All i need is a square with a solid fill.

[MSGhero]

At 3/1/13 06:50 PM, DavidHan wrote: Anyways, back to the main topic, is selecting "export as bitmap" the same as blitting? Also, since the graphic of my block can easily be drawn with the as3 drawing tools, would that be less intensive than a bitmap image? All i need is a square with a solid fill.

Well, blitting is actually pasting the images onto the stage; but using bitmaps is a start.

It's not necessarily the complexity of the shape that makes blitting faster, it's that the cpu doesn't have to do as much. Vector images, like your square and solid fill, require math to move, rotate, and scale.

Also, when flash renders everything, it will take time to try to display everything that's addChilded. So your entire huge background is getting math-ed around. Each of the fifty squares all on top of each other are all getting rendered even though you can only see one. With blitting, it only renders once. CopyPixels is fast enough that it's not a problem compared to rendering. So you'd copyPx a chunk of the big background and all fifty squares, but only the bitmap gets rendered instead of 51 different things.

[DavidHan]

At 3/1/13 07:06 PM, MSGhero wrote:

At 3/1/13 06:50 PM, DavidHan wrote: Anyways, back to the main topic, is selecting "export as bitmap" the same as blitting? Also, since the graphic of my block can easily be drawn with the as3 drawing tools, would that be less intensive than a bitmap image? All i need is a square with a solid fill.

Well, blitting is actually pasting the images onto the stage; but using bitmaps is a start.

It's not necessarily the complexity of the shape that makes blitting faster, it's that the cpu doesn't have to do as much. Vector images, like your square and solid fill, require math to move, rotate, and scale.

Also, when flash renders everything, it will take time to try to display everything that's addChilded. So your entire huge background is getting math-ed around. Each of the fifty squares all on top of each other are all getting rendered even though you can only see one. With blitting, it only renders once. CopyPixels is fast enough that it's not a problem compared to rendering. So you'd copyPx a chunk of the big background and all fifty squares, but only the bitmap gets rendered instead of 51 different things.

Cool. Does export to bitmap do the same thing?

Also,the memory is only at 9~ (kb?) when the lag starts dropping. All of my graphics right now are placeholders, so theyre just solid rectangles.

Does high memory = low fps?
does this mean that the problems are in my code?

[GeoKureli]

At 3/1/13 10:35 PM, DavidHan wrote: Does high memory = low fps?
does this mean that the problems are in my code?

its possible. I know flash punk was designed in a way similarly to flixel, so I'm going to talk in terms a flixel, assuming that there is some kind of equivalent in flashpunk(I haven't used flashpunk but I hear good things)

I had a game with like 50 coins on screen and I would call flixel's collide() function on each of them, the result was a laggy game. all i had to do was put all of the coins in a FlxGroup and call collide on the group, and it stopped lagging and still told me which coin was hit. the group wasn't a layer or displayobject, it was just a kind of array but the main event of the flxGroup was the quadtree, which organizes its children by location. so when I call hero.collide(coinGroup); the collide function only tested coins "fairly close" to the hero, causing my lag to completely disappear. look into flashpunk's quad trees if they exist. if not google it and make your own, its just a bunch of abstract tiles grouping the objects by location.

[prexen]

Collision detection / spatial partioning and a rendering efficient pipeline.

For collision detection a simple grid to place the "coins" to reduce pairwise tests.
The rendering, if you are going for performance forget movieclips / sprites. Use copypixels in a bitmapdata. Ive never seen anything as fast as copypixels in a software render.

With those two you can get a LOT (place a more than a lot here) of stuff on screen. The physics arent really an issue in the game you mentioned.