Плавное движение Opengl ES 2.0

Question

Я создаю очень простую «игру» для Android, используя Opengl ES 2.0. Игровой процесс состоит из движущейся точки, которая ускоряется или замедляется в зависимости от ввода пользователя. Конечно, пространство, покрытое точкой в ​​одном кадре, зависит от количества времени, прошедшего с последнего кадра, поэтому для вычисления этого пространства я умножаю скорость точки на это количество времени.

У меня также есть камера, которая движется в соответствии с моей точкой, но я поворачиваю оси X и Y, чтобы камера следовала за точкой.

Моя проблема в том, что точка (и камера) не двигаются плавно. Кстати, я не понимаю, почему FPS всегда 60 или по крайней мере 55 (я проверяю их через внешнее приложение).

Если я использую всегда одно и то же время между кадром и следующим, все получается гладко.

Кстати, чтобы понять, что не так, я построил очень простой счетчик FPS и регистрирую FPS (или прошедшее время) через Log.d. Здесь я заметил, что значения варьируются от 45 до 80 FPS. Теперь я думаю, что если бы я мог зафиксировать это значение максимум до 60 (что является частотой обновления экрана большинства смартфонов), то движение было бы намного более плавным. Итак, мой вопрос: как мне избежать, чтобы мое приложение рисовало кадр до истечения 0,0166 секунд с последнего кадра?

Спасибо за чтение и извините за мой английский!

Answer 1

Здесь я заметил, что значения варьируются от 45 до 80 FPS.

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

Как правило, обновление дисплея будет ограничено 60 кадрами в секунду, но поскольку ваша анимация основана на истекшем времени кадра, которое вы видите на уровне API (который отделен от фактического обновления дисплея), вы анимируете каждоекадр, как если бы он был 45 кадров в секунду или 80 кадров в секунду, что на самом деле не отображается на экране.

Если вы знаете, что вы близки к 60 кадрам в секунду, я бы попробовал что-то вроде усреднения прошедшего времени за последние 3кадры, и используя этот временной шаг в качестве частоты обновления анимации.Это должно устранить большую часть дрожания, вызванного заносом буфера, за счет небольшой задержки при реагировании на большие изменения рабочей нагрузки.