Почему анимации иногда делаются с помощью шагов на основе количества времени, это передается?
Я заметил что некоторые одушевленные объекты программистов на основе разницы во времени. Я не уверен, почему или логично ли это. Кто-либо знает значение?
Ниже отрывок кода, который объясняет, что я имею в виду:
var timePassed:int = getTimer()-lastTime;
lastTime += timePassed;
var newBallX = ball.x + ballDX*timePassed;
var newBallY = ball.y + ballDY*timePassed;
6 ответов
] Когда вы анимируете, основываясь на времени, вы делаете себя независимым от фреймерата. Независимо от того, сколько кадров прошло, ваш шар будет перемещаться на одно и то же расстояние за заданное количество времени. Сравните это с зависимостью от фреймерата, который зависит от многих переменных, например, от того, сколько вычислительной мощности доступно для анимации.[
] [] Это распространенная проблема игровой физики -- посмотрите замечательную статью Гленна Фидлера [][] "Fix Your Timestep!" article[][] для более подробного ознакомления с этим. (Сделать это правильно немного сложнее, чем просто умножить ваши векторы направления на таймстеп)[
].Логика проста.
BallDX => Ball Delta X => Расстояние, на котором мяч может двигаться по координате x за одну секунду
timepassed => количество пройденного времени
if OldBallX = 0
if BallDX = 10
if TimePassed = 1 sec
Then NewBallX = OldBallX + (BallDX*TimePassed)
Что означает
NewBallX = 0 + (10 * 1) = 10 pixels
В этом случае
if TimePassed = 0.5 sec (half a second)
Тогда
NewBallX = 0 + (10 * 0.5) = 5 pixels
Logical?
.Самым важным аспектом независимости от фреймерата является то, что вам не нужно связывать его цепочкой. Раньше, еще в темные века, игры писались так, чтобы максимально использовать процессор, а частота смены кадров определялась скоростью процессора. Я помню, как играл в игры на своей 16-мегагерцовой машине, в которых все пролетало так быстро, что вы не могли реагировать, потому что они были написаны для 1-мегагерцовых машин. Программисты подошли к этому с умом и начали писать игры, которые закрывали кадр, обычно со скоростью 30 кадров в секунду в ранние годы, позже 60 кадров в секунду (обычно закрытые на VSYNC монитора). Это решило проблему, но было действительно раздражающим для тех из нас с потрясающими компьютерами, которые хотели более плавного движения. В конце концов, они начали писать игры полностью независимо от кадров, что позволяет играть в игру со скоростью 700 кадров в секунду и получать тот же опыт, что и со скоростью 20 кадров в секунду, за исключением более плавной графики. И она также может справляться с изменением нагрузки во время игры, как говорили другие, что может быть очень важно при работе с современными многозадачными операционными системами
.Почему бы и нет? В противоположность чему? Это ведь простое линейное движение? Есть одна мысль: это позволяет мячу догнать намеченное положение в том случае, если другие программы замедляют работу компьютера.
Современная компьютерная операционная система выполняет множество задач одновременно, и вы не всегда получаете срезы времени через регулярные промежутки времени. Используя разницу в часах реального времени, вы сглаживаете движение против того, чтобы каждый раз перемещать одно и то же количество по циклу, что может привести к дрожанию, если операционная система отдаст еще несколько миллисекунд другому процессу, прежде чем он вернется к вашему.
Если вы делаете анимацию как функцию времени, вы можете быть независимо от частоты кадров несколько, это означает, что если вы делаете вашу анимацию для 24 кадров в секунду, вы можете легко настроить анимацию на 30 кадров в секунду , если она динамическая (как в , определяемая функцией / в отличие от кадра за кадром рисунков, где планирование - это все )
Это короткая история, для полного объяснения смотрите старую главу Роберта Пеннера о Motion, Tweening and Easing .