Godot-proposals: move_and_slide should not implement delta on its own

Created on 13 Jul 2020  Â·  8Comments  Â·  Source: godotengine/godot-proposals

Describe the project you are working on:
Zelda 2 recreation game

Describe the problem or limitation you are having in your project:
I have documentation on zelda2 physics based in the NES's original 60 fps.

the move_and_slide function of KinematicBody2D implements delta time on its own making the values I use far too slow.
I tried dividing by delta before passing but that doesn't work either and makes my player fly off screen

I also tried doing move_and_collide but due to the zelda2 physics of applying gravity every frame regardless if I am on the ground or not makes the player unable to move on the x axis

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
just remove the delta time implementation and have us multiply it ourselves
this makes code not only clearer but make it much more flexible for different types of games

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
just remove the delta time multiplication from the move_and_slide function

If this enhancement will not be used often, can it be worked around with a few lines of script?:
it would certainly be used by me and any other person trying to recreate a beloved game

Is there a reason why this should be core and not an add-on in the asset library?:
its already in it just needs to be separated

physics

Most helpful comment

On a related note: it seems odd that delta is not applied consistently to the move_and functions. Either they should both do so, or not.

All 8 comments

@Shadowblitz16 Thank you for the suggestion. The delta is used to convert velocity into distance moved during that frame. It is implemented the way it is in the move_and_slide() function, because it needs to use it to also calculate the distance the platform the user is standing on moves and adjust the player's movement accordingly.

making the values I use far too slow.

I'm not sure what you mean, but move_and_slide() takes velocity as it's first parameter; so the speed of the body is controlled by changing the size of this vector not by adjusting delta.

I tried dividing by delta before passing but that doesn't work either and makes my player fly off screen

Dividing the velocity by delta is the same as multiplying the velocity by 60 (or whatever you've set the physics Fps to); so yes, the body will fly off the screen.

Finally, there is a lot of work planned for updating the physics interface in Godot 4, including changing move_and_slide() to make it more user friendly; so I'm closing this proposal for now.

@madmiraal you are misunderstanding this. He's suggesting that move_and_slide should not automatically grab the physics delta, but should instead be left to the user to multiply the provided velocity by the physics delta themselves so that it is consistent with move_and_collide. I know that the physics system will be getting a revamp soon, but IMO, this is still a valid criticism and one that should absolutely be addressed in the redesign.

@madmiraal jonbonazza is correct.
Not only is it inconsistent but it forces the user to use delta time to use kinematic body collisions.
Now most of the time delta time is a good thing and should be used.
However when trying to recreate the physics from a 90s system which wasn't frame rate independent its makes it impossible to simulate the exact physics.
not only that but framerate independence should be strongly encouraged not required.

@madmiraal please reopen this.
this is a very big issue forcing us to use delta with kinematic bodies

@Calinou can you or one of the godot devs reopen this?
this is a valid suggestion and I feel it was closed for the wrong reasons

@Calinou Thankyou very much ♡

On a related note: it seems odd that delta is not applied consistently to the move_and functions. Either they should both do so, or not.

I would prefer not as it allows more control over our own game's physics

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Dorifor picture Dorifor  Â·  3Comments

aaronfranke picture aaronfranke  Â·  3Comments

SleepProgger picture SleepProgger  Â·  3Comments

WizzardMaker picture WizzardMaker  Â·  3Comments

SpyrexDE picture SpyrexDE  Â·  3Comments