move_and_slide is not smooth w/ high refresh monitors

[ghost]

documentation for this says

linear_velocity is a value in pixels per second. Unlike in for example move_and_collide(), you should not multiply it with delta — this is done by the method.

• if you don't use a delta, movement is different from going to a 60hz monitor and then a 120hz one.
• if you do use a delta, your movement becomes a bit jittery because you have to use a high number (for example: with 170 speed, you'd have to use something like 17000). however, the speed does stay somewhat the same across different monitors. way better than no delta

the documentation is telling you not to use a delta, but this is kind of bad because w/o a delta given, the movement is vastly different from 60hz to lets say 120hz.

while looking at #15060, i also see something in: physics_body.cpp:

godot/scene/2d/physics_body_2d.cpp

Line 1018 in 53a2b0a

Vector2 motion = (floor_velocity + p_linear_velocity) * get_physics_process_delta_time();

@poke1024 can you take a look here if you got time as well?

would changing this to how you changed the camera2d be a possible solution, or is this something else?

[ghost]

actually, i'm going to compile this right now using get_process_delta_time() instead. will report back!

[ghost]

yep, it fixes it! movement takes the same amount of time going from point a to point b, on my 120hz monitor as it does when switching to 60hz.

not sure about repercussions of this change, but i think at least developers should implement an option to use process or physics process for their internal delta. because a lot of gamers are using high end monitors nowadays, having the same movement across them is ideal.

in fact, if you are a game developer, you'd want your game to run the same on all monitor types really.

[bojidar-bg]

@girng You are supposed to use _physics_process to move, not _process. Maybe it should just detect which process it is running in, and use that delta, similar to how Input.is_action_just_pressed() does it.

Guess I might make a quick PR a bit later. 😃

[ghost]

@bojidar-bg problem is, if you use physics_process to move, it uses the 60 fps default delta (0.0167), which creates the jitter issue for higher refresh rate monitors. you must use move_and_collide for movement inside _process, for it to work on all refresh rates ^^ (and use get_process_delta_time())

e: btw, thx for response. glad this is seeing dev attention. very important i feel.

[bojidar-bg]

Just to mention the counter-problem, if you use _process to move, then your simulation is frame-rate dependent unless you know and apply calculus.

P.S.: Nice you are saying thanks here and there, it helps create a less-toxic atmosphere, even if it isn't widely practised

[ghost]

@bojidar-bg np, if you are taking time to help my issue, i will give respect. it's very appreciated, same for poke's camera PR too! if it also can help game developers, it's a win win in my book.

well, i tried physics_process to move on my 120hz monitor, and it's very jittery in the background. but if i use _process it's not. im not sure what you mean by frame-rate dependent as i don't know what else to do. im just trying to make the jitter stop haha.

as of right now though, if you use the movement in _process and use get_process_delta_time(), the time it takes for your character to move from point A to point B is the exact same with a 60hz and a 120hz monitor (i tested it!) that's very good

[Dar13]

Perhaps there just needs to be a way to update the physics framerate based on the monitor? That could get tricky because it seems to be a project setting. Maybe add a boolean saying to scale the physics update frequency based on the detected display rather than setting a global physics framerate.

@girng Does setting the Physics Fps in Project->Project Settings->Physics->Common to 120 fix the jitter on your 120 Hz monitor when using _physics_process?

[akien-mga]

The plan outlined by @reduz is to have adaptive FPS: you define in your project settings a range of refresh rates to support (e.g. from 60 Hz to 144 Hz), the OS API will query the monitor's actual refresh rate and adjust the physics framerate accordingly.

It should solve 98% of use cases at no cost. Any more advanced work on physics interpolation will have to be assessed afterwards if/when there's a need.

[Ranoller]

The plan outlined by @reduz is to have adaptive FPS: you define in your project settings a range of refresh rates to support (e.g. from 60 Hz to 144 Hz), the OS API will query the monitor's actual refresh rate and adjust the physics framerate accordingly.

It should solve 98% of use cases at no cost. Any more advanced work on physics interpolation will have to be assessed afterwards if/when there's a need.

This is now possible in gdscript or I´m wrong?:

1. Turn On Vsync
2. Performance.get_monitor(TIME_FPS)
3. Engine.set_iterations_per_second( Performance.get_monitor(TIME_FPS))

Is that? I do that (a bit complex that explained, with median values and roundings...) and don´t have any jitter (by physics, stutter "car demo kind" is other problem)

[ghost]

@Dar13 yep, it does.
@bojidar-bg i understand what you mean by frame-dependent now. If using movement code in _process, and if your game starts lagging and losing fps, movement will be distorted. I guess that is why using physics_process is very important. my apologizes for misunderstanding you at first