I've just noticed, that "c_move" returns the "covered distance" dependent on the framerate, but as I use it to animate the camera, depending on the movement speed, I would like to know, is there a way, to make the return value by "c_move" framerate independent? Plus, I tried vec_length and it returns framerate dependent value as well.. But there is nothing wrong with the movement itself, as it's framerate independent.


Edit: changed the code

The value c_move returns is always framerate independent, because it does in no way rely on the time the current or any other frame took. It just returns the distance covered.

Well, the problem is, that it changes if I change the fps_max, so what could this mean? The movement is framerate independent itself.

The value returned by c_move IS framerate independent when your movement vector is multiplied by time_step (I guess vec_accelerate does this for you, right?).
For example you can use the following:

result = c_move(me,vector(10*time_step,0,0),nullvector,IGNORE_PASSABLE);
my.skill20 = (my.skill20+result)%100;
ent_animate(me,"walk",my.skill20,ANM_CYCLE);

Multiplying result in the second line with time_step would be wrong here as result already is framerate independent thanks to the time_step factor in c_move.
If you however want to get the speed of an entity/ the movement distance, use the following:

result = c_move(me,vector(10*time_step,0,0),nullvector,IGNORE_PASSABLE);
distance = result/time_step;
Write "distance" to screen, should be very close to 10 when there are no obstructions.

Superku@ if I change the fps_max from 60 to 30 (let's say), then I get result two times bigger than it was (with both, mine and your examples). Why is that?

If that didn't happen your object would only move half as fast on 30fps.

Ok, I guess I got it.. dividing my_speed by time_step, returns the constant value, so I guess that proves that value is framerate independent. Thank you.

I still don't get that. Regardless of the vectors you pass to c_move, c_move will attempt to move the entity exactly that distance. There is absolutely no dependence on the framerate. If you pass a vector of length 10 to it it will return 10 - if there is no obstacle.

That means: if the distance covered is framerate dependent you already gave c_move a frame rate dependent speed vector. And that's what you'd want to do in most cases anyways.

Uhrwerk@ hehe, it's still a bit dirty for me, but I guess I got the idea (I got it to work anyway).
If you want to give it a try, here is a small demo (it's 7 kb made with the code from the first post):
c_move result test thing
First value is the covered distance, second one is the moving speed.
Just change the fps_max at run-time to see what I was talking about.

As they have stated above, the result of c_move is frame rate independant.

But the difference in results you are getting is because it will always return the exact distance covered in the last frame. And remember, if you are using the code from your last request thread (framerate independant movement), the value you are passing to the c_move instruction was speed multiplied by time_step in your code, therefore to get framerate-INdependant movement you are passing framerate-DEpendant distances to c_move. And that causes the framerate-INdependant results you are getting from c_move each frame to now be different depending on different framerates.

Explanation:
Also another important thing to keep in mind, I feel you are confusing the concepts of distance and speed.
Remember:
speed=distance/time
time=distance/speed
distance=speed*time
You obviously know these formulas already because you got them right in your code from your previous thread, but I have the feeling that when using time_step they get a little more confusing since it is easy to forget that for a computer time is directly related to both framerate and time_step. As a generalization, consider fps=time in these formulas, since you could generalize that time_step is calculated from the time the last frame took to complete.

-In the other thread you had to multiply your speed with time_step to get the distance covered per frame because dist=speed*time
-The result of c_move is the exact distance covered over a period of time (in this case, the distance covered last frame).
-By dividing the result of of c_move (distance) by time_step (time), what you are actually getting is speed (not distance). speed=dist/time
-By changing the framerate in the example you stated above, you are changing the time (of each frame), and even though c_move result is just distance, since distance=speed*time the program is modifying the speed (or what is the same, the distance per frame).

Conclusion:
- c_move always returns framerate independant distance of the instruction. If you pass it a constant distance you get constant results ignoring the time (but that will obviously produce different speeds at different framerates).
- Remember (in your previous thread) you are not passing a distance to c_move directly anymore, you are now passing a speed*time. That is also a distance, but not an absolute distance ignoring time anymore.
- If instead of giving c_move a distance, you give it a speed and a time, your result is a distance modified by speed and time.
-In your above post you said that you got the correct (constant) distance values by dividing it by time_step, that is incorrect, you are now getting a constant value, but you are confusing distance and speed, what you are really getting now is speed because speed=dist/time. You gave c_move speed and time, and it correctly returned distance. Afterwards you took that result (distance) and divided it by time, transforming it into speed again.


In sloppy game programming people ignore time_step, so their game is designed only for their computer because it is framerate dependant. The above formulas still apply even when programmers dont use time_step, but the programmer is choosing to ignore time, making speed and distance different on other computers since they choose to ignore time.
All three things are always depending on eachother, a change in one (for example time) whether you program them in or not, will always effect the others.
By correctly accounting for time in your program now, it will modify speed and distance to get correct (constant) results on all computers no matter the time (framerate). When not programming time, those computers still modify distance and speed depending on time, the only difference is that time is now out of the programmer's control and left for the computer's framerate to modify speed and distance with no control.

You are now correctly taking all three variables into account when programming your input to the computer, but still thinking only with two when analyzing the data it otuputs to you.

EDIT:
Wow, that was much longer than I thought! Again, sorry for the long read, but I hope it helps you out.