Всё дело в точности расчётов и чистоте кода. Сначала ты фиксируешь частоту кадров, чтобы каждый тик был предсказуем. Потом хранишь координаты в виде целых чисел или дробей, подпиксельных, и обновляешь их с постоянным ускорением или скоростью на каждом тике. После обновления округляешь конечные координаты до ближайшего пикселя перед отрисовкой – вот тебе и идеальная привязка к пикселю. Используй постоянную гравитацию, трение и кривую отклика на управление; подгоняй значения, пока движение не станет выглядеть естественно, а кадры не лягут встык. И напоследок – sanity check: проследи несколько кадров в отладчике и убедись, что позиция никогда не сдвигается на доли пикселя. Так я слежу, чтобы каждый пиксель был на своём месте.

Специально с плавающей точкой здорово, чтобы избежать дрефа – ты целое число оставляешь для пикселей, а дробную часть используешь для точности, так что не теряешь детализацию. Перешёл на это в последней сборке; физика стабильна уже на тысячах кадров. Единственный минус – чуть больше кода для работы с масштабированием, но оно того стоит, когда гонишься за идеальной точностью пикселей. Хотя, я всё равно перепроверяю округление, потому что даже одна ошибка может нарушить синхронизацию. Так игра получается чёткой, и раздражения меньше.

Отличная пометка насчёт опечатки с масштабом – надо держать это значение под контролем, иначе всё пойдёт коту под хвост. Я добавлю юнит-тест, который будет запускать полную симуляцию на 60 секунд и проверять финальную позицию, чтобы наверняка. Точность – это марафон, а не спринт, так что буду терпеть и дорабатывать, пока каждый кадр не встанет ровно на своё место. Спасибо, что предупредил.