Содержание
Одни видят разницу, другие нет. Кому-то 30 FPS на консолях хватает, а кому-то не хватает и 60 на компьютере.
В общем — FPS, как ни крути, критерием плавности изображения не является, а такие расхождения по ощущениям и цифрам — это не предрассудки людей, а ещё одно подтверждение того, что FPS на роль мерила плавности не подходит.
И чтобы разобраться в причинах всех этих проблем для начала нужно понять что же такое FPS.
FPS это аббревиатура расшифровываемая как «frame per seconds«, что переводится как «кадры в секунду».
Так исторически сложилось, что долгое время эта величина была жёстко связана ещё и с возможностями кинокамер/кинопроекторов и в дальнейшем и с развёрткой телевизоров/мониторов. И это очень важное уточнение, от которого и идут все последствия.
FPS как мерило кадровой частоты появился ровно в тот же день как был показан первый фильм, а вернее как был записан первый фильм.
И FPS был заложен в кино чисто механически.
Самая сложная задача для создания фильмов (кроме создания плёнки, которая к тому времени была уже решена) оказалась в том, чтобы заставить плёнку замирать напротив объектива на какое-то относительно длительное время неподвижно, а затем нужно было быстро перемотать плёнку на длину одного кадра чтобы начать экспонирование уже следующего кадра.
Для реализации этого процесса был придуман и выполнен «в железе» грейферный механизм.
Количество оборотов первичного вала в секунду и было равно количеству перемещений плёнки за ту же секунду. Таким образом — скорость вращения вала была равной FPS. А устанавливая ту же скорость для проекторов зритель получал и правильную скорость воспроизведения (так же важно отметить, что кино, во времена до 24-х кадров в секунду, «крутили» в родном для камер FPS, то есть показывали не в убыстрённом виде)
С появлением телевидения ситуация несколько изменилась. Однако осталось нечто общее, а именно неминуемость и неумолимость вещания. Вещание без глобальных изменений всех составных частей нельзя ускорить или замедлить, точно так же как нельзя ускорить или замедлить киносъёмку, не меняя скорость вращения приводного вала грейферного механизма, а если поменять эту скорость, то надо будет менять её и на всех проекторах.
Телевещание точно так же подчинялось механике, ведь вопрос хранения потока видео оказался куда сложнее, чем его вывод. Телевизор не может записать то что ему надо показать, он может только вывести то, что приходит через антенну. А значит источник вещания и сам телевизор должны быть строго синхронизированы. И для реализации этой задачи появились вещательные протоколы обмена данными. Не будем вдаваться в подробности и частности разнообразных черезстрочных развёрток, а так же вопросов передачи цвета (которые, кстати, породили такие развёртки как 23,976 FPS, 29,97 FPS и 59,94 FPS вместо 24, 30 и 60). Нам сейчас важно, то, что уже в те далекие аналоговые времена сигнал был
поделён на строки, а строки в свою очередь на меньшие участки. То есть
картинка была поделена на пиксели выводимые построчно. Одна строка за
другой. Через эфир передавалась величина яркости текущего пикселя, и что
самое важное, каждая строка передавалась с такой скоростью, с которой
телевизор был способен вывести эту строку. Собственно договорённости
вещателей с производителями телевизоров и стали протоколами передачи
телеэфира
. Если вещатель захотел бы поменять частоту передачи пикселей или длину строк или количество строк — то телевизоры бы не смогли показать картинку, равно как и производители телевизоров не могли делать устройства которые бы показывали больше строк или имели отличия в развёртке. Все эти ограничения были вызваны исключительно тем, что сохранить видео было нельзя, у телевизора нет памяти, есть только текущий сигнал, текущего участка текущей строки.
С приходом компьютеров всё изменилось.
Компьютер сам генерирует изображение и сам же его и сохраняет. Долгое время картинка может не меняться, а может меняться постоянно по требованию пользователя. Однако мониторы не изменились. Принципы вывода изображений для мониторов с электронно лучевой трубкой остались прежними. То есть с приходом компьютеров функцию вещания на себя взял именно компьютер. Протоколы передачи при этом сильно усложнились. На одном и том же мониторе можно и менять число строк, и менять дискретность строки (разрешение), и менять развёртку, то есть скорость вывода строк и кадра целиком. В протоколы добавлены служебные части, которые сообщают информацию о настройках, благодаря которой монитор конфигурируется под входящий видео сигнал. Но, всё остальное осталось неизменным. Развёртка, пусть и может меняться, но только один раз. На лету менять её нельзя. То есть полная смена кадра на мониторе происходит через равные промежутки времени и сейчас самое распространённое — это 60 раз за секунду (каждые ~16,7 мс). И хочет того или нет — компьютер должен отправлять на монитор все эти 60 кадров каждую секунду. Естественно в современном мире ЖК мониторов — когда пиксель не меняется между соседними кадрами — ничего физически с пикселем и не происходит.
Отсюда появляется первая проблема, которая как раз связана с «для консолей и 30 кадров хватает». Проблема в синхронизации.
Сам термин «синхронизация» говорит нам о том, что синхронизироваться должно «что-то» с «чем-то». Из этих двух «что-то» и «чем-то» мы пока рассмотрели только одно, а именно — частоту вывода изображения. А синхронизироваться она должна с частотой подготовки изображения. На практике есть два случая. Первый — это забить на синхронизацию. В видеокарте есть специальная часть отвечающая именно за вывод кадра и специальный буфер памяти, который хранит только сам кадр который надо вывести. И самый простой подход — это выводить то что есть в этом буфере. Теперь представьте, что монитор точно так же по строкам выводит кадр (ЖК мониторы так же выводят кадры построчно и попиксельно слева направо, сверху вниз), в какие-то моменты в буфере видеокарты кадр меняется на новый и просто посреди вывода кадра на мониторе оказывается два куска от разных кадров.
Естественно какой бы плавной не была картинка — разрывы портят впечатления. Проблема эта решается синхронизацией. Теперь уже понятно синхронизацией чего с чем. Если на монитор начал выводится кадр, то более новые на монитор подаваться не будут до тех пор пока не начнётся следующее обновление картинки на экране. Самый простой метод — вертикальная синхронизация, когда компьютер всецело подстраивается под монитор (Есть и другие методы, о них можно написать ещё одну статью в пару раз длиннее этой). Основная проблема в том, что когда мы не даём компьютеру своевременно выводить новые кадры — мы получаем на мониторе картинку с сильным запозданием, и это выражается в замедленности управления, то есть ощущение, как будто всё управление осуществляется через какую-то тягучую кисельную массу. Современные консоли используют именно вертикальную синхронизацию, поэтому нет разрывов, что сильно улучшает впечатления от плавности. А недостатки с задержками скрываются за тупым управлением, которое специально притупляется. Вводятся в игру лишние анимации движения персонажей, которые добавляют ему инерцию движений за которой не чувствуется задержек, плюс ещё мёртвый ход стиков на геймпаде, задержки беспроводных контроллеров и т.д. И в итоге задержки есть всегда, и задержки синхронизации — это их малая часть.
Но это только одна проблема, она частично решается современными методами синхронизации, с современными мониторами, но есть и другая, куда более глобальная проблема.
И проблема заключается в том, что игры — это не фильмы. Нет никакого грейферного механизма, который определяет сколько времени уйдёт на один кадр. В игре каждый кадр имеет индивидуальную сложность в его расчёте и отрисовке. Некоторые могут быть отрисованы быстрее, а другие — медленнее. Более того. Порой процессор или видеокарта сталкиваются с тем, что для выполнения работы нет нужных данных, и приходится обращаться вместо кешей в оперативную память, что долго, бывает и ещё хуже, что и в оперативной или видеопамяти нет нужных данных, а они на диске, и надо прочитать их с диска. Бывает и фоновая нагрузка становится приоритетнее для компьютера чем игра. Допустим работа антивируса, или какие-то запланированные системные процессы. Тут то мы и подходим к проблеме того, что FPS — не подходит для описания плавности. И причина как раз в том, что кадры разные. И одно и то же значение FPS может получится от различных комбинаций этих самых кадров.
Представим, что у нас есть игра которая показывает картинку в 50 FPS.
То есть делает 50 обновлений кадров в секунду.
Довольно просто можно посчитать сколько должно уходить времени на каждый кадр. Для этого мы берём секунду, и делим на 50.
Для удобства переводим секунду в миллисекунду и получаем 1000мс/50=20мс. То есть удельное время кадра у нас выходит 20 мс.
И теперь построим график времени кадра идеального случая, когда все кадры одинаковые.
Но по ранее сказанным причинам — так это не работает.
Допустим большая часть кадров будет почти в два раза быстрее отрисовываться, не по 20, а по 11,1(1) мс. В таком случае при равномерном фремрейте получилось бы почти ровно 90 FPS. Но, допустим, каждый пятый кадр будет длинной 100 мс, а не 11,1. В таком случае у нас за 1с отрисовывается 45 кадров длиной в 11,1 мс и 5 кадров длиной в 100 мс. Что в итоге даёт те же 50 FPS.
Естественно такие 50 FPS будут существенно отличаться от предыдущих 50 FPS.
Поэтому куда важнее, говоря про плавность учитывать именно стабильность длин кадров, а не то количество которое было выведено.
Естественно — тема это большая. На своём YouTube канале она освещена богаче и длится эта история уже больше двух лет, даже есть фирменная утилита для подсчёта других параметров, более подходящих.
Видео на YouTube канале "Этот компьютер"
Подписаться на канал
Автор,я прочёл. Надеюсь ты рад что не зря создал эту статью
Я долго ждал когда все укомплектуется в одной статье, спасибо за труд
На слух такую информацию трудно воспринимать и поэтому очень хорошо, что ты создал сайт, как важное дополнение к твоим видео или возможно даже замену им. Статью же сделать проще чем видео?