Почему анимации иногда выполняются с использованием шагов, основанных на количестве пройденного времени?

Question

Я заметил, что некоторые программисты ожидают объекты, основанные на разнице во времени. Я не уверен, почему и даже если это логично. Кто-нибудь знает значение?

Ниже приведен фрагмент кода, который объясняет, что я имею в виду:

var timePassed:int = getTimer()-lastTime; 
lastTime += timePassed; 
var newBallX = ball.x + ballDX*timePassed; 
var newBallY = ball.y + ballDY*timePassed; 

Answer 1

Когда вы анимировать в зависимости от времени, вы делаете себя независимо от частоты кадров. Независимо от того, сколько кадров прошло, ваш мяч будет перемещаться на одинаковое расстояние за определенный промежуток времени. Сравните это с тем, что зависит от частоты кадров, которая зависит от многих переменных, например, насколько доступна вычислительная мощность для анимации.

Это обычная проблема в игре-физике - ознакомьтесь с превосходным Glenn Fiedler "Fix Your Timestep!" article, чтобы получить более подробную информацию об этом. (Выполнение этого права немного сложнее, чем просто умножение векторов направления по времени.)

Answer 2

Почему бы вам не сделать так? В отличие от того, что делать? Это простое линейное движение? Вот мысль: это позволяет мячу догнать свое предполагаемое положение в случае, если другие программы замедляют работу компьютера.

Answer 3

Современная компьютерная операционная система запускает сразу несколько задач, и вы не всегда получаете свои срезы времени с регулярными интервалами. Используя разницу в часах реального времени, вы сглаживаете движение по сравнению с тем, что каждый раз через цикл вы перемещаете одну и ту же сумму, что может привести к тому, что он будет выглядеть отрывистым, если ОС предоставит еще несколько миллисекунд другому процессу, прежде чем он вернется к твоему.

Answer 4

Логика проста.

BallDX => Шаровые Delta 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 

Логическое?

Answer 5

Важнейшим аспектом независимости от частоты кадров является то, что вам не нужно связывать частоту кадров. Раньше, в темные времена, игры записывались так, чтобы использовать процессор как можно больше, а частота кадров определялась скоростью процессора. Я помню, как играл на своей 16-мегагерцовой машине, у которой все было так быстро, что вы не могли реагировать, потому что они были написаны для машин с частотой 1 МГц. Программисты догадались об этом и начали писать игры, которые ограничивали частоту кадров, обычно в 30 кадров в секунду в первые годы, а затем 60 кадров в секунду (обычно они были заблокированы на VSYNC монитора). Это решило проблему, но было очень неприятно для тех из нас, у которых были удивительные компьютеры, которые хотели больше движения жидкости. В конце концов они начали писать игры совершенно независимо от частоты кадров, что позволяет играть в игру со скоростью 700 кадров в секунду и получать тот же опыт, что и при 20 кадрах в секунду, за исключением более плавной графики. И это также может справиться с изменением нагрузки во время игры, как говорили другие, что может быть очень важно с сегодняшними многозадачными ОС.

Answer 6

Если вы сделаете анимацию, как функцию времени, вы можете быть независимо от частоты кадров несколько, а это означает, что если вы сделаете анимацию для 24fps, вы можете легко настроить анимации, чтобы соответствовать 30 кадров в секунду сценарий если это динамический (как в определяется функцией/противоположность покадрово чертежи, где планирование все)

Это короткий рассказ, для полного объяснения взглянуть на старые добрые Роберт Пеннер в 'глава на Motion, Tweening and Easing.