Фиксированная и переменная частота кадров в играх: что лучше и когда?

Похоже, что большинство 3D-разработчиков предпочитают переменный FPS: движки Quake, Doom и Unreal масштабируются как вверх, так и вниз в зависимости от производительности системы.

• По крайней мере, вы должны компенсировать слишком высокую частоту кадров (в отличие от игр 80-х, которые работали в 90-х, слишком быстро).
• В любом случае ваш основной цикл должен быть параметризован временным шагом, и пока он не слишком длинный, достойный интегратор, такой как RK4, должен плавно обрабатывать физику. Некоторые типы анимации (спрайты с ключевыми кадрами) могут быть проблематичными для параметризации. Сетевой код также должен быть умным, чтобы, например, игроки с более быстрыми машинами не стреляли слишком много пуль, но этот вид дросселирования в любом случае необходимо будет сделать для компенсации задержки (параметризация анимации также поможет скрыть отставание сети).
• Код синхронизации необходимо будет изменить для каждой платформы, но это небольшое локализованное изменение (хотя некоторые системы затрудняют чрезвычайно точную синхронизацию, Windows, Mac, Linux кажутся приемлемыми).
• Переменная частота кадров обеспечивает максимальную производительность. Фиксированная частота кадров обеспечивает стабильную производительность, но никогда не будет достигать максимума на всех системах (похоже, это является препятствием для любой серьезной игры).

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

Если это 2D-игра-головоломка, вы, вероятно, можете обойтись фиксированной частотой кадров, возможно, слегка параметризованной для супермедленных компьютеров и моделей следующего года.

Я склоняюсь к модели с переменной частотой кадров, но внутренне некоторые системы имеют фиксированный временной шаг. Это довольно легко сделать с помощью аккумулятора времени. Физика — это одна из систем, которую лучше всего запускать с фиксированным временным шагом и при необходимости запускать ее несколько раз за кадр, чтобы избежать потери стабильности и обеспечить плавность симуляции.

Немного кода для демонстрации использования аккумулятора:

const float STEP = 60.f / 1000.f;
float accumulator = 0.f;

void Update(float delta)
{
    accumulator += delta;

    while(accumulator > STEP)
    {
        Simulate(STEP);
        accumulator -= STEP;
    }
}

Это ни в коем случае не идеально, но представляет основную идею — есть много способов улучшить эту модель. Очевидно, что есть проблемы, которые нужно решить, когда частота кадров на входе неприлично низкая. Однако большим преимуществом является то, что независимо от того, насколько быстрой или медленной является дельта, симуляция движется с плавной скоростью в «времени игрока», и именно здесь пользователь будет воспринимать любые проблемы.

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

Один вариант, который я, как пользователь, хотел бы видеть чаще, — это динамическое изменение уровня детализации (в широком смысле, а не только в техническом смысле), когда частота кадров выходит за пределы определенного диапазона. Если вы выполняете рендеринг со скоростью 5 кадров в секунду, отключите рельефное отображение. Если вы выполняете рендеринг со скоростью 90 кадров в секунду, немного увеличьте навороты и дайте пользователю несколько более красивых изображений, на которые он может тратить свой процессор и графический процессор.

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

Это я, конечно, говорю как пользователь игр, причем несерьезный — я никогда не пытался написать нетривиальную игру.

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

Если, например, вы добавляете время кадра * скорость к положению, и время кадра становится очень маленьким, а положение большим, ваши объекты могут замедлиться или перестать двигаться, потому что вся ваша дельта была потеряна из-за точности. Вы можете компенсировать это, используя отдельный аккумулятор ошибок, но это боль.

Фиксированное время кадра (или, по крайней мере, нижняя граница длины кадра) позволяет вам контролировать, сколько ошибок FP необходимо учитывать.

Мой опыт довольно ограничен несколькими простыми играми (разработанными с помощью SDL и C++), но я обнаружил, что довольно просто реализовать статическую частоту кадров. Вы работаете с 2D или 3D играми? Я бы предположил, что более сложные 3D-среды выиграют больше от переменной частоты кадров и что сложность будет выше.