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

Question

Поработав некоторое время над разработкой игр, я столкнулся как с переменной частотой кадров (когда вы вычисляете, сколько времени прошло с момента последнего тика, и соответствующим образом обновляете движение актера), так и с фиксированной частотой кадров (когда вы вычисляете, сколько времени прошло, и выбираете либо установить фиксированный промежуток времени, либо перейти в режим ожидания до появления следующего окна).

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

• Соответствие различным системным спецификациям;
• Простота разработки/обслуживания;
• Простота переноса;
• Финальное выступление.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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