Переменный шаг перемещения и ускорение (Variable time step). Алгоритм

[KumoKairo]

Доброго времени суток.
Многодневные поиски информации и экспериментирования не дали результатов, поэтому попробую тут спросить, может кто сталкивался.

Суть:
Есть игра-платформер, создаваемая во FlashDevelop с помощью Starling. То есть нет гарантированного количества FPS, есть только ограничение сверху (стандартные для Stage3D 60 FPS).

Поэтому обычную модель перемещения (Fixed time step), когда каждый кадр к позиции игрока прибавляется или убавляется определенное значение перемещения, использовать нельзя.
Еще интересней - простую реализацию Variable time step, когда каждый кадр проверяется время, прошедшее с последнего отрисованного кадра, и это значение умножается на нашу квантовую скорость, которая уже прибавляется к положению игрока, тоже использовать нельзя.
Причина - движение с ускорением.
Допустим мы нажали клавишу "Влево". Пока она нажата, мы предполагаем, что игрок движется влево. Проверяем, не привысил ли он установленный лимит (не разогнался ли до предельного значения)

if (Math.abs(this.player.xSpeed) < this.atmoshpere.linearSpeed && !this.player.inAir)

Если нет, то увеличиваем скорость игрока на величину, которая зависит от прошедшего времени:

this.player.xSpeed -= elapsed * this.atmoshpere.linearSpeedIncrement;

Тут явно заметна проблема - при низких FPS игрок просто не сможет разогнаться до нормальной скорости, поскольку ограничивающее значение абсолютно.
Можно попытаться связать ограничивающую скорость с прошедшим временем,

if (Math.abs(this.player.xSpeed) < this.atmoshpere.linearSpeed*elapsed && !this.player.inAir)

Но тогда в случае, если FPS резко возрастет, допустим, с 30 FPS до 60, скорость игрока уже будет больше, чем позволяет в данном случае ограничение

 this.atmoshpere.linearSpeed*elapsed

Решение простое - добавить условие, при котором, если скорость игрока больше вычисленного только что лимита, присвоить игроку максимально возможную в данной ситуации скорость:

if (Math.abs(this.player.xSpeed) > this.atmoshpere.linearSpeed * elapsed)
{
	this.player.xSpeed = - this.atmoshpere.linearSpeed * elapsed;
}

Но теперь игрок начинает дергаться, резко замедляться, поскольку часто FPS не очень стабильно (меняется +/- на 3 кадра в секунду)

В общем основная проблема с этим ограничителем максимальной скорости, из-за него весь сыр-бор.

значение elapsed измеряется в миллисекундах (изменялось от 16 до 150), скорости linearSpeed и linearSpeedIncrement меньше единицы, первое ограничено 0.2, второе 0.005

Давно откладываю решение этой проблемы, но в скором времени уже надо разобраться..

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

[strangedk]

Мне кажется что при слишком низких FPS пользователь просто закроет игру, да и всё тут.
У меня в некоторых проектах цикл игры повешен на таймер, с проверками на изменение значений.

Никогда не замечал критичных проблем с этим. Если FPS падает слишком низко, то лучше разобраться сначала с ним.

[KumoKairo]

Спасибо за ответ, strangedk
В данном случае, FPS влияет только на плавность перемещения персонажей, а сама анимация (этих персонажей, эффектов и прочего) имеет собственный параметр FPS (анимация создается с помощью спрайтов). То есть даже при ФПС 10 у приложения, вся внутренняя анимация отдельно взятого объекта (игрока) будет плавной, как надо.

Проблема с FPS, на самом деле, возникает только на стареньких нетбуках, вот там серьезно невозможно играть, проверили на нескольких.

Если потом портировать на айпады и прочее, проблем тоже возникнуть не должно (надеюсь)

А так, в целом, FPS колеблется от 58 до 60, плюс иногда компьютер "икает" и "втыкает" лишний кадр не через 16-20 мс, как должен, а через 0.0005 мс (или около того)
Вот из-за этих небольших, казалось бы, колебаний, персонаж начинает дергаться, если использовать анимацию с ускорением и плавным замедлением.
То есть при общем тестировании проблем с FPS не возникает, сейчас там реализована модель ускорения по кадрам, но расчитывая на будущее, хочется менее зависящее от производительности системы приложение. Потому что аж до 40 FPS перемещение довольно гладко выглядит. То есть до 40 FPS можно себе позволить спуститься.

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

Но нигде нет про анимацию с ускорением и ограничением максимальной скорости)

Сейчас думаю прикрутить школьный уровень физики, может что получится

[strangedk]

Простите, что отвечаю не совсем на сам вопрос. Но на сейчас, в эпоху мобильных устройств - возникает достаточно скользкий один момент:

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

Так вот эта аудитория пользователей, по факту, не такая уж и важная. Если посчитать все за и против.
Я не пытаюсь сказать что они нищеброды и не принесут денег, речь не об этом. А о том, что все нормальные игры должны иметь свои требования! Совсем не обязательно поддерживать ВСЕ устройства, это просто невозможно.

Важно установить для себя минимальные требования игры, и тестировать её уже полагаясь на них.

[KumoKairo]

Не не, порт на мобильные устройства не был самоцелью, я просто пока не исключаю такой возможности)

Ну вот, с натяжкой можно сказать, что тестируем с определенными системными требованиями (проверяем на ноуте и декстопе, ноут, кстати, не очень мощный), но от проскакивания кадров это не спасает. Я не знаю, видимо причина в самом старлинге или где-то на низком уровне stage3D

То есть можно считать, что FPS ниже 55 не опустится, а между 55 и 60 не особо большая разница в покадровом перемещении.
И вроде как можно оставить стандартный fixed time step
Я скорее всего так и поступлю, если таки не найду способ реализации перемещения в зависимости от времени..

[iflamberg]

Что-то я не могу понять, как переменный фпс мешает достигнуть максимальной скорости при абсолютном ограничении скорости.

Скажем, при нажатии кнопки "вправо" мы установили Vx в +1 и плануруем скорость увеличивать на A=+1 в секунду, пока она не достигнет maxVx=+5. На enterFrame прошло с предыдущего кадра времени dt = getTime() - t_prev. Скажем dt = 0,05 секунды. Изменяем соответсвенно, Vx = Vx + A*dt. Ну и условие максимальной скорости if (Vx > maxVx) Vx = maxVx; После чего перемещаем персонажа charX += Vx*dt; Вроде все.
И что, такая простая математика не работает? Ну, там могут вылезать погрешности, типа при слишком большом dt скорость моментально измениться слишком сильно и персонаж пробежит большее расстояние, чем должен. Тогда надо разбить dt на несколько и в цикле провести приращение скорости/перемещение несколько раз. Но, это опять же, стандартная практика, это все равно обычно необходимо для проверок на столкновение, иначе при больших скоростях персонаж будет пролетать сквозь небольшие препятсвия.

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

[strangedk]

Привязка ко времени в данном случае - оптимальна.

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

Графика spritesheet, starling второй, ну не должно оно тормозить, не должно.

[alatar]

Скорость

v = v0 + a*t

Если скорость больше максимальной, вычисляем время на достижение этой скорости

t = (v - v0)/a

После чего вычисляем расстояние для движения с ускорением и для равномерного движения.
Пройденное расстояние

s = ((v + v0)*t)/2

или

s = (v^2 - v0^2)/(2*a)

v - конечная скорость
v0 - начальная скрость
a - ускорение
t - время
s - расстояние

[gagaga]

какая разница то с ускорением или нет движется тело, есть определенная функция (любой степени) находим производную скорости по времени и делаем приращение координат

[KumoKairo]

iflamberg, gagaga
Угу, на теории все просто и работает, а на практике вылезают косяки

alatar,
Спасибо за подробные формулы, я как раз начал реализовывать с абсолютным временем начала движения, но почему-то пропустил мимо эту формулу расстояния)

Как реализую - отпишусь, сейчас вроде нормально все должно получиться