Currently I have a local script that moves the character using SetPrimaryPartCFrame on RenderStepped. I believe this is an improper way to do character movement, but I am not sure what the proper way is.
As I understand it RenderStepped will slow down if the player’s computer cannot complete the calculations in time, meaning players with slow computers will move with less speed. I want the character’s actual speed to be consistent on all devices. Heartbeat also seems to be unreliable depending on the system running the code.
Is there something I can do with tick() or os.time() for this? It seems like I could distribute the movement across the time that has passed, but I’m not really sure how I would create number that could easily be used in calculations?
You can normalize the speed with time by applying the delta time between frames.
How the physics logic would work:
newPos = currentPos + (directionVector) * speed * delta)
newPos = currentPos + (velocity * delta)
How to get delta between frames if you don’t already have it:
local lastTime = tick()
local currentTime = tick()
local delta = lastTime-currentTime
lastTime = currentTime
--physics logic here
BindToRenderStep’s callback function receives a delta time (dt) as its only parameter.
Thanks, this is what I was looking for. Just wondering though, how do I determine a normal length for the frame? It seems like it would be easier to use if I could divide and get a number that is “normally” 1 for the delta. Hope it makes sense what I am asking, it seems like if I use just the delta my velocity will get distorted.
The exact opposite is true. If you always use the calculated delta, the velocity will not be distorted. By using the delta, you ensure that over a period of time the player will always travel the same distance. Always use an accurate delta; do not use an average.
You usually run frames as fast as you can. Roblox rendering tries to step at 60 frames a second, which means that deltas are usually 1/60.
The more frames per second, the smoother the experience is for the user. As long as you use the amount of time between the current frame and the last frame, your physics velocity calculations will scale properly to account.
Stable acceleration on the otherhand require some calculus and derivatives. I am not sure how they work myself. I tend not to worry about this though because it is usually not a big deal. If you are making an extreme precision based game, you could framelock your game by defining delta instead of calculating it.