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
@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
Most helpful comment
On a related note: it seems odd that
deltais not applied consistently to themove_andfunctions. Either they should both do so, or not.