The document for move_and_slide() states: "linear_velocity is the velocity vector in pixels per second. Unlike in move_and_collide(), you should not multiply it by delta — the physics engine handles applying the velocity."
Doesn't move_and_slide() already handle the _velocity parameter with delta again inside the function? The way it is currently, aren't we technically using delta twice? Once in _velocity.y += gravity * delta and again within the move_and_slide() function. Or am I understanding it wrong and move_and_slide() doesn't apply delta? But why does the function documentation say that "you should not multiply it(linear_velocity) by delta — the physics engine handles applying the velocity?"
Gravity is 500 and delta from _physics_process() is 0.016667.
500 * 0.016667 = 8.3335
So what would be the difference if we just set the gravity value to 8.3335 and just use _velocity.y += gravity? (assuming move_and_slide() handles the velocity with delta in some way inside the function)
Or is it the opposite: That we have to multiply gravity * delta because move_and_slide() can't handle delta for us inside its function?
You must understand the difference between ACCELERATION and VELOCITY.
Velocity is how much movement there is at any one moment in time. It is calculated as units per second.
Acceleration is how much the velocity changes at any one moment in time. It is calculated as units per second per second (or per second squared.)
To represent that constant increase from gravity, we add one "per second" by multiplying with delta, and move_and_slide provides the other for the change it enacts on velocity.
If we used 500 directly, the character would float downwards like a leaf in the wind at a constant 500 units per second, which is not how gravity works. A falling body accelerates downwards over time.
It's a matter of making units match.
Gravity is an acceleration in pixels per second squared.
Velocity is a speed in pixels per second.
The gravity applied every frame causes a change in speed. But to integrate it into our velocity, as the units don't match, we want to multiply it by a time difference to turn it into a speed difference.
what would be the difference if we just set the gravity value to 8.3335 and just use _velocity.y += gravity?
In many cases you wouldn't see much difference.
However, delta is not a fixed value, even when you use _physics_process: while the engine does it best to keep the physics process delta time constant, you can change project settings that affect that duration.
Then, when you run code inside _process, the delta time is different every frame. So if you forget to use delta inside _process, your code will become frame-dependent as opposed to time-dependent.
Have you ever seen games where, when the framerate slows down, the character and everything else moves slower too? That's something that happens when you don't use delta.
Lastly, move_and_slide() applies delta to your velocity because you give it a velocity (a speed in a given direction) and it needs to convert it into a motion in pixels for this frame.
Hope this makes sense.
Okay, so I think I understand now, the idea is:
1. var gravity: float = 500.0 by itself is just pixel distance. Distance = 500.0
2. func _physics_process(delta: float) -> void: This updates whatever's inside this function every 1 physics frame, in other words 1/60 of a second based on Project settings and works with delta.
3. delta grants the element of time when used to multiply and keep things independent of system performance.
4. _velocity.y += gravity * delta
5. gravity * delta or 500 * 0.016667 = 8.3335. This combines distance and time and gives us speed. Speed = 8.3335
6. _velocity.y gives us direction. Direction combined with 8.3335 speed gives us velocity: Vector2(x, 8.3335) which is a down direction. Velocity = 8.3335 pixels/physics frame(with delta) and down direction.
8. += and move_and_slide() grants acceleration and gives the second component of time(delta) and modifies velocity into acceleration.
Acceleration = 8.3335 p/pf squared in the down direction or 8.3335 pixels/physics frame squared in the down direction.
All this just to simulate real gravity which is 9.8 meter/second squared where as I have 8.3335 pixels/physics frame squared.
Hopefully I'm at least pretty close to the ballpark.
That's not quite it.
Here are the things you didn't nail yet:
Gravity's not a distance, and move_and_slide doesn't deal with or produce any acceleration. Lastly, the gravity we use inside the game is arbitrary and has nothing to do with the real world. We're just trying to get something moving down. You could increase or lower the gravity, all that matters is that your game character feels good to the players.
You mixed up the notions of acceleration and motion a bit:
Thank you for clarifying. I'm in much better shape now! =)