[nightowl_games]

Hard disagree. It's not hard to do well. The draw back is less than 1 frame of input latency. If your game uses a physics engine or is networked you are forced to use a constant update rate, ie: 30 or 60hz. The draw backs to linking the physics update rate to the monitor refresh rate are enormous and untenable in a networked game.

[mort96]

I don't personally care much about a frame or two of latency (some do though, and for some genres that'll be a big deal); however I care about animation smoothness. If the monitor refresh rate is 144Hz and physics tick rate is 60Hz, you'll need some form of interpolation, which is hard to do well especially since the refresh rate isn't a multiple of tick rate.

[nightowl_games]

An 'animation' tick can be (and should be) disconnected from the physics 'tick'. Physics/game logic 'ticks' should use a constant time so the simulation is more predictable and stable, a 'animation tick' can be exactly what the monitor refresh rate is and thus doesnt need 'interpolation between ticks'.

[mort96]

The position of objects is determined by the physics system though.

[nightowl_games]

It's important to be precise. The position of a small subset of the "objects" are determined by the physics engine. You might have a character with 100s of thousands of vertices, but only a single capsule is in the physics engine. The movement of the characters fingers is not determined by the physics system.

[magicalhippo]

> you'll need some form of interpolation, which is hard to do well

Due to non-constant accelerations?

[kibibu]

Some games use a 120hz physics sim even if they're capped to 60hz display refresh.