Timer smoothing improvement

I would like to add an improvement to LWJGLTimer: Long loading times or debugger breakpoints currently cause the tpf to be very high after the waiting time for some seconds, letting the application rush or stutter (esp. with physics). To compensate for this I added these lines locally:

if ( lastFrameDiff > 0 && frameDiff > lastFrameDiff*10 ) {
    frameDiff = lastFrameDiff*10;

It still adapts to truly high tpf exponentially but filters a single high tpf very well. What do you think - should this go into LWJGLTimer? Or should I make a subclass?

This is somewhat related to this issue.

i had the problem with the my app rushing after loading occured. it this would help fixing such a behavior it would be very nice.

i'm not sure about where it belongs tough. can you think of situations where one wouldn't want to filter high tpf's out?

The timer right now is unusable for anything that has serious differences in framerates… at least not in my experience. This should make it easier to debug when you use it though… and debugging when you're learning jME or just toying around a bit with a SimpleGame is of course very important.

Anything that helps with this would be excellent, at the moment my game starts with the plane rushing about 5 seconds worth of flight forward, bouncing off a hill at high speed, and then stuttering into action some seconds later when it finally balances out. Mind you that might just be my fault :wink: I actually just ignore the first 5 seconds of "time" before I do anything, to avoid this catastrophic error :slight_smile:

Where are you adding that code, irrisor?

Maybe timer capping should be done by the user. jME coudl provide an external class to cap the timer with such algorithms, or at least that should be optional (Timer.setTimerCapping()?).

Access to the real timer could still be needed to gather network statistics (ping, etc…) though this might be solved in other ways.

Just an opinion, though.

@shingoki: to avoid such startup problems you can reset the timer after your loading is done

@jjmontes: the code was added to LWJGLTimer

And I agree that the application need more control over the timer than it currently has. So we need to add support for different timers plus develop a more configurable one.

More suggestions beside setTimerCapping (or setMaxFPSDelta, I'd name it)?

Im trying to implement a system to synchronize the server time with all clients. The reason is that a client may overclock the pc in order to try and give them an advantage over other clients.

For instance if 2 clients were in a race game, the overclocked would go faster.

Rather than to maintain a timer on each client which is maintaining standard game elapsed time, it would be nice to make small time adjustments to the JMe timer, that way all controllers and animation can be run as is.

Maybe a suggestion is to allow the time to be adjusted by losing or gaining small amounts of time each frame until the client clock is synchronised…

Any suggestions or thoughts welcome.

I think you should post this on the network board, theprism. It's not really related to this thread…

Irrisor, the issue is not how to test whether the clients time is slower or faster than that of the server, the issue is can the fps from Timer used by jme be adjusted and that adjustment not severly effect the scene graph

There was some mention of allowing creating of altenative timer implementations, it would also be nice to allow inheritance of them too.

If you still think this should be in a seperate topic, i'll move it. you were asking for suggestions of timers…

ah well, ok, didn't get that