We need to figure out what the various time streams are (real time (ntp), engine time, game time (edited to be slower/faster/adaptive sync/etc)).
We would also want a delta time equivalent set of time streams, such as an un-smoothed delta time.
This is just a random question I had today (11/05/22), but a serious question that needs to be answered at some point. Actually, it is 3 specific questions, annotated below:
Currently, I believe game time is determined via a relative distance to a fixed point in time (the "genesis" I think the clock class calls it). This fixed point in time is the wall clock time at the point the clock module is initialized upon engine startup.
If you recall back to a couple streams in the past where we tackled the problem of having a custom debugger hook that tracks how much time the execution of the game has been paused for, so we can throw some maths at the clock update to account for it. This way we don't get problems with interpolating frames (player stuck in walls, etc).
The questions that I would like to answer are:
Is this game time being relative and prone to out of sync errors what we want?
and as a follow-up,
What are the alternatives with their advantages and disadvantages over the current method?
Please read the following:
Consider that, for example, the Lisp (SBCL) garbage collector stops the world. This might be for a few nano/microseconds once in a while, and even more when streaming in scene zone content by loading in assets at runtime. All these small and large pauses add up to what I would say is "significant enough" for there to be game time/real time clock drift, for the average gamer's play-time; especially if this rolls over into serialized game save state.
So possibly, by the way we define how game time is calculated, currently seems to be broken for any use in most real games. Of course, this is just an assumption, and I'd love to be proven wrong. But it still begs the question of:
What other ways can we do it to mitigate drift and other accuracy issues?