Nope, I would always have the enterFrame listener running. add the event listener at the start, remove it at the end (if you are using Composer or similar), and control what events happen using flags.
So if everything is driven by your single eventFrame listener, you can pause everything by just having if isPaused then return end at the start of the listener (for example).
Excellent. I see what your saying there.
Remove the listener on leaving the scene, and use “pause” flags to fire off what’s in the functions yeah!? Won’t that have more of a drastic effect on performance though?
Probably not, it’s only being called 30 times a second.
There’s an old rule about 10% of the code being responsible for 90% of the performance. For this 10%, sometimes, you have to write tricky code. But for the 90%, it’s always better to go for clean and simple code, even if there is a slight performance hit.
I read somewhere someone did some speed testing between the two ways of calling functions in lua - straight and oop
myFunction(32) myObject:myFunction(32)
and it came out as something like 5ms in 10s of time, i.e. it doesn’t matter. Usually code that causes the problems is O(2) code. So if (say) you check for collisions and you are checking everything against everything else, that can be slow because for 10 objects there’s 100, but for 33 there is 1,000 and so on.
I’d always code for simplicity and clarity and then optimise it. The risks with Corona are usually about trailing event listeners and object references.
Ok one more question :lol: (for now)
So would you have a seperate runtime listener strictly for checking the flags (say if I had about 6 or 7 of them) would I make a separate function that was called every frame and contained a bunch of if statements in it to check the flags (true or false) sort of thing? Instead of simply once in the scene will show (for example), if I wanted to constantly be checking the flags?
example:
function 1 ()
function 2 ()
function 3 () etc…
function listener ()
if flag1 = false then
function1()
elseif flag1 = true then
function2()
end
if flag2 = false then
function3()
elseif flag2 = true then
function4()
end… and so on
end
in the create scene:
Runtime:addEventListener( “enterFrame”, listener )
in the hide scene:
Runtime:removeEventListener( “enterFrame”, listener )
Thanks for all the help - I appreciate it.
Wow thats a poorly written example - but I think you can get what I’m asking LOL
Actually - I think you already answered the above question - I just had to re-read it again.
Cheers!
You made some great points I just discovered about paulscottrobson. The reason I have so many timers is this. I have ‘turrets’ which fires projectiles. The turret gets created by a function when needed with a timer like this;
autoTurret.destroyTimer = timer.performWithDelay(autoTurret.lifeTime, destroySelf, 1)
And than I do the necessary removal things. And when game is paused I pause that timer, and resume when resumed. The projectiles the turret fires also has these timers, they spawn with a lifetime and a timer. And sometimes there are 50+ projectiles on-screen and all needs to be paused. I can now see why this might be a huge liability when it comes to being reliable. How do you advice I approach managing all these without timers?
Well, you can’t, because pausing this timer will just stop it being destroyed.
I’d write a class, or a module, which spawns the projectiles, thus it ‘knows’ about the projectiles (by keeping a list). The module can then send the projectiles positional updates (e.g. update display.x,display.y) and delete them based on their own personal timer. You can then control whether these timers are updated or not. It can also delete them all if you want. This can be driven by just one enterFrame() or timer, if you prefer.
I would add that this is in some ways counter-intuitive to Corona which does sort of encourage this glue together by the seat of your pants approach. There are some advantages to this, for example the approach I describe means you can’t use the physics module. The downside is the lack of modularity and compartmentalisation.
I see, thanks for the input. I guess I can’t use it because projectiles actually heavily dependent on physics, lots of bouncing etc. I’m yet to test this on a device but I hope it will work similar to simulator. Do you know if timers may cause any performance issues that I can’t see on the simulator?
Shouldn’t do. (It may be possible to ‘stop’ the physics engine, I haven’t used it much). There is a basic problem that an iPhone or an Android phone just isn’t that fast compared to a PC. The thing to do is try it before you’ve written too much code, just the core is working. It is worth having an old phone just to check these things, or a really cheap Android tablet.
I made my first test on an s4 mini and it is… not very good. While almost nothing is happening I get an avg. of 55fps but when I have a few turrets and a few bullets it drops to ~20. It is not that noticeable while playing (some lag spikes does occur) but fps counter doesn’t lie! This is not really about the timers tho, I have ~100 objects with physics bodies colliding, I think that is the problem.
It is sad to see Corona SDK can’t handle this. Or perhaps it is bad coding? I would say not because when the turrets gets destroyed fps goes back up to ~55…
For performance reasons, it is better to create a pool of objects and re-use them, as opposed to a destroy/recreate cycle.
So perhaps create a pool of bullets and turrets, and when you “destroy” them, instead of removing them, you just move them off screen, set them to invisible and disable their physics bodies until you need them again.