> Вот это "фиксированное время" для расчёта кадра не с потолка ведь берётся.Берётся достаточно большим, чтобы обсчитать больше, но достаточно малым, чтобы чаще обновлять сцену (например, интерполированное положение движущегося объекта), чтобы игрок не замечал дискретного шага времени. Обычно это 30 Гц. Связь с частотой монитора косвенная: оба пытаются подстроиться под "частоту обновления" человеческого глаза (24-25 Гц). Такая же как с видеороликами с частотой 25-30 Гц для экономии места с почти незаметным глазу падением качества в движении.
Физическая подсистема (особенно, если это специализированная, модульная библиотека) выполняется в отдельном потоке (thread) от обработки вывода и ввода. Она, когда нужно, снимает состояние ввода на момент и/или обрабатывает очередь накопленных событий. Графическая подсистема обновляется на основе состояния сцены, также на момент, также в одностороннем порядке. Когда игрок увидит готовый кадр, тот уже может сильно отличаться от реального (времени) состояния мира. (Поэтому видеовывод требует большей частоты обновления.) Связь между подсистемами косвенная, на уровне планировщика потоков ОС.
Из-за этого многие данные в подсистемах дублируются. Например, при обсчете столкновений используется не настоящая геометрия, а заранее подготовленные на её основе геометрические коллайдеры. Не только для скорости, но из-за разницы времени выполнения и архитектур (CPU/GPU).
Если вызывать подсистемы последовательно в одном цикле, то добиться фиксированной частоты затруднительно. То время на себя перетянет физика, то графика. То динамичная сцена замирает в ожидании окончания построения видеокадра (в теневом буфере - при двойной буферизации), то картинка замирает в ожидании пересчета всего мира. Тогда подсистемы нужно делать с плавающим кадром, с интерполяцией по переменной величине времени между кадрами (deltaTime) для каждой подсистемы соответственно. Но у плавающего кадра свои проблемы. А в век многоядерных всего-и-вся это как-то совсем нерационально.
