How to set NullEngine timeStep, missing from options?

Questions
1

Trying to setup NullEngine with deterministicLockstep (which is present on NullEngineOptions), but there doesn’t seem to be a way to set the timeStep?

2

FWIW: for now doing this as workaround, letting timeStep also control render interval:

class MyEngine extends NullEngine {
  constructor(options: NullEngineOptions & { timeStep?: number }) {
    super(options);
    if (options.timeStep) {
      this._timeStep = options.timeStep;
    }
  }

  protected _queueNewFrame(bindedRenderFunction: any, requester?: any): number {
    return setTimeout(bindedRenderFunction, this.getTimeStep()) as unknown as number;
  }
}
3

cc @sebavan

4

Yes you are right, Do you want to make a PR for it @pjoe ? or I can do it if you prefer ?

6

Should be a fun little PR to add timeStep to NullEngineOptions, lemme see if I can find some time :slight_smile:

Btw. what do you think about having an easy way to control the render interval in NullEngine? At least in my use case it doesn’t make much sense to have it render at the default 60 FPS.

7

FWIW: found out setTimeout is wildly inaccurate in node.js, came across this article, so now doing:

  protected _queueNewFrame(bindedRenderFunction: any, requester?: any): number {
    const delay = this.getTimeStep();
    const start = performance.now();
    let update = () => {
      const remain = delay + start - performance.now();
      if(remain < 16 && remain > 0) {
          setImmediate(update);
      } else if (remain > 0) {
        setTimeout(update);
      } else {
        bindedRenderFunction();
      }
    };
    update();
    return 1;
  }

Seems to work much better :slight_smile:

8

You should double check the perf as you would go in the function every ticks, also the else part seems to be missing the timeout value ?

9

Yeah as the article also mentions, there can be some CPU overhead with using setImmediate. From testing at my tick rates it seems promising.

The else part executes when remain is <= 0, as in time to call the callback :slight_smile:

10
2 Likes
12

FWIW: After getting this to run on a “real” server (linux, arm64), it turned out that there, the setImmediate is way too much overhead and just plain setTimeout is precise enough :slight_smile: