Lately, more and more computation limit errors happen on games, even for games that were previously released that was not having them, or not having them that frequently.
Obviously non-existent of computation limit errors, doesn’t mean your game isn’t missing frames.
This is mostly about async computations taking long time before releasing the context, (before sleeping).
A common thing we do is to sleep a frame or so in fixed intervals at loops that we ‘think’ that might take some time. For example we might be doing a frame of sleep at each 20-50 loops, on some async loop that were doing some work on maybe hundreds of props, (since usually doing things that have effect in game, instead of data stuff takes more time).
Or a better thing is to track the time passed in the loop, using ‘GetSimulationElapsedTime’, and if it’s taking greater than some target time, do a Sleep.
Here is the problem: In both cases, we don’t actually know how much time we have left for the frame. I might sleep if the execution takes more than some time T0, but maybe the time left for the entire frame was T1, where T0>T1, so I miss the frame no matter what. Or it was T1>T0, but they were close so it missed the frame later anyways.
So even though these kind of stuff are helpful. They are really suboptimal. A really easy fix is to just give us the time left for the ‘targeted’ frame end time. This would allow us to do sleep in our code, independent of the server tick rate as well.
So a simple api function of (with nanoseconds precision):
GetTimeLeftForFrame():float=
So we can do stuff like:
for():
…
doing some compute
…
if (GetTimeLeftForFrame() <= SomeMinTime):
Sleep(0.0)
We can also assist this with a simpler to use api function:
IsAboutToMissFrame():logic=
Which I’m guessing, natively this function can be written wrt considering the dynamically changing runtime properties, instead of just doing:
if (GetTimeLeftForFrame() <= SomeMinTime):
Because it could estimate, depending on where you’re at the frame, how much time the left computation will take. And comparing it to the actual time left, instead of doing a comparison to a fixed time.
These would help us a lot to make our games better and miss much much fewer frames. And the good thing is, the first api call is extremely easy to implement, an intern could do it. The second could take some time, depending on the programs ability to oversee the computational state and estimate what’s left.