EDIT: this was on jme3 r7261
This is what I’ve done in my attempts to understand how the timer aka Application.timer field works in an attempt to solve the issue that my “game” goes fast for like 1 second after SWT window regaining focus(ie. alt-tab away then back, though I suggest clicking the taskbar then clicking on the window to restore focus, alt-keys are used in game and will trigger stuff) or when dragging the Window by the title (hold LMB to “pause” game(not a real sensed pause, I think) and after LMB release that fast thing happens)
I provide a link to a zip containing the entire folder in workspace of an eclipse project:
http://www.mediafire.com/file/i5u39eqyb1p0h1v/MessingWithJME3Timer.rar
Basically two boxes each using different timers:
- red box uses jme3’s normal
timer which has smoothness(the timer has this)
- purple box uses a non-smooth timer which also can be paused (and does so only when window loses focus, not when LMB on window title when dragging it (though this does pause the game in a way))
http://i.imgur.com/6oyyT.jpg
http://i.imgur.com/qEFEa.jpg
What I noticed is that the normal jme3 timer is slowing down when the time between frames is higher but when the it comes back it quickly tries and succeeds to reach where it should’ve been if the slowdown didn’t happen. I didn’t know this, but what I didn’t like about it is that it caused my game object(s) to move faster for like 1 second, and I’ve seen this behavior in Titan Quest IT when alt-tabbing back. If I use my timer I can pause the timer too when I detect alt-tab(aka lost focus) and works well for my needs… also I wanted to keep a constant speed of my game object even though the update couldn’t be called in real time, as you can see if you press LeftAlt the update gets some delays which causes lower fps but yet the purpleBox keeps wanting to go with the same speed, while the redBox slows down … but no worries the redBox quickly reaches the purpleBox when pressing LeftControl to reduce the delay/sleep
the purpleBox’s timer is bad at reporting the framerate, it can report temporary spikes in fps, unlike the jme3’s timer
Since I made this I might as well ask(though nobody should’ve read this far, sleepy mode on?!) how can I detect when the window is being dragged? ie. press and hold left mouse button(LMB) on the window title, this pauses the game but I don’t think anything in the game actually detects this (to ie. set the paused flag), though the game does detect loss of focus (ie. alt-tab away) and pauses the game(via flag)
PS: this is a work in progress still (code is as it is, didn’t clean it up)
(note, reader: you should probably not read all this garbage that follows, I need to learn to xpress my self)
Note that in jme3 r7264
https://code.google.com/p/jmonkeyengine/source/detail?r=7264
@Momoko_Fan (I think) fixed the speedup issue, adding timer.reset() right after focus was regained,
this seems rather ok and prevents that speedup though I would like to mention this:
after focus is gained, the “game” starts slower than normal and uses the next 32 frames (TIMER_SMOOTHNESS==32) to catch up to the normal speed (while before this fix it started fastest towards slower until catching up, using the same amount of frames, it now starts slower towards faster where fastest is the normal “game” speed)
here is the tpf (time per frame, ie. reported inside simpleUpdate()) from the time the window focus is regained:
[java]focus gained!
1.25E-4
5.3125E-4
9.3750004E-4
0.00134375
0.00175
0.0021562502
0.0025625
0.0029687502
0.003375
0.0037812502
0.0041875
0.00459375
0.0050000004
0.0054062502
0.0058125
0.0062187505
0.0066250004
0.0070312503
0.0074375
0.0078437505
0.00825
0.00865625
0.009062501
0.00946875
0.009875
0.010281251
0.0106875
0.011093751
0.011531251
0.01190625
0.012312501
0.01271875
0.013
0.013
0.013
0.013
0.013
0.013
0.013
0.013
0.013
0.013
0.013[/java]
the 0.013 tpf is the normal “game” speed, as you can see that is reached on frame 33 (due to timer smoothness)
This catchup is not noticeable, unless you have a delay in your simpleUpdate that sleeps X seconds, then it will take 32*X seconds for the timer’s tpf to catch up (in my project, in first post, LeftAlt to increase this delay in simpleUpdate)
====
and the following is the timer(tpf) after focus is regained and no timer.reset() is invoked (ie. without the fix) - this is when it used to speed up:
[java]focus gained!
0.053218752
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052937504
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.052906252
0.012687501
0.013
0.013
0.013
0.013
0.013
0.013
0.013
0.013
0.013[/java]
(hmm for some reason I remembered[wrongly apparently] that tpf would start fast then slow down on the course of 32 frames until it reached 0.013(in this case) the normal “game” speed, but it seems constant => the elapsed time is split in 32 calls to update as opposed to just 1 call when using non-smooth timer; though it’s not the entire elapsed time(ie. from paused until resumed) that is considered; the update calls are supposed to make the game catch up smoothly (32 steps) instead of just jump in 1 step(as seen in my project in first post the purple box does this))
Note that this speedup still happens(in the fixed code) in the case when for example you left click mouse on the window title bar (ie. drag window) and holding it pressed for like 1 second then releasing it…
