Is the godot engine reliable for counting frames?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Guliver_Jham

So, i had this engine in java that didn’t let the program be “frames behind” what it’s supposed to be, for example: if the game lost some frames (let’s say it processed 45 frames instead of 60 making it 15 lost frames), it would then compensate for it (for example by processing the 15 lost frames on the next second while still executing the full cycle making it 15 frames processed at the start of that second and 60 frames on the course of it).

Now i want to make the frame never slowing down (or at least compensating for slow downs) for the sake of netcode, that’s why this is so important, does the godot engine works in a way that compensates for lost frames/slowdowns?

I will have to respond to my own question on this one, no, this won’t do for this, it’s better to use some other approach.

First, no, it probably doesn’t always compensate, even if godot remedies slowdowns, if there’s a major slowdown max_physics_step probably doesn’t let it compensate fully. (probably because it doesn’t want the games to go slow motion for a second)

And second, i can expect a desync over time between systems if i use delta time since godot doesn’t use any form of determinism, it just shoves a float in delta and calls it a day.

Guliver_Jham | 2021-08-27 16:01

Godot’s physics engine is indeed not deterministic, but it doesn’t claim to be. Most games don’t need determinism after all :slight_smile:
Godot is a general-purpose game engine, but it happens that fighting games have specific needs that aren’t well-addressed by general-purpose game engines.

There are plans to make the physics engine more deterministic for 4.0, but it will never be 100% deterministic by default since there are too many compromises to make for that to happen. Due to this, if you create a replay system, you should make it store players’ transforms instead of players’ inputs. This also ensures engine/game updates don’t break your replays.

Calinou | 2021-08-27 16:12

I knew it wasn’t deterministic, but i didn’t know it was so far way, i will have to make a completely new network solution because of that, since the sdk i plan to do is meant to handle long periods of time.

I hope 4.0 really delivers something more close to it because modern fighting games or any multiplayer that actually feels like singleplayer relies on at least something close to determinism, the smallest difference makes the player quit.

Guliver_Jham | 2021-08-27 17:55

:bust_in_silhouette: Reply From: Calinou

Now i want to make the frame never slowing down (or at least compensating for slow downs) for the sake of netcode, that’s why this is so important, does the godot engine works in a way that compensates for lost frames/slowdowns?

Godot avoids slowdowns in this case if you use the delta parameter consistently in your _process() and _physics_process() functions.

I know what delta time is!

No, it’s a frame based netcode, it’s supposed to operate in fixed FPS, delta would result in it easely desyncing in some cases before the netcode could correct it, resulting in some visual innacuracy lasting 1 full second.

So the answer is it doesn’t?

Guliver_Jham | 2021-08-27 15:22