Attention | Topic was automatically imported from the old Question2Answer platform. | |
Asked By | Punpun | |
Old Version | Published before Godot 3 was released. |
Hey people.
I’ve been messing with the engine for quite some time, but I noticed I’ve been ignorant
to frame dependency till now. Most godot’s demos have it, so I tried giving a look at it, but I still couldn’t get it into my head. I even went through many articles, but it made me even more confused.
On my project, I move the player through a grid. Its a linear movement with a constant speed, so I do it like this :
#assign movement key
if Input.is_key_pressed(KEY_DOWN) && !moving:
total_movement = Vector3(0,0,2) #total transition
movement = Vector3(0,0,2) #current transition
moving = true #start walking loop
#moves player
if moving:
move(total_movement/32) #move by fraction
movement -= total_movement/32 #consume fraction from current transition
#if movement has been fully consumed, closes walking loop
if movement = Vector3(0,0,0):
moving = false
Although the code above is really rough, it is good enough to not leave any problems.
The player moves 0.0625 each frame, which is also subtracted from “movement”, that will become a perfect ‘Vector3(0,0,0)’ eventually, sinalizing the end of the cycle.
But this is a bad practice as it seems, meaning players with lower FPS will see the unit
walking at lower speeds and players with higher FPS will get higher speeds.
From what I understood, there two ways of making games framerate independents so FPS don’t determine physics actions:
-
Adapting all physics interactions to multiply by delta as an
damage control switch -
Fixing the Timestep
So following the first step, I went to integrate delta into all my loops, and as I got a good result, it didn’t last long. As more extreme FPS variations appeared, they broke the values and skipped conditions. So I had to create more functions and implement more equations to adapt my code to these variations, until I bloated the code, gave up and reverted it back.
Then I went on about the second step, that is almost spammed at every related question I found, but I really didn’t get it at all. It’s about decoupling the render from the physics and syncing it up in code. Couldn’t get the pseudo code neither other users versions. It seems that everybody read the same article and somehow got a different concept from it while explaining.
So I was wondering if someone with a good grasp on the subject could get an example in GD or some advice on what take I should use on the subject.
Any help is appreciated, thx!
References:
When should I use a fixed or variable time step?
motion calculations in games
Fix Your Timestep!
In _process(delta) or _fixed_process(delta) call move like this:
move(total_movement*delta)
The delta is the fractional time elapsed between frames, it’s like your 1/32 but it will be framerate independent.
davidoc | 2017-10-09 20:39
This is sorta what I did when I bloated my code.
You see, move(total_movement/32)
is frame dependent but it is precise, it will walk 0.0625 p/frame and consume the same value from movement, that is expected to go from Vector3(0,0,2)
to Vector(0,0,0)
in order to close the walk cycle.
Using the method you told however, it allows values other than 0.0625 p/frame, which leads to the total_movement
being divided by odd numbers and movement
also subtracted by those same odd numbers, thus never reaching the desired Vector3(0,0,0)
.
I could simply close the walk cycle using movement.distance_to(Vector(0,0,0)) <= .1
instead of movement == Vector3(0,0,0)
, however, at even more variable framerates, the delta control could skip this distance and bypass even this condition, and so on.
At this point is either making the game run some rocket sciency methods on the background or fixing the step… I think.
Punpun | 2017-10-09 22:30