I've been building my own multiplayer FPS, implementing the techniques in the well known "Source Engine Networking" article by Valve. Now to my question, so far I've been reading the user input in my variable time Render() function, but this is ending up being a bit messy since I have to pass around the actual delta time associated with each input to replicate movement properly on the server, etc.

So I started moving over to reading input in my fixed step Physics() function, but since the fixed time step and the rendering don't always line up this ends up looking a bit "choppy" sometimes. The best I could come up with was to try to fix my frame rate and physics rate at the same speed (60 updates/second).

They don't always line up and get called one after the other, but most of the the time they do and it looks smooth. So now to my question: Is this an acceptable solution? Sometimes the rendering will skip ever so slightly, but in 99% of the case it looks perfect. How is this solved in "AAA" titles? Or should I go for an interpolating solution where I calculate the movement needed in Physics(), but actually interpolate towards the next Physics() inside of Render()?

http://gafferongames.com/game-physics/fix-your-timestep/

Essentially if you are at time 3.4 (in ticks) then you should have physics simulated 0, 1, 2 and 3. Keep a record of the current physics position and the previous physics position.

Then to render, render exactly 1 tick behind, so you would render at tick 2.4, intepolate 0.4 fraction between tick 2 and tick 3 position.