So I've been experimenting a lot recently, just making some prototypes for ideas I have, having some fun. It's all going very well, except for one problem. There's always an issue with something being affected by the framerate, even when time_step is being used. I just made an FPS movement system, and tried out different framerates. You jump higher when the framerate is higher.

Confused about why this keeps happening, I did some research on Google, about timestep and all that stuff, and apparently this has been a problem in games for a while, certain things being affected by the framerate. In the Quake games, if you have a lower framerate, you don't jump as high. I was just wondering... is it possible to get around this? I read about there being a variable timestep and a fixed timestep, but don't really understand what the difference is. I assume it has something to do with how certain games slow down everything if the proper framerate isn't being reached, and other games just making everything move more/less every frame if the framerate isn't correct.

So, my question is: Is there a way to make my jumping less affected by framerate? I don't want players with an fps of 20 to get stuck on a platforming section or something...

Thanks in advance.

other than setting fps_min and fps_max to the same i'm having the same problem

The timestep variable is set by getting the arithmetic difference between the current clock time and the clock time of the last frame. Because the time difference between one cycle and another is minute, the FP unit often times cannot accurately record the difference. If your framerate is especially high, the FP unit may record the time difference as 0 and everything in your world will stop.

This is one of the many reasons why games are typically locked to 60fps. It completely prevents these apocalyptic scenarios from happening.

Regarding your problem with movement and stuff, though: there isn't any way to totally defeat the problem. But instead of writing this:

You could write this:

This tends to return more uniform results.

Another trick is to provide a smooth gradient for these time dependent variables. That is, make your "totalspeed" variable something that is only indirectly affected by timestep through velocity, inertia, and friction variables.

Not true, the clocks inside a x86 PC are accurate enough to get times in the sub millisecond range, otherwise a today OS couldn't work very well. Its also possible to grab the time as double precision floating point from the OS, being valid for about 10k years in the sub millisecond range, subtracting the old time from the current time and converting it to single precision floating point afterwards doesn't really reduce the accuracy by much.

I assume you mean:

...but that doesn't seem to work. Jumping in 60 FPS is completely different than jumping in 20 FPS. I tried it in the c_move for jumping, and in the command that decreases the variable "z_move" (which is used in the c_move). Perhaps I'm not using it correctly?

Thanks for the help so far.

The problem is not time_step but the fact that movement per frame is linear, I hope the following sketch explains the problem:

(The result is, of course, the same when you only jump in z-direction.)

I don't understand. What do you mean by "movement per frame is linear?"

Have a look at the sketch:
Your entity won't move along the curve, instead it will move straight from one black arrow to the next. As a result, the entity probably will not reach the maximal height (= green line) on a low framerate.

Ah, I see. Is there a way to prevent this? Or at least, reduce the effect?

I'm working on a platformer/ jump'n'run and I simply "ignore" it. I just make sure that the game works on 20fps+ and that you can reach every platform and make every jump.
You could write a code that only allows downward movement when you've reached a certain height (f.i. starting height + 256 quants), but this would deform the jumping curve and result in different timeframes.