Speed of Motion (and related) components depend on the current frame rate

[starwed]

This is definitely on purpose, but I'm not sure it's a good idea. It seems like the perceived speed shouldn't depend on the target frame rate, but should respect the passed dt.

Maybe there's something I'm missing? Presumably @mucaho knows! :)

[mucaho]

The speed depends on the target frame rate (!= current frame rate if I understand correctly). You set the target frame rate with Crafty.timer.FPS. I thought it would be nice when you set vx = 1 you will move 1 px per frame (if the step timer is in non-variable mode). I based this on the premise that Crafty.timer.FPS would be set exactly once (for all clients of a game) and not changed individually for each client. But, now that you mentioned it, independence from frame rate was the goal of Motion PRs :) So lets just remove this and let vx = 1 be 1 px per frame just for the default, 50 fps situation?

[starwed]

So lets just remove this and let vx = 1 be 1 px per frame just for the default, 50 fps situation?

Yeah, the thing that should remain consistent is pixels per second, not pixels per frame. If you change the target frame rate or step type, you don't want to have to alter every object's speed just to keep the same in-game speed. (Especially important if you're using other components that run off dt, such as Tween or viewport animation.)

[ashes999]

Generally, you want speed to depend on time. Whether your game runs at 5fps or 50fps, you still move at 10px/s. This means slower computers get frame skips instead of slower gameplay.

But, if you want slower gameplay, yeah, you can couple movement speed to frame rate. Most engines I've seen (eg. XNA) couple it to time, not frame rate.

[starwed]

@ashes999 We actually support specifying how the gameloop handles slowdowns; you can change whether the "EnterFrame" event gets the actual amount of time that has passed, or just a fixed amount. The latter corresponds to tying the motion directly to the number of frames, of course.

(And Tweening and animation are both clock driven now, so the motion component definitely should be for consistency.)

[starwed]

@mucaho I've been looking through Motion/AngularMotion and found a couple more easy-to-fix issues -- I was about to open a PR for them, but I don't want to step on your toes if you're already got something brewing.

[mucaho]

@starwed No problem, go ahead! I'm a bit busy at the moment, so I plan to fix any outstanding issues starting July. Some quick fixes I propose would be to remove the lines of code concerning the FPSChange event:

• remove this, this, this, this, this, this
• change this and this to var dt = frameData.dt * 0.05 probably

[starwed]

@mucaho Just opened #923 that fixes this and several other small things.

[mucaho]

fixed with #923