Well the base movement speed uses input.time, but the turning speed is still dependent on the update rate.
The issue is that the amount of speed that gets added is based on how smooth your mouse movement is. Your impulse direction, which is dependent on your view angle, can only be updated every update, so input.time can't account for that. When the update rate decreases, the mouse movements get perceived as being increasingly erratic, which therefore decreases the amount of speed that gets added.
So I'm thinking that I may be able to make a recursive function to estimate the amount of speed that would have been added had the update rate been higher. The reason it would have to be recursive is because the amount of speed that gets added is proportional to your current speed. It would divide the difference in angle between velocity and the impulse direction by a certain standard, and create new vectors from those angles. Then it would treat each of those vectors as if they were new updates.
However, this would have to assume perfect mouse smoothness between updates, which will lower the skill ceiling and possibly cause some other problems. Not to mention performance costs.
<!--quoteo(post=1999444:date=Oct 29 2012, 04:04 AM:name=Jaweese)--><div class='quotetop'>QUOTE (Jaweese @ Oct 29 2012, 04:04 AM) <a href="index.php?act=findpost&pid=1999444"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Well the base movement speed uses input.time, but the turning speed is still dependent on the update rate.
The issue is that the amount of speed that gets added is based on how smooth your mouse movement is. Your impulse direction, which is dependent on your view angle, can only be updated every update, so input.time can't account for that. When the update rate decreases, the mouse movements get perceived as being increasingly erratic, which therefore decreases the amount of speed that gets added.<!--QuoteEnd--></div><!--QuoteEEnd-->
If your mechanic is fps dependent then your doing something wrong.
If you want to compute the turning speed (angular velocity) for example for the yaw you need to do ( yaw(t) - yaw(t-dt) ) / dt with dt = input.time so that you get a result in radian per second that is independent of the frame rate.
The 30 ticks gives a limit on the fast process; you can't deal with anything that happens faster than 33ms.
Comments
The issue is that the amount of speed that gets added is based on how smooth your mouse movement is. Your impulse direction, which is dependent on your view angle, can only be updated every update, so input.time can't account for that. When the update rate decreases, the mouse movements get perceived as being increasingly erratic, which therefore decreases the amount of speed that gets added.
So I'm thinking that I may be able to make a recursive function to estimate the amount of speed that would have been added had the update rate been higher. The reason it would have to be recursive is because the amount of speed that gets added is proportional to your current speed. It would divide the difference in angle between velocity and the impulse direction by a certain standard, and create new vectors from those angles. Then it would treat each of those vectors as if they were new updates.
However, this would have to assume perfect mouse smoothness between updates, which will lower the skill ceiling and possibly cause some other problems. Not to mention performance costs.
The issue is that the amount of speed that gets added is based on how smooth your mouse movement is. Your impulse direction, which is dependent on your view angle, can only be updated every update, so input.time can't account for that. When the update rate decreases, the mouse movements get perceived as being increasingly erratic, which therefore decreases the amount of speed that gets added.<!--QuoteEnd--></div><!--QuoteEEnd-->
If your mechanic is fps dependent then your doing something wrong.
If you want to compute the turning speed (angular velocity) for example for the yaw you need to do ( yaw(t) - yaw(t-dt) ) / dt with dt = input.time so that you get a result in radian per second that is independent of the frame rate.
The 30 ticks gives a limit on the fast process; you can't deal with anything that happens faster than 33ms.