Performance upgrade suggestion for setSimulationInterval

[Lumyo]

setSimulationInterval is using setInterval causing a fixed delay timer, once the callback has been called.
If the computation is not heavy inside the callback, this isnt really an issue, but when the computation is heavy, the timer will still be applied fully after the callback evaluation is finished.

So if your update logic takes for example 20ms, and your simultation interval is set at 50ms,

Delta time = 20ms (computation time) + 50ms (fixed delay) = 70ms

It could be a significant performance upgrade to have an adjusted value for the timer as:
delay = simulationInterval - computationTime
(And even just not have any delay when computationTime > simulationInterval)

Here is the result of a test I made with the 2 solutions, with a target of 20 updates/s (50ms)

Here is the code used for the test :
https://gist.github.com/Lumyo/394382f4af628686b81345c5bb3c1a4c

@endel I would be interested to have your thoughts on this.

[Elyx0]

Can tick B finish before tick A if computation of A is super long/buggy?

[LeakedDave]

Thanks for this. I noticed an inconsistent FPS in my server.

[LeakedDave]

Can tick B finish before tick A if computation of A is super long/buggy?

I'd hope tick B cannot run until tick A completes.

[Lumyo]

Can tick B finish before tick A if computation of A is super long/buggy?

I'd hope tick B cannot run until tick A completes.

It can't, in both case

[hunkydoryrepair]

It is very common for this type of adjustment to be made in a simulation engine. But it still gets behind, so next step is to average over several frames and can "catch up".

If a single frame update takes 3-4 frames to complate, you get some lag, but the following frames may be quick, and it can be better to call them rapidly in succession so that you catch up.

In practice, this approach eventually fails. Most games I've worked on do this in the update itself. The simulator should determine where it should be at that time. If it misses a frame, the simulator should use time differential to basically run itself twice (or more), with the system providing a type of "heartbeat" with the update calls.

For colyseus, it not only has to run the simulation frames, but the find the changes and propagate to the clients. If the simulation loop dominates the thread (node.js being single threaded) everything else breaks. It can't starve the network and schema update tasks.

One possible solution would be to have Colyseus provide a "frame #" parameter. Based on the last call to setSimulationInterval, it would basically take (currentTime - startTime) / interval to provide the update with a means to know if it should take multiple steps.