Drop this into a module somewhere. Call startTimer() at the start and then place a few stopTimer() calls at random places in your code and it will print the execution time in ms. It is a real simple way to time blocks of code.
I’ve found this real helpful in finding slow code blocks.
local startTime = nil function startTimer() startTime = system.getTimer() end function stopTimer() local elapsedTime = system.getTimer() - startTime print("Time = "..elapsedTime.." ms") endThank you very much for your help and the code!
local check=false GameLoop = function (event) if check==false then check=true -- CODE HERE check=false else -- ENTERED AREA check=false else end
Here is a part of the code from the – CODE HERE area above:
for x=#Weapons,1,-1 do if Weapons[x].active==true and Weapons[x].isVisible==true and Weapons[x].lockedOnEnemy and Weapons[x].shootingAllowed==true and \_G.paused==0 then if not Weapons[x].freqTimer then -- we only shoot if we are not still rotating this weapon: -- allow shooting if we have the rotation of the weapon finished: if not Weapons[x].transTo then shootAtEnemy (Weapons[x]) -- shooting as long in given Frequency as it is in range else -- here we are if we have a rotation towards an enemy -- we check if the current aimed at enemy is visible and in case not we set back the target for this weapon if Weapons[x].lockedOnEnemy and Weapons[x].lockedOnEnemy.isVisible==false then Weapons[x].lockedOnEnemy=nil end end end end end
It is the shootAtEnemy function which on a slow device is making the GameLoop enter the ENTERED AREA (see code above!). In the simulator or a fast device the ENTERED AREA is not getting entered at all.
The shootAtEnemy function is first checking if the weapon is still active before creating bullets, moving the bullets towards enemies and doing collision checks for the bullets with the enemy or other enemies.
Is there a way to running the GameLoop on the slow device using shootAtEnemy without entering the ENTERED AREA? Or how can I make sure the stuff happening in shootAtEnemy is NOT delaying the GameLoop?
As Ed said there is no way gameloop can be called whilst it is already being executed. that would imply multi-threading and Corona is single-threaded.
In other words the first execution of gameloop will always finish before a second execution can start.
So if I get this correctly the code NEVER should be running the ENTERED AREA part from above, right?
Mhhh…
BTW: I’m showing admob banner ads on top of the screen.
Okay… I now have found the issue with the code:
On device (where an ad is shown) I’m using a global to store the height of the banner ad. In the module handling the ShootAtEnemy function I still had a local with the same name… resulting in the value not known causing a hidden runtime error in ShootAtEnemy. Because the rest of the game was running on and continued the error was not an eye catcher and I only found it after looking through all the log output for the device. At first I didn’t think of an error at all because the whole game continued playing.
Thank you all for your help!!!
I use an underscore for globals… for example _W, _H store the actual pixel width and height which I often use for dynamic UI placement.
If I accidentally declare a local W they will never clash. Some devs use G_ or other schema. Choose one that works for you really - save a LOT of headache
this is the perfect example of why to avoid globals! (not to mention they’re also accessed via the slowest possible mechanism)
my go-to recommendation is Niklas Frykholm’s GLOBAL_Lock , then wrap it in a conditional to only run in simulator (cuz not worth crashing a production version if a global leak still makes it through testing, as maybe it’s of the “harmless” variety)
tho a caveat/gotcha is to first include composer (since it includes physics, which leaks a global “physics”) before locking. (there are a couple other corona libs that also leak, ottomh “crypto” is one, but don’t recall them all - if you discover one just include it prior to lock)