Is there somthing wrong with pausing, resuming timers?

Solar2D General Questions/Discussion
#1

Hello,

   I was having this weird weird problem with my game. When I pause my game and than resume, sometimes it started to act weirdly. Like most of the moving stuff kept working but some touch listener for example stopped working, and some functions based on an objects position didn’t trigger. And after 4-5 seconds all the functions suddenly triggers that did not trigger for the past 5 seconds. So the problem was not on pausing, it was on resuming.

   I tracked down the problem and turns out it was because I was pausing and resuming some timers. I now use something like this when pausing;

local timeleft = timer.pause(sometimer) timer.cancel(sometimer)

   And when resuming I re-create the timer;

sometimer = timer.performwithdelay(...)

 This does solve the problem but I felt like letting you guys know. The mentioned timers are a lot (like 50), that’s why it might be giving the game a hard time. And I was experiencing this on the simulator, didn’t have chance to test this on any device.

#2

So I guess you’re saying that timer.pause(someTimer), followed by timer.resume(someTimer) can cause issues?

I’ve never seen it in any of my apps, although I only use a handful of timers at a time.

It’s good to see you’ve found a workaround, but if you have a repeatable test-case, I think it would be a good idea to make an official bug report.

#3

Is there a reason you’re doing:  pause, cancel, create vs. pause, resume or cancel, create?

It’s possible that when you pause the timer, we are setting some value in the table returned by timer.performWithDelay and when you cancel it with out nil’ing it out, the remaining data might confuse things.   I would only use pause, resume in pairs or cancel, performWithDelay in pairs.

Rob

#4

@Rob

The way I interpreted his post was that pause, resume is causing problems for him, and that he found a workaround by using pause, cancel, create instead. But I may be wrong…

#5

You are probably right Ingemar.  We do need a reproducible test case.

#6

Yeah ingemar got it right. If I do pause than resume, unexpected results occur. I then use timer.pause() because it returns the time left, and I’m using it to set a new timer. I’ll try to prepare a test code to be reproducible but I don’t have high hopes because it is so unstable I don’t understand when exactly it happens, it will just work sometimes. I can of course send my whole project tho, you can see it happen with changing few lines there.

#7

The whole project won’t help because we will spend hours trying to figure your code out and we really cant afford the engineering resources to debug your project.

Rob

#8

Generally, timers and so on are problematic. It is difficult to know in what order they will fire and so on. 

Timers can be quite useful for frilly little bits, but in game core it is better to do it as a centralised timer event system, driven by one core timer event, and rather than (say) stop and resume timers, set a boolean to ignore them.

#9

@paulscottrobson

Hi;

" it is better to do it as a centralised timer event system, driven by one core timer event, and rather than (say) stop and resume timers, set a boolean to ignore them."

Is there a tutorial somewhere that deals with this or an example maybe I could look at?

Cheers!

#10

I actually wouldn’t use timers at all in the core code, but rely on the enterFrame() event. Timers can be used for little one offs - make a bang sound in 0.1s, draw this little bit of graphic fluff, but for managing core game events, you can end up with all sorts of complex interplays that are undebuggable because you can’t reproduce them. Only my opinion though.

#11

Yes I think I have encountered this type of behaviour before… thus my interest in the subject.

OK Thanks for the reply, I will look into it more.

Cheers!

#12

So if I wanted to do something every few seconds for instance, it would be something like what is discussed in the post below right!?

http://coronalabs.com/blog/2012/02/21/understanding-coronas-enterframe-event/

#13

I would do something along those lines. It’s more about centralising the code that does similar sorts of things. If you have objects starting timers and sending messages to each other … asking for trouble.

#14

Yes very interesting, it never occurred to me - to use the enterFrame() event in a “timer” type of way.

I am going to try that and see what affect it has on performance. 

Cheers.

#15

So let me run this by you… for instance:

If FPS is 30 then a half second timer would look like this basically:

local framesPassed = 0

– enterFrame listener function
local function trackTime( event )
  framesPassed = framesPassed + 1

  if framesPassed >= 15 then
 

    --do something here

    framesPassed = 0
    – stop tracking time
    Runtime:removeEventListener( “enterFrame”, trackTime )
  end
end

–everytime I wanted to run the “timer” again I would use this
Runtime:addEventListener( “enterFrame”, trackTime )

So would something like this work as a timer? Or am I wrong? I think timers are easier to use and keep track of, however, more control over the firing of a function is appealing for me to avoid “all sorts of complex interplays that are undebuggable”.

OR

Maybe I just need better debugging skills? LOL

Cheers.

#16

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).

#17

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?

#18

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.

#19

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.

#20

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!