Missile turn rate is framerate dependent

[asarium]

Higher framerates cause missles to turn slower (or low FPS causes missiles to turn faster). This can also be seen when increasing time compression, higher time compression causes the missiles to turn much sharper than when no time compression is used.

I guess that this is caused by using a wrong method of computing the next orientation and position of the missile that isn't stable for lower framerates.
This bug probably also affects ships but it isn't as noticeable because they don't turn as fast as missiles.

[chief1983]

So is this like a direct relationship? Like 30fps vs 60fps vs 120fps still look different, or do you have to get to the really low end of the spectrum to see it?

[asarium]

As far as I can tell it's a direct relationship. You can even notice it when the framerate suddently gets lower or higher because the turn rate changes.

[MageKing17]

Turn rate getting faster as framerate decreases makes me instinctively expect that frametime is being used wrong in the calculations somewhere. Is this a retail problem, or was it introduced by FSO?

[asarium]

I'll try to reproduce it with retail.

[chief1983]

Anyone ever reproduce this on a much older build?

[JohnAFernandez]

So, I think I know what's happening here, although I think someone else should also take a look.

I took a look through the physics code to see if missiles were treated any differently than normal objects, and as far as I can tell, they're not. Their rotational damp is set to zero, but that doesn't change the root cause of the bug in the end.

Since ships have a damp factor, their rotation accelerates and the effect is not as pronounced. You would see it only notice it for a ship if it is already rotating at or its maximum rotational velocity and you are actively looking for a ship to move weirdly.

Missiles, by virtue of being the example of rotational velocity we keep the most track of (in order to avoid) and having this issue be even more pronounced because of no damp factor, are just the first example we've discovered. In the end, the real problem is fundamental to our physics engine.

Here's the real problem: we simulate velocity for the whole frame at once, and then we simulate rotation for the whole frame at once. This works for short frame times because it reasonably approximates real world physics, but once frame times become long, this is no longer true. So after moving a long distance in a long frame, it will be in that position and rotate a lot. The rotational velocity is directly multiplied by frametime.

The real fix is to require a certain number of steps if frametime is too large, calc the distance, then calc the rotation, repeat until done. The problem with this is that the issue is happening on computers for which FSO is already running slowly. Perhaps we can add an approximation for longer frame_times, but I would have to look up the math involved.

[JohnAFernandez]

Why isn't this closed yet?