Что такое frame time в играх
Что такое «частота кадров в секунду»? 24, 30 и 60 FPS
Разбираемся, от чего зависит и на что влияет кадровая частота в играх, кино и мультипликации.
Кадровая частота (англ. frame rate) — это количество кадров, сменяющих друг друга за секунду. В кино, анимации или видеоиграх термин зачастую используют, чтобы пояснить, насколько изображение получилось «плавным». Единица измерения такой частоты тоже есть — это буквально кадры в секунду (англ. frame per second, или FPS). Чем их больше, тем «плавнее» изображение: если для фильмов норма — 24 кадра в секунду, то в разговорах про игры обычно упоминают цифры от 30 до 60.
Это, впрочем, не предельные значения. Так, в классических мультфильмах Уолта Диснея кадровая частота — 12 FPS, но картинка всё равно достаточно «плавная», чтобы не раздражать зрителей, — всё благодаря приёмам аниматоров. А вот профессиональный киберспортсмен, играя на самом современном компьютере, вполне может увидеть до 300 кадров в секунду. Рассказываем, откуда такой разброс и что в этом «фреймрейте» важного.
Сценарист и копирайтер. Утверждает, что видел все фильмы и прошёл все игры, но редакция отказывается ему верить.
24 кадра в секунду
24 FPS — стандарт в кинематографе. Показатель, наиболее комфортный для зрителя.
Впервые частоту киносъёмки осознанно выбрали пионеры кинематографа — братья Люмьер. Она тогда составляла 16 кадров в секунду. Это был строгий расчёт — расход 35-миллиметровой киноплёнки составлял ровно один фут (0,3048 метра) в секунду.
Во времена немого кинематографа скорость показа фильма нередко превышала частоту съёмки. Киномеханик, который вращал ручку проектора, подбирал темп в зависимости от настроения фильма и «темперамента» публики — от 18 до 30 кадров в секунду.
Ситуация изменилась с появлением звукового кино. Поскольку разная скорость воспроизведения меняла частоту звука и голоса становились выше, американские кинокомпании задумались о стандарте фреймрейта. В 1926 году таким стандартом стал показатель в 24 FPS — создатели кино выбрали его как компромисс между «плавностью» картинки, расходом плёнки и возможностями техники. Как раз с этой частотой мы смотрим фильмы по сей день. Хотя исключения тоже бывают.
Кто-то снимает быстрее?
Современные режиссёры иногда проводят эксперименты с увеличением кадровой частоты, чтобы сделать изображение «плавнее» и тем самым усилить погружение. Один из самых известных примеров — «Хоббит» Питера Джексона, снятый с частотой 48 FPS.
Другой пример — фильм «Гемини» Энга Ли, снятый с частотой и вовсе 120 кадров в секунду.
Правда, чтобы увеличить в фильме кадровую частоту, вовсе не обязательно снимать его с высоким фреймрейтом — порой достаточно и современного телевизора с функцией «сглаживания движения» (англ. motion smoothing).
Дело в том, что частота обновления экрана у нынешних ТВ превышает общепринятую кадровую частоту кино — это может быть и 50 Гц против 24 FPS, и даже 120 Гц против тех же 24 кадров. Иногда это приводит к тому, что изображение начинает дёргаться и дрожать. Чтобы решить проблему, изобрели «сглаживание движения» — эта технология анализирует движение объектов и создаёт дополнительные кадры, будто бы заполняя ими «пустые» места.
Звучит здорово, однако на деле motion smoothing только портит изображение. Резкость картинки заметно увеличивается, порой возникают артефакты изображения, а естественная «смазанность» сцены, специально созданная режиссёром, становится едва заметной, сбивая фокус. И в результате возникает «эффект мыльной оперы».
По этой причине режиссёры и актёры выступают против технологии, называя её проклятием кинематографа. Хорошо, что пока это лишь опция, которую при желании можно просто отключить.
А что с кадрами в мультфильмах?
Сегодня во время съёмок кино оператор выставляет на камере нужную частоту. Всё сложнее, если речь идёт о мультипликации, ведь каждый кадр необходимо нарисовать вручную. По кадровой частоте анимация делится на несколько видов:
Чтобы снять 20 минут мультфильма в анимации вида 1s, необходимо нарисовать порядка 28 000 уникальных рисунков. Это весьма непростая задача, и потому мультипликаторы идут на всевозможные уловки, чтобы зритель не заметил недостающих кадров. Так, анимацию 1s чаще всего применяют только в активных сценах — например, если персонаж бежит.
Постепенно в создании анимации появились новые секреты. Первым работу мультипликаторов оптимизировал Уолт Дисней: ведущие художники сперва рисовали основные кадры (англ. keyframes), а после этого в дело вступали художники-фазовщики — они рисовали «промежуточные фазы движения»
(англ. in-between) и доводили анимацию до финального вида. Эти термины остаются актуальными для аниматоров и сегодня.
Для экономии кадров художники идут и на другие хитрости. Скажем, рисуют фон и на статичный рисунок накладывают прозрачные целлулоидные плёнки с подвижными элементами. А ещё аниматоры зацикливают кадры или же «раскладывают» персонажей и объекты в несколько слоёв — например, анимируют только губы на неподвижном лице.
В японской анимации — аниме — художники для упрощения своих задач зачастую пропускают промежуточные рисунки — фазовки. Из-за этого эмоции на лице персонажа меняются моментально.
В аниме также существует термин sakuga — это моменты, когда качество картинки возрастает и доходит до стандарта 1s. Приём используют для заставок, сюжетных поворотов или экшн-сцен.
Сколько кадров в видеоиграх?
Оптимальный фреймрейт в играх выше, чем в кино, — он начинается с 30 кадров в секунду. С точки зрения технологий кадровая частота в игровой индустрии работает иначе, нежели в кино, однако суть та же — чем больше FPS, тем лучше. Кроме того, именно счётчик FPS — главный показатель производительности той или иной игры.
Частота в 60 FPS обеспечивает куда более «плавное» изображение. Впрочем, важнее стабильная производительность. Высокий фреймрейт, который время от времени неожиданно «падает» до 35–45 кадров, игрок воспринимает хуже, чем стабильные 30 FPS. Любой такой сбой воспринимается как лаг, ведь мозг игрока «настраивается» на определённую кадровую частоту.
Кадровая частота игры во многом зависит от того, на какой платформе она запущена. Так, на ПК единственное ограничение в большинстве случаев — мощность «железа», которое может быть очень разным. Зачастую это вызывает дополнительные проблемы при оптимизации игры: сделать так, чтобы она работала одинаково на всех компьютерах, попросту невозможно — комбинаций «железа» слишком много.
При создании версий для игровых приставок, где установлены фиксированные комплектующие, ситуация немного проще — оптимизировать игру приходится под тот или иной «стандарт» (в зависимости от конкретной приставки). В этом случае, правда, возникает другая проблема: нередко мощности устройства не хватает для частоты в 60 кадров, и тогда разработчики искусственно ограничивают фреймрейт на отметке в 30 FPS. Это компромисс — низко, зато стабильно.
Правда, с появлением консолей нового поколения — Xbox Series X и PlayStation 5 — многие компании и студии при разработке стали целиться именно в 60 FPS, поскольку «железо» позволяет. По крайней мере, пока. Если верить рекламе, новые консоли способны выдавать и 120 FPS, но это, конечно, касается относительно «лёгких» с точки зрения графики игр.
«Мы никогда не пытались ограничить разработчиков в том, чего они пытаются добиться на нашей платформе, будь то 60 FPS на Xbox 360 или 4K и 60 FPS на Xbox One X. Мы хотим дать им инструменты для того, чтобы они создавали свои игры на любой из наших платформ. В поколении Xbox One X мы уже достигли момента, когда игры выглядят потрясающе, но у нас есть простор для того, чтобы сделать их ещё лучше. Я хочу, чтобы игры ощущались столь же здорово, как и выглядят. Думая о будущем, мы хотели сосредоточиться не только на количестве пикселей, но и на ощущениях от игр, которые обеспечивает высокий фреймрейт».
Фил Спенсер, глава Xbox.
Интервью, 2020 год
Похожего мнения придерживаются и разработчики, которые сотрудничают с Sony.
«Разрешения 4K достаточнo, его хватит надолгo. Но мне хочется вместо того, чтобы оставаться на уровне 60 кадров в секунду, поднять частоту до 120 или даже 240 кадров в секунду. Я думаю, это то, что изменит игры».
Кадзунори Ямаути, руководитель разработки серии Gran Turismo.
Интервью, 2020 год
И если в одиночных играх кадровая частота играет роль важную, но всё-таки не принципиальную, то в киберспорте высокий показатель FPS — залог успеха.
И не только он: ещё при подборе техники для соревнований профессиональные игроки учитывают частоту обновления экрана монитора. От неё зависит, как часто и быстро обновляется изображение на дисплее каждую секунду. Так, при частоте 60 Гц кадр меняется каждые 16 миллисекунд, при 144 Гц — каждые 6 миллисекунд.
Когда монитор обновляется с такой скоростью, разница не видна глазу, всё дело в мелкой моторике. После нескольких лет тренировок киберспортсмен в той же Counter-Strike: Global Offensive использует лишние 10 миллисекунд для более точного наведения прицела. Для реализации своего потенциала профессиональным игрокам необходима техника с максимальными характеристиками, даже несмотря на то, что упомянутая Counter-Strike — не слишком требовательная к «железу» игра.
Ещё один пример — Call of Duty: Black Ops — Cold War. Компания NVIDIA, которая выпускает видеокарты, в 2019 году провела исследование «фликшотов» — этим термином обозначают ситуации, когда игрок в шутере очень резко целится во врага и метко стреляет. В случае с Black Ops частота обновления 360 Гц улучшает качество стрельбы на 4% — по сравнению с монитором на 240 Гц. И этот небольшой перевес может оказаться решающим во время соревнования.
Что означают 1 % и 0,1 % при тестировании видеокарт и процессоров в играх
Содержание
Содержание
Все чаще при измерении производительности ПК в играх можно заметить показатели «0.1 % Low» и «1 % Low». Большинство неопытных пользователей не придают этому значения и по старинке смотрят только на средний FPS. На самом деле эти показатели очень важны и на них стоит обращать внимание. И вот почему.
Что такое средний FPS и Frame Time
Время, требуемое для отрисовки одного кадра называется Frame time или же «время кадра». Измеряется оно в миллисекундах, но обычно используют частоту кадров (Frame rate), которая обозначает количество кадров, отрисованных за единицу времени. Частота кадров же измеряется в количестве кадров в секунду — Frames per second или же FPS.
Главная единица, используемая при измерении производительности — средний FPS (AVG FPS) за весь промежуток времени. Средний FPS находится по формуле FPS = n/t, где n — количество кадров, отрисованное за все время, а t — время проведения теста. У среднего FPS есть недостаток, который не позволяют ему быть единственной единицей измерения в бенчмарках.
0.1 % минимальный и 1 % низкий FPS
При измерении FPS его среднее значение не является точной величиной, поэтому внимание стоит уделить другим — 1 % низкий и 0.1 % минимальный FPS. В нашем случае важно понимать, что время отрисовки кадра зависит от его сложности. Во время игры могут встречаться карты с большим количеством предметов и NPC в поле видимости игрока, на отрисовку которых будет уходить больше времени. Такие кадры могут задерживаться на экране, в результате чего картинка может фризить и испортить впечатление от игры. Проблема среднего FPS заключается в том, что при замерах время «длинных» кадров усредняется с «быстрыми», поэтому информация о первых теряется.
К примеру, за секунду было отрисовано 30 кадров с таким временем отрисовки в мс:
33, 57, 23, 13, 34, 68, 34, 40, 44, 16, 90, 27, 66, 87, 23, 37, 17, 23, 31, 21, 23, 20, 37, 12, 32, 36, 22, 14, 20, 10
В данном случае средний FPS равен 30 кадрам в секунду, а среднее время отрисовки кадра — 33,3 мс. Общая картина достаточно неплоха, но если взглянуть пристальнее, то можно заметить четыре кадра, время отрисовки которых в два, а то и в три раза больше среднего. Как и было сказано ранее, при высчитывании среднего времени отрисовки кадра и среднего FPS «долгие» кадры теряются на фоне «быстрых», в результате чего значения получаются неточными.
Было принято решение как-нибудь дополнить значения среднего FPS, чтобы лучше описать все кадры.
Существует такое понятие как процентиль, с английского — percentile (в русском языке чаще встречаются персентиль или перцентиль). В нашем случае это можно трактовать как значение, ниже которого находится определенный процент данных из общего набора. У нас 99-процентиль — это значение, ниже которого находятся 99 % данных из общего числа. И, если он равен 90 мс, то 99 % значений времени кадра из примера меньше 90 мс, а 1 % больше или равен этому числу.
В бенчмарках по договоренности используются 99.9- и 99-процентили. Поскольку обычно в качестве единицы измерения применяются FPS, то в данном случае используются обратные 0.1- и 1-процентили FPS. В народе их принято называть 0.1 % минимальный и 1 % низкий FPS. Обычно эти значения оказываются ниже среднего FPS, так как это часть данных, которая описывает редкие игровые события с многочисленным количеством объектов. Это говорит о том, что сложность кадров в сцене непостоянна. Плохо это только тогда, когда 0.1 % минимальный и 1 % низкий FPS «просаживаются» до неиграбельного уровня в результате чего картинка начинает подлагивать. Правда, оценить этот неиграбельный уровень статистически невозможно — для каждого он свой в связи с особенностями человеческого глаза и привычками геймера.
Математические объяснения недостатков среднего FPS (для любознательных)
Между временем кадра и частотой кадров есть математическая связь: значение FPS после отрисовки кадра — мгновенный FPS — обратно времени отрисовки этого кадра:
Поскольку время кадра обычно измеряется в миллисекундах, а частота кадров в единицах в секунду, вышеуказанная формула будет выглядеть вот так:
Например, кадр был отрисован за 25 мс, тогда получается, что мгновенный FPS по окончании его отрисовки был равен 1000/25 = 40 FPS.
Как уже было сказано ранее, средний FPS находится по формуле FPS = n/t. Кроме нее средний FPS можно найти так:
Где t — среднее время кадра, равное t = (t1 + t2 + t3 + … + t-нное)/n
n — общее количество кадров, t1, t2, t3 и т. д. — время отрисовки каждого кадра
То есть, средний FPS — величина, обратная среднему времени кадра. Подтверждается это тем, что время бенчмарка равняется сумме времени отрисовки всех кадров:
t1 + t2 + t3 + … + t-нное = t
Но почему же средний FPS — недостаточно точный показатель измерений? Так происходит, потому что средний FPS не является средним арифметическим значений мгновенного FPS:
FPS ≠ (FPS1 + FPS2 + FPS3 + … + FPS-нное)/n
FPS ≠ (1000/t1 + 1000/t2 + 1000/t3 + … + 1000/t-нное)/n
Для подтверждения этому приведем одну из вышеперечисленных формул:
FPS = 1000n/(t1 + t2 + t3 + … + t-нное)
Значения среднего FPS и среднего значения мгновенного FPS будут равны только в том случае, когда все кадры были отрисованы за одинаковые промежутки времени – t1 = t2 = t3 = t-нное = t, что на практике практически невозможно. В этом и заключается главный недостаток среднего FPS.
Средний FPS далеко не идеален, и при измерении производительности системы в играх ориентироваться только на него не стоит. 0.1% минимальный и 1% низкий FPS наоборот являются очень важными единицами измерения. Если говорить простым языком, то они показывают самые большие просадки FPS за время теста, портящие общее впечатление от игры.
Неуловимая проблема тайминга кадров
Технический директор Croteam Ален Ладавач, участвовавший в разработке Serious Sam и Talos Principle, рассказывает, как ему удалось найти причину торможения графики даже на самых мощных машинах.
Наконец-то появилось объяснение того, почему некоторые игры тормозят на вашем PC (и луч надежды на то, что в ближайшем будущем они тормозить перестанут).
Т-т-тормоза
Вы с нетерпением ждали следующей части вашей любимой серии видеоигр для PC и она наконец вышла. На этот раз вы хотите насладиться ею во всей полноте, поэтому потратили деньги и время на тщательную подготовку. Вы заменили процессор, поставили сверхсовременную видеокарту, добавили ещё ОЗУ — чёрт возьми, даже купили RAID на SSD. Игра должна быть плавной с самой заставки.
Предзаказ наконец разблокирован и вы только что завершили установку. В нервном предвкушении вы впервые запускаете игру. Пока всё хорошо — она работает с частотой 60 кадров в секунду. Или, по крайней мере, так сообщает счётчик кадров тюнера GPU. Но что-то не так. Вы делаете мышью резкие, хаотичные движения. Стрейфитесь влево-вправо, и тут игра… начинает тормозить! Блин, да как такое возможно? Как она может тормозить при 60 кадрах в секунду?
Если такое с вами никогда не случалось, то это может показаться смешным. Но если вы их испытали, то, скорее всего, ненавидите тормоза всей душой. Тормоза в играх. Это не старый добрый «лаг». Не низкая частота кадров. Это просто «тормоза», происходящие при высоких частотах кадров на идеальных, супербыстрых машинах. Что это, откуда они взялись и как от них избавиться? Позвольте мне рассказать вам историю…
Тормоза, плавность, скорость… это ведь одно и то же?
Видеоигры работали с частотой 60 fps ещё со времён первых аркадных автоматов в 70-х годах. Обычно ожидается, что игра работает с той же частотой, которая используется дисплеем. Так было до популяризации 3D-игр, в которых впервые стала допустимой пониженная частота кадров. В 90-х, когда «3D-карты» (так мы называли их до того, как они стали «GPU«) начали заменять программный рендеринг, люди играли в игры при 20 fps, а 35 fps считались приличным значением для серьёзных сетевых боёв. Я не шучу.
Сегодня у нас есть супербыстрые машины и «разумеется, они могут работать при 60 fps«. Однако количество разочарованных скоростью игр пользователей как никогда велико. Как такое возможно? Проблема оказывается не в том, что игры не могут работать достаточно быстро, а в том, что они тормозят, даже когда могут работать быстро!
Если почитаете разные игровые форумы, то наверняка найдёте подобные сообщения:
Можно подумать, что это единичные проблемы, но посмотрите на статистику поисковых запросов Google:
За последние пять лет тормоза (stutter) стали (относительно) более серьёзной проблемой, чем скорость!
(Учтите, что это относительные значения. Они не значат, что в целом люди спрашивают о торможениях больше, чем о частоте кадров. Они значат, что запросы о частоте кадров (frame rate) остаются на том же уровне, а количество запросов о тормозах растёт, особенно в последнее время.)
Десяток лет в поисках причины необъяснимых тормозов
Пациент скорее жив, чем мёртв, просто тормозит чуть больше, чем нужно.
Впервые я столкнулся с этой проблемой ещё примерно в 2003 году. Мы работали над Serious Sam 2, и пользователи начали отправлять нам отчёты о том, что они тестировали что-то на пустом уровне, и при перемещениях мыши движения не были плавными. Это сопровождалось очень характерным паттерном на графике частоты кадров, который мы прозвали «кардиограммой».
Мы думали, что где-то в коде есть баг, но не могли его найти. Казалось, что проблема появляется и исчезает случайным образом — после перезапуска приложения, перезагрузки машины… а потом игрок менял какую-нибудь опцию скорости и она исчезала. Потом игрок снова включал эту опцию, но проблема не возвращалась. Она была похожа на призрака.
Очевидно, что эта проблема возникала не только у нас. Наблюдая за теми же проблемами в других играх, мы начали думать, что виноваты драйверы. Но это происходило на видеокартах разных производителей. Даже на разных API (OpenGL, DirectX 9, DirectX 11…) — единственным общим у них было то, что они появлялись на разных машинах, в некоторых сценах… иногда.
Несси, бигфут… почти столь же неуловимые, как и проблема с «кардиограммой».
Мы выпустили ещё несколько игр, но это странное поведение по-прежнему появлялось и исчезало. Некоторых пользователей оно раздражало, и мы рекомендовали им изменить опции скорости — иногда это помогало, иногда нет. Такова жизнь, не правда ли?
Но однажды, в отличный зимний день в начале 2013 года мой коллега Дин позвал меня, чтобы я увидел ещё один пример этой проблемы, который он на тот момент мог относительно стабильно воспроизводить. На этот раз проблема возникала на уровне из Serious Sam 3. Мы экспериментировали с опциями в этой сцене, пока до меня внезапно не дошло. Я понял, в чём была причина! И она была очень проста — неудивительно, что она ускользала от всех в течение десятка лет.
Изменив всего одну очень простую опцию игрового движка, мы смогли заставить эту проблему появляться и исчезать в этой конкретной сцене. Но нам стало сразу же очевидно, что на её качественное решение потребуется гораздо больше усилий. Усилий не только с нашей стороны, но и всей игровой экосистемы PC — программистов драйверов GPU, разработчиков API, поставщиков ОС — каждого.
В чём же была причина всё это время
Хотел бы я показать вам её на примере сцены из Serious Sam 3, которую мы с Дином исследовали пять лет назад. Или даже ещё лучше — на примере тестовой сцены из Serious Sam 2, в которой мы впервые её увидели. Но, к сожалению, после замены «железа» этот ускользающий зверь может переместиться в другую сцену. У меня есть сцена из The Talos Principle, в которой мне недавно удалось воспроизвести эту проблему, и я заснял несколько видео, позволившие проанализировать её более подробно.
Но прежде чем мы начнём, убедитесь, что вы на самом деле смотрите видео в 60 fps. Для просмотра представленных ниже примеров переключитесь в 1080p60, как показано на картинке:
Чтобы смотреть видео в 60 fps, переключитесь в YouTube на 1080p60.
Если вы всё сделаете правильно, а ваш компьютер и веб-браузер способны показывать видео с частотой 60 fps, то представленное ниже видео должно воспроизводиться плавно и без всяких тормозов. Если это не так, то именно поэтому мы и говорим об этом — многие другие приложения тоже демонстрируют такое поведение, не только игры. Пока я могу только рекомендовать вам попробовать посмотреть видео на какой-нибудь другой машине, или просто читать текст.
Проверка, проверка, раз, два, три… Вы должны видеть это видео в плавных 60 fps.
А теперь перейдём к делу. Если вы сталкиваетесь с тормозами, то вероятнее всего это выглядит примерно так:
Вот как выглядят «тормоза при 60 fps». Мы называем этот симптом «кардиограммой».
Да, именно так выглядят «тормоза», даже когда игра работает с 60 fps. Вы могли сталкиваться с чем-то подобным в любой современной игре, и вероятно думали, что «игра не оптимизирована». Так вот, вам стоит пересмотреть свою теорию (о том, что такие тормоза возникают из-за «медленного» рендеринга игры). Если игра «слишком медленная», то это значит, что в какие-то моменты она не сможет достаточно быстро отрендерить один кадр, а монитору придётся заново показывать предыдущий кадр. Поэтому когда мы записываем видео такой игры в 60 fps, то видим «пропущенные кадры». (Это такие кадры, при которых следующий кадр не был отрендерен вовремя, поэтому текущий кадр показывается дважды.)
Ну как, нашли? Нет? Странно, не правда ли.
Видео выглядит не плавным, когда смотришь всю анимацию в целом, но когда рассматриваешь покадрово, разрывов нет!
Как такое может быть?
Позвольте мне объяснить более подробно. Вот сравнение идеально плавного видео и видео с тормозами в виде «кардиограммы», воспроизводимые на 1/20 от исходной скорости, чтобы мы могли видеть отдельные кадры:
Сверху правильное видео с 60 fps, снизу «кардиограмма». Воспроизведение замедлено в 20 раз.
Можно заметить две вещи: во-первых, они действительно воспроизводятся с одинаковой частотой — когда сверху есть новый кадр, снизу тоже есть новый кадр. Во-вторых, они по какой-то причине движутся немного по-разному — есть заметный «разрыв» в середине изображения, который становится то более, то менее заметным.
Внимательный зритель может заметить и ещё одну любопытную деталь: нижнее — тормозящее — изображение — которое считается «медленным»… на самом деле «опережает» правильное. Странно, правда?
Если мы посмотрим на два соседних кадра и их тайминги (заметьте, что во всех показанных мной видео были точные таймеры (с точностью 1/10 000 секунды), то можем заметить нечто очень интересное: первые два кадра идеально синхронизированы, но третий…
Шесть идущих друг за другом кадров из видео с точными таймингами. Верхние — правильные, нижние — с «кардиограммой».
…на третьем кадре мы видим, что дерево в «тормозящем» видео значительно опережает свою копию из правильного видео (обведено красным). Также можно заметить, что на этот кадр, похоже, ушло больше времени (обведено жёлтым).
Постойте… если видео «медленнее», и на кадр «ушло больше времени», то как он может опережать правильный?
Чтобы разобраться в этом, вам нужно понять, как в наше время игры и другие трёхмерные интерактивные приложения реализуют анимации и рендеринг. (Опытные разработчики должны простить меня за то, что я надоедаю им с очевидными вещами, но мне нужно быть уверенным, что текст смогут понять все читающие этот текст игроки.)
Краткая история таймингов кадра
Давным-давно, в далёкой-далёкой галактике… Когда разработчики создавали первые видеоигры, они обычно подстраивались под точную частоту кадров, с которой работает дисплей. В регионах NTSC, где телевизоры работали при 60 Гц, это означало 60 fps, в регионах PAL/SECAM, где телевизоры работали при 50 Гц, это означало 50 fps. Они даже и думать не могли о какой-то возможности «пропуска кадра».
Большинство игр было очень вылизанными и упрощёнными концептами, работавшими на конкретном оборудовании — обычно на аркадном компьютере, или на «домашнем микрокомпьютере», наподобие ZX Spectrum, C64, Atari ST, Amstrad CPC 464, Amiga и т.д. По сути, разработчик создавал дизайн, реализовывал и тестировал игру под конкретную машину и конкретную частоту кадров, и был на 100% уверен, что она никогда не пропустит ни кадра.
Скорости объектов тоже хранились в единицах «кадров». Поэтому говорили, не на сколько пикселей в секунду должен двигаться персонаж, а на сколько пикселей за кадр. Известно, что в Sonic The Hedgehog для Sega Genesis скорость вращения, например, была равна 16 пикселям за кадр. У многих игр даже были отдельные версии для регионов PAL и NTSC, в которых анимации вручную рисовались специально под 50 fps и 60 fps. По сути, запуск при любой другой частоте кадров даже не рассматривался.
Поэтому было очень сложно предсказать, сколько займёт симуляция и рендеринг одного кадра. (Стоит заметить, что на современных консолях «железо» по-прежнему неизменно, но сами игры всё равно часто непредсказуемы и сложны.)
Если мы не можем быть уверенными, при какой частоте кадров будет работать игра, нам приходится измерять текущую частоту кадров и постоянно адаптировать физику и скорость анимаций игры. Если один кадр занимает 1/60 секунды (16,67 мс), а персонаж бежит со скоростью 10 м/с, то в каждом кадре он перемещается на 1/6 метра. Но если кадр перестаёт занимать 1/60 секунды, а вместо этого внезапно начал занимать 1/30 секунды (33,33 мс), то надо начать перемещать персонажа на 1/3 метра (в два раза «быстрее») за кадр, чтобы на экране он продолжал двигаться с кажущейся постоянной скоростью.
Как же игра это делает? По сути она измеряет время в начале одного кадра, а затем в начале следующего и вычисляет разность. Это довольно простой способ, но он очень хорошо работает. То есть простите, он работал хорошо. В 90-х (вспомните фразу «35 fps считались приличным значением для серьёзных сетевых боёв» из начала статьи), людей более чем устраивал этот способ. Но в то время графическая карта (не забывайте, их даже ещё не называли GPU) была очень «тонким» элементом «железа», и попаданием объектов на экран непосредственно управлял основной ЦП. Если в компьютере не было 3D-ускорителя, процессор даже сам отрисовывал эти объекты. Поэтому он точно знал, когда они появятся на экране.
Что происходит сегодня
Со временем у нас появились более сложные GPU, и они становились всё более и более «асинхронными». Это значит, что когда ЦП отдаёт GPU команду отрисовать что-то на экране, то GPU просто сохраняет эту команду в буфер, чтобы ЦП занимался своими делами, пока GPU выполняет рендеринг. В результате это привело к тому, что когда ЦП сообщает GPU, что «это конец кадра», GPU просто сохраняет сообщение как ещё один фрагмент данных. Но он не относится к нему как чему-то особо срочному. Да и как он может — ведь ему по-прежнему нужно обрабатывать часть из ранее переданных команд. Он покажет кадр на экране, когда закончит всю работу, которую ему дали раньше.
Поэтому когда игра пытается вычислить тайминги, вычитая метки времени начала двух кадров, то актуальность этого, грубо говоря… весьма сомнительна. Давайте вернёмся к нашему примеру из коротких видео. У нас есть эти кадры, где камера перемещается вдоль деревьев:
Шесть идущих друг за другом кадров из видео с точными таймингами. Верхние — правильные, нижние — с «кардиограммой».
Теперь вспомните то, что я говорил о таймингах и перемещениях. В первых двух кадрах тайминг кадра равен 16,67 мс (то есть 1/60 секунды), и камера движется на одну и ту же величину и сверху, и снизу, поэтому деревья синхронизированы. На третьем кадре (внизу) игра увидела, что время кадра равно 24,8 мс (что больше 1/60 секунды), поэтому она думает, что частота кадров снизилась и торопится переместить камеру чуть дальше… только для того, чтобы обнаружить, что тайминг четвёртого кадра составляет всего 10,7 мс, поэтому камера движется здесь чуть медленнее, и деревья снова более-менее синхронизируются. (Синхронизация восстановится полностью только спустя два кадра.)
Здесь происходит следующее: игра измеряет то, что она считает началом каждого кадра, а эти тайминги кадров иногда по разным причинам колеблются, особенно на такой высоконагруженной многозадачной системе, как PC. Поэтому в некоторые моменты игра думает, что не успевает обеспечить 60 fps, и в какие-то моменты генерирует кадры анимации, рассчитанные на меньшую частоту кадров. Но из-за асинхронной природы работы GPU он на самом деле успевает обеспечить 60 fps для каждого отдельного кадра этой последовательности.
Именно это мы воспринимаем как тормоза — анимация, сгенерированная под изменяющуюся частоту кадров («кардиограмму») на самом деле отображается с правильной постоянной частотой кадров.
То есть, по сути, здесь нет никакой проблемы — всё действительно работает плавно, просто игра об этом не знает.
При этом мы возвращаемся к началу статьи. Наконец обнаружив причину проблемы (на самом деле, это иллюзия проблемы — ведь её на самом деле нет, так?), вот что мы сделали для проверки:
Сначала мы наблюдаем «кардиограмму», а затем используем небольшой трюк, чтобы избавиться от неё.
В первой части видео вы с самого начала можете увидеть проблему с «кардиограммой». Затем мы изменяем «магическую» опцию, после чего всё становится идеально плавным!
И на этом всё? Достаточно сделать так и всё станет замечательно?
Неужели решение настолько простое?
К сожалению — нет. Это всего лишь тест разработчиков. Если мы перестанем замерять частоту кадров в реальных ситуациях и просто будем предполагать, что она всегда равна 60, то когда она упадёт ниже 60 — а на PC она рано или поздно обязательно упадёт по тем или иным причинам: ОС запустит какой-нибудь фоновый процесс, включится экономия энергии или защита от перегрева GPU/ЦП… кто знает — то всё замедлится.
Итак, если мы изменяем частоту кадров, то возникают торможения, если нет — то всё в какие-то моменты может замедляться. Что же нам делать?
Реальное решение заключается в том, чтобы измерять не начало/завершение рендеринга кадра, а время отображения картинки на экране.
Как же нам сообщить игре, что изображение кадра уже показывается на экране? Вы можете удивиться, узнав это — но на сегодняшний день такого способа нет!
Это шокирует, я понимаю. Можно было ожидать, что это базовая функция каждого графического API. Но оказывается, в процессе постепенных улучшений тут и там все, в сущности, упустили сам смысл проблемы. Мы все забыли о тонких деталях своей работы, продолжая повторять одно и то же, а графические API эволюционировали во всех других аспектах, кроме этого: приложение никаким образом не может точно узнать, что кадр на самом деле отображается на экране. Мы можем узнать, когда закончится его рендеринг, но не когда он будет показан.
Что дальше?
Уже ведётся работа по созданию аналогичных и более качественных систем для всех основных графических API. Когда она закончится? Сложно сказать, потому что проблема лежит довольно глубоко внутри различных подсистем ОС.
Однако я заверяю вас, что Croteam безустанно работает над тем, чтобы эта проблема была решена как можно скорее, и все участники экосистемы интерактивной графики понимают и поддерживают наши усилия.
Мы стремимся сделать это решение доступным для более широкой аудитории, и когда это случится, мы подготовим апдейт The Talos Principle с реализацией этой функции.
Различные помехи и другие подробности
Последнюю фразу можно считать концом основного текста. Ниже представлены «бонусные разделы», практически не связанные друг с другом и основным текстом. Вероятно, я буду обновлять их, когда ситуация станет меняться, или в случае возникновения более сложных вопросов, требующих решения в ближайшем будущем.
«Композитор»
Эффект матового стекла? Да, для него нам определённо нужен композитор. Он просто-таки необходим, правда?
За кулисами со всем этим связан концепт под названием «композитный менеджер окон», или композитор. Это система, существующая теперь во всех ОС, которая позволяет окнам быть прозрачными, иметь размытый фон, тени, всплывающие поверх окна Skype и т.д. Композиторы даже могут отображать окна в 3D. Для этого композитор перехватывает управление над последним этапом создания картинки кадра и решает, что ему сделать с ней, прежде чем она попадёт на экран монитора. Это ещё больше всё усложняет.
В некоторых ОС композитор можно отключить в полноэкранном режиме. Но это не всегда возможно, а даже если и возможно — то разве можно запретить запускать игру в оконном режиме?
Управление питанием и тепловыделением против сложности рендеринга
Мы также должны учитывать, что современные ЦП и GPU не работают с фиксированной частотой, а имеют системы, изменяющие их скорости в соответствии с нагрузкой и температурой. Поэтому игра не может просто предполагать, что GPU и ЦП будут иметь одинаковую скорость в каждом кадре. С другой стороны, ОС и драйверы не могут ожидать, что у игры в каждом кадре будет одинаковый объём работы. Чтобы учесть это, необходимо разработать сложные системы для общения этих двух сторон.