Author Topic: Large numbers of FlxBlocks  (Read 2381 times)

Titch

  • Contributor
  • ****
  • Posts: 270
  • Karma: +0/-0
  • Thing with the guy in the place.
    • View Profile
Large numbers of FlxBlocks
« on: Tue, Dec 15, 2009 »
Curious about how many FlxBlocks people have put on screen before it started to cause significant slowdown. I'm thinking about doing a vertical moving tunnel digging game (you have to dig and built upward to escape) and was wondering if I could fill a couple of screens with them (like say 2 lots of 640x480 screens at 1:1 resolution and 16x16 tiles, so 2400 tiles) without significant slowdown. I would like to maximise the amount of space the player can work with, so some kind of value at which it becomes a big problem would be nice.
Free cake whippings every day at #flixel on irc.freenode.net.

Markham

  • Guest
Re: Large numbers of FlxBlocks
« Reply #1 on: Tue, Dec 15, 2009 »
Do you plan on running collision or overlap checks on them?

Titch

  • Contributor
  • ****
  • Posts: 270
  • Karma: +0/-0
  • Thing with the guy in the place.
    • View Profile
Re: Large numbers of FlxBlocks
« Reply #2 on: Tue, Dec 15, 2009 »
Well I can cull out some of the collision checks, probably. I could narrow the per update collisions to the boarder bricks around the cave (as in take 2 tile thick boarder around everything and just check that, that would take a lot of time to update, but would only change when the shape of the map changed. I could consider not moving anything that is offscreen, but that might lead to some nonsensical behaviour from the players perspective.
Free cake whippings every day at #flixel on irc.freenode.net.

Markham

  • Guest
Re: Large numbers of FlxBlocks
« Reply #3 on: Tue, Dec 15, 2009 »
I don't know about displaying, but I do know that you want as few objects in the collision loop as possible.  My current Flixel project, at one point, was checking around 200 blocks against one player and 30 enemies in the average level, and was getting a significant slowdown even with only a fraction of that onscreen at a time.  Even after I reduced the amount of blocks in the collision array to a fifth of that, it was still slower than desired.

I would suggest making a custom object that extends FlxBlock that takes in the array you want to use for collision detection as a parameter in it's construction, and has functions to add "neighbors" for the tiles to it's left and right and above and below.  When the player digs it out, the object removes itself from the collision array and adds any neighbors that still exist to that array.

How you order the arrays in the FlxG.collideArrays function affects performance, too.  The first parameter should be the array most likely to have the most "dead" objects in it.  I do this for colliding enemies with the environment.  The reason is due to how FlxG runs it's collision loop: if an object in the first array is not dead, it runs another loop that checks that object with every object in the second array.

xmorpher

  • Member
  • **
  • Posts: 39
  • Karma: +0/-0
    • View Profile
Re: Large numbers of FlxBlocks
« Reply #4 on: Wed, Dec 16, 2009 »
maybe you could use the onScreen function/property
to reduce the number of iterations to calculate

i.e: you could avoid the animation statements if the sprite is not on screen
(if (onScreen) { select and show sprite animations... } )


btw, you could do a benchmark testing the number of sprites
that start to slow down the game or drops the FPS a lot...
and sharing the results over here if you want
 :)

fefranca

  • Guest
Re: Large numbers of FlxBlocks
« Reply #5 on: Wed, Dec 16, 2009 »
« Last Edit: Wed, Dec 16, 2009 by fefranca »