DoubleStyx
commented
3 weeks ago For sync mode, what would it mean if we set some arbitrary threshold? Then it prevents you from using sync mode when the framerate is low, which isn't necessary.
Maybe sufficiently high thresholds can be used to indicate sudden events like world loads?
For async mode, what would a threshold mean? Async lets Resonite stay up to date or Unity reuse states. It doesn't really need a threshold. We'd want to use async over desync when we can't use sync.
For desync, it allows Resonite updates to trickle through as well as allowing Unity to keep rendering even if it has work left to do. This seems like the best place to use a threshold, I think, since desync only handles very sparse events.
We need to at least "add" a threshold to handle sparse events. A threshold for sync doesn't work since it defeats the purpose of syncing.
A threshold for async doesn't work since it defeats the purpose of batching.
So maybe just use a threshold for desync. In almost all cases you'd want to use async. Only in <1 Hz (where the game becomes a still-life and the illusion of a lively world is lost) would you want to accept half-states on either the Resonite generation side or the Unity processing side.
Right now, the way the auto mode behavior works is that the update rate is estimated based on an exponential moving average. This helps to prevent premature mode switching from random hiccups. Though I do wonder if perhaps we should also just have it give up if it takes too long regardless.
For example, the desync mode does almost nothing because the only times where it's actually used are in one-off cases, and the EMA can't notice this fast enough.
So we need to either combine the EMA and threshold approaches or just use thresholds.