Каковы преимущества укупорки кадров в секунду? (Если есть)

Я работаю над простой игрой в OpenGL, использую SDL для инициализации и ввода дисплея, и, судя по всему, у меня есть две опции. Номер один просто спит для оптимального времени-кадра - theTimeTakenToRender, когда оптимальное время-кадра в секундах = 1 / theFramerateCap. (Я не совсем уверен, если это необходимо, поскольку это эквивалентно использованию vsync, что может быть более точным. Если мое предположение верно, скажите, пожалуйста, SDL + OpenGL имеет vsync по умолчанию, и если нет, то как чтобы включить его.) Другой - измерить время с момента рендеринга последнего кадра и просто соответствующим образом отрегулировать движение. (Чем меньше времени требуется для рендеринга кадра, тем меньше объектов перемещаются в этом кадре). Каковы преимущества и недостатки этих двух методов с точки зрения производительности, уменьшения мерцания и т. Д.?

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

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

Посмотрите презентацию Microsoft GameFest « Что в кадре: разрыв, задержка и частота кадров», чтобы узнать подробности здесь. Кармак также имеет ряд постов в блоге , которые полезны в этом.

Также имейте в виду, что некоторые математические вычисления могут выйти из строя, когда вы запускаете кадры с использованием низких deltaTзначений - или даже когда вы используете переменные deltaTвообще (вещи могут становиться сложнее или даже сложнее делать «стабильным» и предсказуемым образом, что важно для вещей как повторы и некоторые формы сетевой синхронизации). Смотрите Fix your Timestep для некоторого понимания здесь.

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

Вы никогда, никогда, никогда, никогда не должны использовать Sleep для управления частотой кадров .

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

Я не говорю, что уступать ЦП, если вам нечего делать, это плохо; отнюдь не. Но это не то же самое, что управление частотой кадров, и Sleep - это решение, которое подходит для первых, но не для последних.

Вместо этого проверьте, сколько времени прошло, и если пришло время запустить кадр, то сделайте это, в противном случае - и если вы хотите сэкономить некоторое количество ЦП - спите в течение минимального времени - 1 миллисекунда. Также убедитесь, что таймер сна настроен в соответствии с вашей платформой, чтобы дать вам хорошее разрешение; то есть, когда вы произносите этот вызов «Sleep (1)», у вас действительно есть шанс действительно спать в течение 1 миллисекунды, а не что-то вроде 15, 20 или 30 (что было бы иначе). Я верю, что SDL сделает это автоматически для вас.

Вы также можете внести в него некоторую слабость, чтобы, если приближается время для запуска кадра, вы останавливаете режим «Сон» и начинаете работать ровно, пока кадр не сработает, что может помочь вам точнее достичь желаемого интервала кадра.

То, как это выглядит в конечном итоге, представляет собой целую кучу вызовов Sleep (1), чередующихся со случайным кадром, и это нормально. Вы по-прежнему отказываетесь от процессора, когда он вам не нужен, но ваши кадры все равно смогут работать вовремя.

Вероятно, наиболее важным преимуществом ограничения частоты кадров является то, что он может помочь предотвратить буквальное физическое повреждение машины. Они забыли сделать это на Starcraft II, что оказалось очень проблематичным (и дорогим) для некоторых пользователей, пока они не исправили его.

Как упоминалось ранее, это снижает загрузку процессора. С другой стороны, и все более важно, что также истощает срок службы батареи. В качестве хорошего примера, FTL работает почти на 100% CPU на моем MBA. В результате он разряжает батарею за> 2 часа и сильно нагревается. (Как более прямой результат, я удалил и больше не играю это ...). Крышка рамы предотвратила бы это.

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