Problem with initial tpf value in AbstractGameSystem

Ali_RS · January 22, 2018, 11:52am

Hi
Here is a tpf log (in seconds) read from SimTime in a system extending com.simsilica.sim.AbstractGameSystem

TPF=8182.538884095001
TPF=0.099026717
TPF=0.017426786
TPF=0.016636905
TPF=0.016667920000000003
TPF=0.016666875
TPF=0.016665305000000002
TPF=0.01666629
TPF=0.016667735
TPF=0.016666895
TPF=0.01666555
TPF=0.016666615000000003
TPF=0.016668095
TPF=0.01666517
TPF=0.01666679
TPF=0.016747479000000003
TPF=0.01666693
TPF=0.016668335

why the first tpf is so huge ?

Edit:

I have a Timer class which gets updated with SimTime and the above issue cause timers to not work properly.

Of-course I can hack it to just refuse the first update or re-base it to use System time. But beforehand I am curious to know why this is happening.

pspeed · January 22, 2018, 12:59pm

I hit this problem recently also.

It happens because the ‘start time’ that is used for the delta is initialized early or something… or is default to 0. It’s sort of a bug. I don’t remember how I resolved it.

Ah… found it. It was in the anarchy sandbox. I added an if( time.getFrame() <= 1 ) return to the beginning of my update.

The issue is as suspected, time is initialized to 0 so the first frame that gets an update of the current nanoTime will be pretty huge. It’s a bug in the way SimTime is initialized by the GameSystemManager. Essentially, during start() I guess there should be a time.update() call.

If you are really adventurous you could try that and submit a PR if it works. Else if you file a problem report I will hopefully remember to take a look at it.

Ali_RS · January 22, 2018, 1:24pm

So you are saying we should add

if( stepTime.getFrame() <= 1 ) 
    return;

after this line, Yes?

github.com

Simsilica/SiO2/blob/747216b53cdd0edbc49d88a3f32593ca3bb41371/src/main/java/com/simsilica/sim/GameSystemManager.java#L284


 *  Updates the current SimTime and calls update on all of
 *  the systems.  It is up to the application to periodically
 *  call this method, either by setting up a GameLoop thread or
 *  by calling it in an AppState or other parts of the application's
 *  normal update loop.
 */
public void update() {
    try {
        // Update the step time...
        long time = System.nanoTime(); 
        stepTime.update(time);
        
        // Update the systems.
        for( GameSystem sys : getArray() ) {
            sys.update(stepTime);
        }
    } catch( Throwable t ) {
        log.error("Error updating systems", t);
        // Treat this as a fatal error... systems should
        // handle their own errors otherwise
        EventBus.publish(ErrorEvent.fatalError, new ErrorEvent(t));

pspeed · January 22, 2018, 1:32pm

No, that’s the hacky fix in your own code to avoid the issue. The proper fix in SiO2 would be to call update() in start().

Ali_RS · January 22, 2018, 2:12pm

Sorry not clear for me!
Again our systems will get updated with the malformed stepTime.

I think we should only update the simTime in start(), No?

I mean adding the following lines to start()

// Update the step time...
long time = System.nanoTime(); 
stepTime.update(time);

Ali_RS · January 22, 2018, 2:31pm

Or add
time = System.nanoTime();
to constructor of SimTime class and instantiate it in start() ?

pspeed · January 22, 2018, 2:43pm

Yes, that’s what I meant.

You have to do it in start() else you would similarly have problems if you stopped and then restarted the game system manager.

Ali_RS · January 22, 2018, 5:29pm

Thanks.

I made the PR