Many off-screen instances cause slow down

0 favourites
  • 12 posts
From the Asset Store
Is a circular loading screen with code ready to use. No Animation.
  • This might be an old question. so I want you guys give me a suggestion:)

    So the situation is:

    -My layout is farely big.

    -There isn't too much on-screen objects but it can be about 400-500 instances in the whole layout.

    -I tried use tiled-background as much as possible but for the graphic quality I can't reduce sprites anymore.

    -I also have many invisible tiledbackground objects for cheaper collision.

    -the averange FPS on ipad 1st gen is 20fps, iphone 3gs is 15 fps (with cocoonjs). it has no problem on PC.

    so should I trying to cut my map into several layouts? or is there any way can help?

  • you may want to post your capx so we can see how to best help.

  • Are you using iOS 6? It's a lot faster.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I found that happens with one of my games on the iPad2 and only the iPad2. I'm not sure what it is, but it might be related to objects bordering the layout.

    I'm not sure exactly what the condition is, but with 400-500 objects something is forcing it to slow down.

  • The ipad 1 and iPhone 3GS are very under powered. Can they even run iOS 6? I seem to recall hearing that they can't, which means from my tests means you're getting about 33% less performance as a result compared to iOS 5. I don't know how many fps are possible to get out of those. You can check for what's causing the slowdown by backing up your project, then deactivating batches of code like the collision detection or making objects invisible and watching what it does to the frame rate. Common performance problems are caused by collision detection and overdraw (too many pixels being drawn per frame, a background with a sprite on top of it means those pixels get drawn twice).

    You could run a test deleting objects in the layout, and if it helps, then splitting it into more layouts might be the way to go - or you could code it to dynamically create and delete instances based on their distance from the player, or you could bug rexrainbow to write a plugin to do that for you, since he's considering making one that does that already. :)

  • Thanks for lots of helping!

    BluePhaze: my capx is kinda of complex now and I used several custom plugin/behaviors in it so you might not able to open it:/ But I take some screenshot to explain it:

    This is the layout. As you can see I have many sprites obj block out the level in stead of tiledbackground, because sprites have image point so I can use them to generate visual objects, and sprite can be scaled up so it will make some blur effect I need.

    <img src="" border="0" />

    <img src="" border="0" />

    Ashley : I have iphone 3gs on iOS 6, ipad on iOS5(6 is not supported )

    Arima : I tried your suggestion and set most objects to invisible, the framerate doesn't change too much, but a little more stable. Is there anyway to test on-screen overdraw? because I do have several overlay from foreground to background.(I even have a full-screen overlay for gradient effect)

    And thanks for the suggested plugin, I will try it out:)

  • Well, the plugin doesn't exist yet, I meant that rexrainbow mentioned possibly making it. If you set pretty much everything to invisible and it didn't really affect fps, then rendering is likely not the problem. Go on to disabling parts of your code, like collision detection, and see what that does to the framerate.

  • It's a logic performance problem, every sprites with collisions more than 50 objects per layout in runtime COULD lag.

    If there are 400-500 instances, the performance goes hell.

    CocoonJS is a renderer performance, not logic performance, I hope Rexrainbow is making new plugin like auto-save/load instances outside a range, it's more like memory managment.

  • Thanks guys for the explain and help! I have tried disable all collision for object movement, such as pushout solid thing, it doesn't help. I also use the same event sheet in another empty map, it runs double the fps. so I guess it might still because of too many objects cant handled by 3GS's weak CPU.

    But here is an idea: On the start of layout, can we remember all the instances location,rotation and other properties, save it into database, then destroy them when off-screen, and create them when on-screen? The InstancesBank seems can make it but I don't know how to spawn instances according to on/off-screen:/

  • I am working on a level editor where the plan is save the canvas arrangement to an array and then save the array.

    But I haven't gotten that far yet to show any code.

    The problem with my code is that I will push to the array:

    "For Each Instance Order By Instance.Zindex ascending"

    so that when it put them all back, they would be in the correct Zorder.

    You would have to sort by X maybe, or make an instance variable labeling which column they belong to, and you could draw that column offscreen as your character approaches.

    --I have a game that checks the FPS every couple seconds, and if it's below 25 twice in a row, it starts "destroying" extra scenery.

    Edit: to clarify the column idea, your character is touching a block that's instance variable says it is in column 5. So if column 2 and column 7 aren't drawn, draw them. (if headed right, column 2 would have been drawn already, and column 8 would get drawn.)

    Then you would also destroy any Column 1 and column 9 instances.

  • Paradox, I'm looking forward to it:)

    Some progress here:

    I have tried solved the issue by dynamically destroy instances off-screen and re-create them in appointed position. But ironically this way seems cost more cpu because of lot of looping.

    So I tried to cut off instances to 300-400, it looks slightly worse, but the framrate is acceptable now:)

  • I have had similar problems in some of my games when there are large scrollable levels. It can be seemingly quite random slowdowns in framerate that then pickup back again. Haven't really been able to totally pinpoint the source, as sometimes recreating the level and changing object layers has resolved it.

    Seems mainly related to collision detection. For instance, a bullet object that has a collision event on a large scrollable level has caused massive slowdown in chrome/ie10, but when I get rid of this event, the framerate is back to normal.

    Are collision events being calculated for all objects in a layout or just visible ones? I have tried coding it so that it is only seen via " is in layout" but it didn't make much difference. Are collision events more efficient when they are on the same layer, or is this irrelevant?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)