Firstly, I want to pose the question: Why do you think you need to update logic 120 times per second? Once again countless games can offer a responsive and jitter-free experience without having to update this often. Including Starsiege: Tribes, the fastest game mentioned by anyone so far, which only updates 32 times per second.
I think I really need to clarify how my timestep works for example at 60 fps the physics engine will simulate 1/120th of a second twice per frame. The time required to render the last frame is divided up into intervals of 1/120th of a second and it processes 1/120th of a second that many times. So at 30fps it will do 4 updates per frame. What I'm really looking for is a better model for updating my physics. As for a definition of responsiveness it is how quickly the simulation reacts to input from the user. Stutter is when the framerate remains constant but motion appears to stop or slow down for fractions of a second I assume this is caused by the physics engine taking longer than the timestep to compute the update.
Do you have a specific reason for this update resolution?
If your reason is just that “It makes things run more smoothly” then your problem lies elsewhere.
You should be experiencing fine control and physics at a mere 30 updates per second, and you should be using this as a base-line anyway because, since numerous other games are fine at this speed, yours should be too unless you are doing something wrong.
What you said about stutter is basically related to my #1 in my first post. The objects are jerky because you are not interpolating them between frames.
If you don’t interpolate the objects, your framerate won’t matter as much because you will be displaying the same objects in the same positions as last frame about 30% of the time or so.
I covered this topic here: http://lspiroengine.com/?p=378
Hit Ctrl-F and type “But How Can”
You will find a drawing that explains this concept, and the entire logic behind interpolation is within the same post as well.
Firstly, try to address this issue, because once again a higher update rate is usually just going to hide underlying problems.
Start with an update rate at 30 and try to solve this issue. As mentioned before, most games are able to get perfectly fine performance out of 30-ish update rates as long as the rest of their pipeline is solid, so getting yourself a nice smooth input rate and lack of jitter at 30 updates per second is a nice way to check that you are doing everything else fine.
Only increase your update rate once everything else checks out and it is only the option left. It does serve a use, but don’t do it prematurely or else all you are doing is hiding bugs.
Edited by L. Spiro, 23 November 2012 - 12:51 PM.