Performance tips for a lot of transitions?

[c.noeth]

I already started a thread on how to save memory doing a lot of transitions. You can find it here:

https://forums.coronalabs.com/topic/63862-saving-system-memory-doing-a-lot-of-transitions/

But now I encountered another problem doing a lot of transitions: Performance!

Things really slow down when I have to move around a lot of objects on screen (with transition.to calls).

When a lot of transitions are active moving an object via a touch listener is lagging for example.

I have the following scenario. I show some explosions on screen which will trigger around 50 to 150 objects to move on screen. But I have to move also 4 objects for each of the first moved objects… so I can get to a max of a few hundred objects really fast.

Now I’m looking for the best way to do this transitions with high performance. Are there any best practices or “hints” on how to improve performance for this kind of animations?

Later in the game there also will be a lot of enemies and attackers and bullets…

Thx for your help!

[roaminggamer]

You’re using transitions to simulate the movement of objects as a result of an explosion?  Why not use physics?

It sounds like you’re trying to handle all of the physics work with transitions.  This is not the right approach, especially if you have physics bodies involved.  Then you’re adding even more work for the engine/SDK.

[c.noeth]

@roaminggamer

You’re using transitions to simulate the movement of objects as a result of an explosion?  Why not use physics?

It sounds like you’re trying to handle all of the physics work with transitions.  This is not the right approach, especially if you have physics bodies involved.  Then you’re adding even more work for the engine/SDK.

I’m not using physical correct movements, but create a “wave” effect which is influencing (moving) the path corners of small images. For each image there are four corners to move.

I have physics in the game, but only to place some stuff on a map, detect non-circle and non-rect bodies by a sensor and things like this. I don’t want to use the physics engine too much beside this, because I think it will also make performance trouble. My idea was to use the physics for the described collision detection and smooth movements by using a touch-joint and then using transitions and non-physics collisions detection (circle-circle) for the rest of the game.

And I can’t use physics on object.path corners like the x1,y1 to x4,y4 values, right?

[roaminggamer]

Ah, I see.  Yes.  Transitions (although associated strongly in people’s minds with visual effects like scaling and movement) are really useful in any context where you want to control/modify a field value on an object over time, using a known algorithm/easing.

Are you sure that the ‘transition’ code is the culprit in your slow down? Are you adding other active code for every object you add?  i.e. do yo increase the execution load (excluding transitions) for each new object?  more enterframe listeners, more loops, etc.?

[torbenratzlaff]

I would say it simply comes down to the number of mooving objects. I experience the same issue with particle system, where the framerate drops when a certain amount of mooving objects is reached.

I don’t know if it comes down to how draw calls are handled in Corona (as you have no real control over it in comparison to other engines like Unity), but it may be, that the only thing you can do, is reducing the amount of used objects.

[anon63346430]

Just a thought… Are all the graphics you are trying to transition from the same atlas?  If not then placing them in one large imagesheet will decrease the draw calls and help performance (a bit).  I have a similar issue in my game with hundreds of images moving - simulating fireworks for example.

It would be great if corona was multi-threaded to handle scenarios like this.

[c.noeth]

I really checked a lot in the past hours and it comes back to the moving object count and active transitions count at one moment.

The objects I’m moving are created circles and image path corners of small images which I get from one huge image I “cut” to small images using an image sheet.

I’m looping through a raster of the circles to check if they are inside a “blast” radius before starting to move them by a transition.

When I detect an already transitioned circle I use transition.cancel to “stop” it’s movement and start a new transition for the circle. (same for the image path corners).

[anon63346430]

Maybe we are pushing coronas openGL pipeline too much?  In my game I have a game area of 100 x 100 tiles where each tile is a display group with a few layered retina graphics.  On top of that I have hundreds of objects being animated with transitions (I tried enterFrame but it made no difference).  I just can’t maintain a solid 30 fps and have to settle for 10-30 fps depending on device and zoom level.  I’ve optimised my run-time code as much as possible but the limit is in the draw calls.

I tried making all of my graphics as atlased but that actually ran slower and caused memory errors on lower end devices so I dynamically load images on demand.  When I tried atlases it created 20 x 16MB imagesheets which was a huge memory overhead.

Is your game released yet - would like to see it.

[torbenratzlaff]

Are the “circles” you are using images or created by display.newCircle?

If its the second, try using images instead. I experienced performance issues with great amounts of circles and rects in my particle systems. By using images instead I was able to improve performance a bit.

[roaminggamer]

You’re using transitions to simulate the movement of objects as a result of an explosion?  Why not use physics?

It sounds like you’re trying to handle all of the physics work with transitions.  This is not the right approach, especially if you have physics bodies involved.  Then you’re adding even more work for the engine/SDK.

[c.noeth]

@roaminggamer

You’re using transitions to simulate the movement of objects as a result of an explosion?  Why not use physics?

It sounds like you’re trying to handle all of the physics work with transitions.  This is not the right approach, especially if you have physics bodies involved.  Then you’re adding even more work for the engine/SDK.

I’m not using physical correct movements, but create a “wave” effect which is influencing (moving) the path corners of small images. For each image there are four corners to move.

I have physics in the game, but only to place some stuff on a map, detect non-circle and non-rect bodies by a sensor and things like this. I don’t want to use the physics engine too much beside this, because I think it will also make performance trouble. My idea was to use the physics for the described collision detection and smooth movements by using a touch-joint and then using transitions and non-physics collisions detection (circle-circle) for the rest of the game.

And I can’t use physics on object.path corners like the x1,y1 to x4,y4 values, right?

[roaminggamer]

Ah, I see.  Yes.  Transitions (although associated strongly in people’s minds with visual effects like scaling and movement) are really useful in any context where you want to control/modify a field value on an object over time, using a known algorithm/easing.

Are you sure that the ‘transition’ code is the culprit in your slow down? Are you adding other active code for every object you add?  i.e. do yo increase the execution load (excluding transitions) for each new object?  more enterframe listeners, more loops, etc.?

[torbenratzlaff]

I would say it simply comes down to the number of mooving objects. I experience the same issue with particle system, where the framerate drops when a certain amount of mooving objects is reached.

I don’t know if it comes down to how draw calls are handled in Corona (as you have no real control over it in comparison to other engines like Unity), but it may be, that the only thing you can do, is reducing the amount of used objects.

[anon63346430]

Just a thought… Are all the graphics you are trying to transition from the same atlas?  If not then placing them in one large imagesheet will decrease the draw calls and help performance (a bit).  I have a similar issue in my game with hundreds of images moving - simulating fireworks for example.

It would be great if corona was multi-threaded to handle scenarios like this.

[c.noeth]

I really checked a lot in the past hours and it comes back to the moving object count and active transitions count at one moment.

The objects I’m moving are created circles and image path corners of small images which I get from one huge image I “cut” to small images using an image sheet.

I’m looping through a raster of the circles to check if they are inside a “blast” radius before starting to move them by a transition.

When I detect an already transitioned circle I use transition.cancel to “stop” it’s movement and start a new transition for the circle. (same for the image path corners).

[anon63346430]

Maybe we are pushing coronas openGL pipeline too much?  In my game I have a game area of 100 x 100 tiles where each tile is a display group with a few layered retina graphics.  On top of that I have hundreds of objects being animated with transitions (I tried enterFrame but it made no difference).  I just can’t maintain a solid 30 fps and have to settle for 10-30 fps depending on device and zoom level.  I’ve optimised my run-time code as much as possible but the limit is in the draw calls.

I tried making all of my graphics as atlased but that actually ran slower and caused memory errors on lower end devices so I dynamically load images on demand.  When I tried atlases it created 20 x 16MB imagesheets which was a huge memory overhead.

Is your game released yet - would like to see it.

[torbenratzlaff]

Are the “circles” you are using images or created by display.newCircle?

If its the second, try using images instead. I experienced performance issues with great amounts of circles and rects in my particle systems. By using images instead I was able to improve performance a bit.