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

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

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

  • питание для разных технические характеристики системы;
  • простота разработки / обслуживания;
  • простота переноса;
  • финальное выступление.
6
frame-rate

5 ответов

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

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

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

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

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;
    }
}

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

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

4

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

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

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

3

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

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

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

2

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

0