You're welcome. One thing I didn't mention is in the department of collision detection, if you have faster moving objects you don't want them to be able to move entirely past another object from one frame to the next or they will never collide. That is a problem with delta timing. Also increasing the fixed rate logic timing reduces that problem a lot and actually can give you much finer grained collision detection for faster moving objects.
Ideally if you're doing some advanced collision detection you'll also use extrapolation or estimation of the total `swept` movement path to see if that entire path of movement collided with an object, but it's harder to do.
Timing schemes are really trying to adapt to variations in how much computation you do, particularly if there isn't enough time to do all your logic and then all your graphics. Usually you let the graphics have less time if the logic needs more, which reduces the visible frame update rate. Some would debate, though, as to whether it's ideal to move objects at an equal speed if you're not even able to see the smooth movement due to not enough frame updates. You can focus on a fixed rate graphics update and a variable rate logic if you want to, somewhat more like the delta timing system.
Where the display hz comes in is really to do with what hz rate you design for and how that translates to verticle blank refreshes, etc. Fixed rate logic may not adapt well to being able to choose multiple screen modes with different hz rates, since if the display hz does not divide evenly (integer) into the logic hz then now you start to have some fluctuation. Delta timing may be better at adapting to different display rates. Ideally though you want both fixed rate logic plus delta timing plus accurate adaptation to the display hz.
Ideally if you're doing some advanced collision detection you'll also use extrapolation or estimation of the total `swept` movement path to see if that entire path of movement collided with an object, but it's harder to do.
Timing schemes are really trying to adapt to variations in how much computation you do, particularly if there isn't enough time to do all your logic and then all your graphics. Usually you let the graphics have less time if the logic needs more, which reduces the visible frame update rate. Some would debate, though, as to whether it's ideal to move objects at an equal speed if you're not even able to see the smooth movement due to not enough frame updates. You can focus on a fixed rate graphics update and a variable rate logic if you want to, somewhat more like the delta timing system.
Where the display hz comes in is really to do with what hz rate you design for and how that translates to verticle blank refreshes, etc. Fixed rate logic may not adapt well to being able to choose multiple screen modes with different hz rates, since if the display hz does not divide evenly (integer) into the logic hz then now you start to have some fluctuation. Delta timing may be better at adapting to different display rates. Ideally though you want both fixed rate logic plus delta timing plus accurate adaptation to the display hz.