Hi. I'm using air friction to slow my player object, and seem to be running into a issue with fixed point precision:

> vec_scale(my._speed_x, pow(air_fric, time));

air_fric is something like 0.995, so at 99fps, the pow() will be 0.999, whereas at 10fps, the pow() will be 0.995. So far so good. The problem seems to be that at 20fps, the pow() also resolves to 0.995. It really needs to be something like 0.9955, which is beyond the resolution of a var.

I could cap the player's terminal velocity manually, but that seems crude. Any suggestions?

Thank you.

edit: or two vec_scales, rather...

Hmm! Thanks; the math is tight, and now I feel embarassed for not realizing that I could separate that out. I *think* I want to do this...

...so as to retain resolution (just off the top of my head, 0.996/2 is identical to either 0.995/2 or 0.997/2 due to the fixed point math). However, either way, I'm still (essentially) hitting different speeds on different systems.

Anything obvious jump out, here?

How about time_step; ?

why not

vec_scale(my._speed_x, pow(air_fric*1000, time)*pow(0.001, time));

Is the resolution problem hit at 3 decimals, or 3 units of precision?

Don
have a great day

Thanks, guys. Ultimately, nothing I've tried has worked yet -- the oddest solution I've tried, based on all of the above, has had things working well at 15fps and 99fps, but not 35fps. My next attempt will be to store the velocities as doubles (C++), and update with acceleration and friction entirely there.

Why don't you try to multiply the values by 1000 to preserve otherwise lost precision before calculation and divide the result by 1000 just before you need the value for use with an engine function?

Would this help for you?
If I understand you right, you don't have problems with very large numbers but with position after decimal point.
By the given multiplication you simply move the decimal point to the right. This results in a higher precision but also limits in a way that you can not process large numbers, because you might get an overflow if you multiply a large number by 1000.

Well from the lowtech side, this would not be a multiplication by 1000 but a simple right shift or left shift operation.
This was a common technique at a time where integer operation where way faster than floating point operations.

I hope this works for you in this situation, too.

[edit]
But as you said, sometimes an external dll can help.
I had to do this some years ago to get a smooth camera movement along a Catmull-Rom spline with gamestudio. Whithout dll the movement was not smooth at all.

I'll be durned if I can figure it out, but the left/right shifts haven't been doing the trick. I do appreciate the suggestion -- I just hope the DLL solution will work out(!)