timer/transition in loop lags question

c.noeth · May 30, 2016, 9:05am

I start moving some game enemies by using a “for loop” and then a timer/transition inside the loop.

Now I see a lot of enemy movement lagging going on in the simulator and wonder if this is normal and how to avoid it?

Here is a sample snipped of the code for the enemy movement:

&nbsp;&nbsp;&nbsp; local moveEnemy &nbsp;&nbsp;&nbsp; for x=1,enemycount do &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local enemynow=Wave[level][wave][x] &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local enemyObj=Enemy[level][wave][x] &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; enemyObj.isAttackable=true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Wave[level][wave][x].isVisible=true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- we now start moving the enemies by looking at their move and spawn speed in the info array! &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; moveEnemy=function(enemy,index) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- starting moving to waypoint one and then the next &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- we have to calculate the moving speed, so it stays the same for all paths &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- get distance between the first two waypoints &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- move so long until the last waypoint is reached &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; index=index+1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if index\<enemyWaypointCount and enemyObj.isAlive==true then &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local dt=getDeltaTime() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local dist=getDistance(EnemyWayPoints[index][1],EnemyWayPoints[index][2], EnemyWayPoints[index+1][1],EnemyWayPoints[index+1][2]) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local speed=dist\*5\*enemyspeed\*dt &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transitionStash[#transitionStash+1]=transition.to(enemy,{time=speed,x=EnemyWayPoints[index+1][1],y=EnemyWayPoints[index+1][2],onComplete=function() moveEnemy(enemy,index) end}) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; timerStash[#timerStash+1]=performWithDelay(enemyspawntime\*x,function() moveEnemy (enemynow,0) end,1) &nbsp;&nbsp;&nbsp; end

What is the best way to create a lot of moving objects on screen to get a good performance and movement of the objects?

horacebury · May 30, 2016, 10:04am

Have you tried checking the number and frequency of times that the moveEnemy is getting called? You almost certainly need to reduce the amount that the function is getting called.

c.noeth · May 30, 2016, 2:36pm

The enemy count in the sample is about 10 to 20. This should be working without any problems, right?

Can anyone tell from experience what is the best solution for moving a LOT of sprites on screen simultaneously? I can’t get the transitions to work correctly here and I have no idea why they are are lagging.

I have to move a lot of sprites to different positions on screen, means to different coordinates. Transitions would be perfect for doing this.

c.noeth · May 30, 2016, 3:10pm

I worked with daily build 2886 which was causing this massive transition.to problems in the simulator btw.

I now have tried it with build 2866 and now it is working!

Is this a known issue with the latest build?

torbenratzlaff · May 30, 2016, 6:19pm

There are several ways to do it. The fastest way would be to use a single enterFrame listener function and loop through all enemys to move them without any transitions involved.

As that can be very tedious (especially if you want to use easing for example) your approach is viable too and much easier to create as well. But there are some optimizations you should make to your code.

Move the “moveEnemy” outside of your loop. In the code above you create a new function every time (which is relatively slow), but there is no reason to do so. All variables needed can be provided by the functions parameters.
You are using staches to keep track of your timers an transitions (which is a good idea in general) but judging from your code, you never remove them from there. I don’t know how you manage these things outside of this specific function, but you should make sure, that only one transition is running for each object at any time.

These are my thoughts so far.

Personally I use the first method most times, as it provides me with the best performance and greates flexibility.

Greetings

Torben

c.noeth · May 31, 2016, 12:11pm

Thank you for your help! Much appreciated. Somehow I didn’t notice the function inside the loop… thx for this

rob · May 31, 2016, 4:23pm

This sounds like a regression bug. We are getting ready to start preparing for the next public build and we certainly don’t want to have an regressions. Can you create a simple project that demonstrates the problem and file a bug report. As soon as I have the CaseID from it, I’ll prod engineering.

It would be helpful to know which version this happened in. You can do a “binary tree search” type method to cut down the number of daily builds to test. You know it happens in 2886 and its good in 2866, so split the difference and try 2876. If 2876 is good split the difference again and try 2881. Follow this pattern until you’ve found the daily build where it broke. I didn’t see anything in the release notes that should impact this.

When filling the bug report, your project should have a main.lua, config.lua and build.settings. It should also have any assets needed to build and run the project. Knowing the build number where the problem starts will help us out a lot.

When writing the description of the bug, make sure to mention the last known good version. You will get an email with a CaseID in the subject. Please post that back here and I’ll make sure the team is aware of it.

Thanks

Rob

c.noeth · May 31, 2016, 5:22pm

I’ve submitted a bug report with some sample code… case 46204

BUT PLEASE NOTE: While creating the testcode I noticed it doesn’t recreate the problem 1 to 1. It also seems the delta time function is causing a lot of the lagging issues. It still looks like the build 2886 performance is not as good as the 2866 so maybe you want to give it a look.

horacebury · May 30, 2016, 10:04am