@albertok interesting, I have the same - Forest Brawl is fine, my own game jitters. My first thought was that it's because Forest Brawl runs at a solid 240 fps, while the other game can vary at 50-60 fps, so maybe the factor was capped before the next tick could be simulated. This doesn't seem to be the case.

I'll look into it more, I'm suspecting it's something around NetworkTime.tick_factor.

@elementbound

Worked it out. Were skipping tiny bits of time by sampling the clock as interpolation is about to happen which leads to the jitter. Because interpolation is meant to calculate the difference between two rendering frames we need to pin the time at the start of the render frame and calculate from there consistently.

@albertok Nice catch! After some testing, I've noticed on my own game that there's still a small amount of jittering. I think this is due to my camera not being tied to the tick loop. If instead I do the same as in Forest Brawl ( update pos in _tick and use TickInterpolator ), everything is silky smooth. I think this is why we didn't see the issue in Forest Brawl originally.

The other issue is if you pause the game for a while - since we're using OS time - netfox will think the game is multiple seconds behind so it will simulate things as fast as it can. I'll see if we can catch the pause and do something about it.

Pinned the OS time at the start of the frame as suggested. Also added support for paused games through get_tree().paused, and a hacky way to detect if the game was paused from the editor. The latter only works in the editor, so hopefully the false positives shouldn't affect final builds.

For testing, I've tied my own game's camera to the tick loop and it works smooth!

@albertok would love to have your review on this!

@elementbound

Initial testing feels really good. There's no sense of lag/delay on local matches at all now and higher latency is also improved.