Этой заметкой я хочу запустить цикл статей, посвященных компьютерной графике, математике и физике в контексте компьютерных игр. В общем, пора сменить сферу деятельности и окунуться в разработку игр.
Недавно приобрел себе новый монитор для ПК. Так как старый перестал включаться, то это была вынужденная мера. Старенький Samsung проработал с 2006 до 2022 года без сбоев. Есть подозрения на потерю ёмкостей пусковых конденсаторов. Попробую их поменять, но так лень ехать до магазина с радиодеталями. В итоге было принято спонтанное (такое же как и поломка старого моника) решение покупать какой-то любой монитор. Выбор упал на Asus с FullHD разрешением. Расскажу о нем в другой заметке.
В итоге я наконец-то полностью обновил свой ПК с 2006 года. О сборке ПК я рассказываю в этой статье.
Ну и стало мне интересно поиграть в Assassin’s Creed Odyssey. Эта игра привлекла меня своим историческим сюжетом. Да и самому мне очень нравилась серия Assassin’s Creed. Правда много лет назад играл только в первую часть, которую ещё тянул старый ПК.
Установил я эту игру на ПК еще тогда, когда у меня работал старый монитор. И так как в планах уже была покупка нового, мне стало интересно, а почему не сделать замер производительности на старом и новом мониторах. Ну а в чем у нас принято измерять производительность ? В некотором загадочном целом числе, которое называется FPS 🤔
Получаются идеальные условия:
1. Игра одна и та же.
2. Железо одно и то же.
3. Меняется только монитор.
Определение и немного фактов
FPS или frame per second или framerate — всё это одно и то же, и на русском языке означает частоту смены кадров, количество кадров в секунду, кадровую частоту. Вот что пишут в википедии по теме кадровой частоты.
Интересен тот факт, что цифровом кинематографе общепринятым стандартом стала частота в 24 кадра в секунду. Видимо, экспериментальным путем пришли к такой частота, потому что она более всего соответствовала эстетике профессионального художественного кино. И ещё для ощущения просмотра фильма нам не требуется большая плотность данных. Мы настолько привыкли к этой частоте, что теперь видео в 60 кадров в секунду кажется нам каким-то другим, любительским, некинематографичным, если так можно выразиться.
Отличие 30 и 60 кадров в секунду огромное, для человеческого глаза это очень заметно. А вот дальнейшее увеличение частоты уже интереснее. Например, у мониторов можн заметить разницу между 60-75 Гц и 144 Гц, а вот разницу между 165 Гц и 144 Гц вроде как почувствовать нельзя. В целом, с какого-то момента это всё уже гиперболизируется маркетологами. Покупайте скорее! Ведь чем больше, тем лучше. Но почувствуете ли вы разницу, если за 20 Гц переплатите 20 тыс. рублей ? У меня вот есть сомнения. А вы напишите своё мнение в комментариях.
Итак, определение еще раз:
FPS (Frames Per Second) — это количество кадров в секунду, которые отрисовывает ваша игра. Чем это число больше, тем плавнее будет выглядеть анимация в игре.
Всегда ли чем больше FPS, тем лучше ?
Нет. Это интересная характеристика, но она должна быть в балансе с другими факторами. Считается, что минимальная частота анимации в 12 Гц еще более менее воспринимается в качестве плавной. Слишком завышенный FPS тоже плохо. Например, есть информация, что изображение перестает быть плавным, если FPS намного превышает частоту развертки монитора. В технических характеристиках вашего монитора есть поле, которое характеризует максимально возможную частоту обновления изображения на дисплее.
Кстати, вот интересный русскоязычный сайт по тематике геймдева:
https://gamedev.ru/
Как оценить FPS в своей игре программными методами
Давайте сразу сделаем замечание. Эта характеристика зависит от множества факторов. Она нестабильна. Она меняется. Мы можем говорить только об оценке средних значений. Допустим у нас есть игра, которая состоит из последовательных кадров (фреймов). На каждый кадр нужно время (на расчет, на отрисовку, на вывод). При отрисовке каждого нового фрейма, в самом начале мы можем положить текущий временной отрезок в переменную, допустим, под названием t_start_frame. Сделать это можно с помощью функции clock_t clock(void) (в контексте языка программирования C или C++). В конце фрейма мы можем опять вызвать функцию clock() и занести результат её работы в переменную t_end_frame.
Вы уже догадывайтесь чему будет равна разница между этими переменными? Думаю, что да. Разница delta, которую мы можем посчитать как delta = t_end_frame - t_start_frame , даст нам длительность нашего кадра. Тогда, если у нас есть время одно кадра, то часту можно определить как fps = 1/delta. С точки зрения школьных задач по физике всё нормально. НО... как всегда есть «но». Это было бы справедливо только для одинаковых кадров. Сами подумайте, имеем ли мы право считать частоту обновления, основываясь только на одном кадре? Сомнительно.
Как улучшить точность оценки? Можно посчитать количество кадров, которые удастся отрисовать за определенное время. Взять время 1 секунду или 10 секунд, насчитать количество кадров, разделить количество кадров на временной диапазон. И вот уже у нас имеется динамическое усреднее FPS, более точное, чем рассчитанное по одному фрейму.
Для лучшего понимания работы функции clock() можете прочитать очень простой пример на моем канале:
Время работы алгоритма простого поиска элемента в массиве. Время работы кода на C++.
Тут не всё так просто, ведь проблемы подсчета через delta могут быть еще связаны с синхроимпульсом монитора. Вертикальный синхроимпульс — это и есть вертикальная синхронизация, с помощью которой можно найти баланс между производительностью и энергопотреблением компьютера. Почитать про настройки вертикальной синхронизации в windows можно здесь (правда тут только про nVidia).
Получается, что FPS является показателем для оценивания производительности графических приложений, а также графических систем (видеокарта + драйвер). Однако, это возможно только при выключенной вертикальной синхронизации. При включённой вертикальной синхронизации количество FPS не может быть больше частоты вертикальной развёртки монитора (обычно 72, 75, 85, 100, 120, 144, 165 Гц), поэтому тестирование со включённой вертикальной синхронизацией всегда некорректно.
Оптимальное значение FPS равно значению частоты вертикальной развертки, так как больше кадров приложение всё равно не сможет отрисовать, и в этом случае имеет смысл тратить вычислительные ресурсы системы на другие вещи (увеличить детализацию физики, например).
Проблема анализа FPS
Когда мы пытаемся оценить кадровую частоту, нам нужно понимать что именно является узким местом в работе программы или игры. Чаще всего ограничивает скорость процессор (CPU) или видеокарта (GPU). Но бывает и так, что в разных местах и в разных кадрах скорость падает то на CPU, то на GPU. Бывает даже в пределах одного кадра.
Если ограничивает работу процессор CPU, то неравномерный FPS возникает из-за задержке в вычислениях в коде программы.
Если ограничивает работу видеокарта GPU, то ситуация может быть сложнее. Современные GPU работают асинхронно с процессором. Драйвер кеширует все команды на отрисовку, в том числе команду на окончание кадра. Таким образом, после этой команды CPU не ждет видеокарту, а продолжает заниматься обсчетом следующего кадра. Это приводит к тому, что в очереди на отрисовку одновременно находятся несколько разных кадров, и когда эта очередь переполняется, процессор долго ждет карточку. Следствие — один кадр (который был занесен в очередь) может быть намного быстрее другого (в котором очередь переполнилась). Результат — нестабильные измерения FPS. Так как большинство игровых и физических сущностей живет ДОЛЬШЕ относительно времени кадра.
Опять приходим к тому, что на практике нужно усреднять время кадра по нескольким последним кадрам.
Что произойдет, если не изменяя настроек игры, просто подключить другой монитор?
Теперь о том, о чем я хотел рассказать в самом начале этой статьи. Замеры производительности игры Assassin’s Creed Odyssey на мониторе с разрешением SXGA (1280 x 1024 ) и на мониторе FHD (1920 x 1080).
Итак, на старом мониторе было среднее значение FPS в 56 кадров (это комфортно для игры). Когда я приобрел и подключил новый монитор, то среднее количество FPS стало 46 кадров. Вот так вот аккуратно потерялись 10 FPS 😄. Изменился ли от этого комфорт? Вообще нет. По ощущениям всё осталось таким же. На глаз абсолютно незаметно. Зато большой монитор - приятно, больше область видимости.
Как зависит FPS от разрешения экрана
Мне всегда было интересно, а потеря FPS пропорционально разрешению экрана? Давайте посчитаем:
Как видите, зависимость нелинейная. Пока вашей GPU хватает видеопамяти, частота (FPS) падает не так быстро, как увеличивается количество пикселей, с которыми нужно работать. При переходе от старого разрешения 1280x1024 на довольно популярное 1920x1080 было потеряно 18% FPS, хотя количество пикселей нового монитора увеличилось на 58%.
Как зависит количество видеопамяти от разрешения экрана
Теперь интересно то, как зависит количество видеопамяти, которое резервирует игра. Оно увеличивается пропорционально количеству пикселей? Или нет? Давайте проверять:
Получается, что нет. Разрешение увеличилось на 58%, а занимаемая игрой память увеличилась не более чем на 6%. Почему так происходит? Потому что пропорционально разрешению увеличивается только память, необходимая для отрисовки конкретного ОДНОГО кадра. Для FullHD это будет оцениваться следующим образом.
Для разрешения 1920x1080 при глубине цвета в 32 бита (4 байта) мы получим 1920×1080×4 = 8 294 400 байт ≈ 7.91 Мбайт. То есть на один кадр хранимого изображения нужно примерно 8 Мбайт. Откуда берутся 3500 Мбайт ?! Эти большие объемы занятой видеопамяти предназначены не для вывода кадра на экран, а для хранения текущих текстур, до которых главный герой может добраться за быстрое время. Всё, что находится вне поля зрения героя, может подгружаться динамически (при необходимости, то есть когда герой приближается к области, где нужно подгрузить текстуры).
Получается, что большое количество памяти нужно для хранения высококачественных текстур игры. А высокая частота работы чипов памяти и процессоров видеокарты нужна для стабильного и высокого FPS. И в реальности всё это сложнее, чем на приведенных формулах.
Но ведь начинать всегда нужно с простого, не правда ли? :)
Полезные ссылки по теме:
https://developer.nvidia.com/
https://www.amd.com/ru
https://gamedev.ru/
Глубина цвета
Рендеринг
Все, что нужно знать про вертикальную синхронизацию
Книги по компьютерной графике и разработке игр
Понравилас заметка ? Поставьте лайк, подпишитесь на канал! Вам не сложно, а мне очень приятно :)
Если Вам нужен репетитор по физике, математике или информатике/программированию, Вы можете написать мне или в мою группу Репетитор IT mentor в VK
Библиотека с книгами для физиков, математиков и программистов
Репетитор IT mentor в telegram