Инпут лаг sega
Обновлено: 04.07.2024
А так же:
I. при стрейфах A/D/A/D моделька не дергается на месте,а уходит в любую из сторон(не регает нажатия)
II. При медленных движениях мышки влево-вправо(3см/3см в обе стороны),и с последующим ускорением,на экране картинка по горизонтальной оси - изменяется и становится с меньшим диапозоном,а так же уплавняется.
III.Общая задержка сильно выше той,которая должна быть,ощущается кисельность.
IV. Ломается физика в игре(хит-рег,пули,движение оружия,микро-мувмент моделек)
Привет всем. Многие из вас знакомы с лагом ввода. Это бывает, когда вас в очередной раз убивают в компьютерной игре, и вы кричите: «Ну я же нажал блок/атаку/уворот». Ну а затем джойстик летит в стену. Знакомо? Происходит это потому, что между нажатием клавиш и появлением результата на экране проходит значительное время. Фактически, когда вы смотрите в экран — вы видите прошлое состояние, которое может абсолютно не отражать действительность.
Если вы разрабатываете собственную игру, или вообще занимаетесь рендером, и хотите уменьшить задержки ввода, то крайне советую заглянуть под кат.
Итак, Input lag в любой игре складывается из:
- Задержки на контроллере
- Сетевого лага (если это онлайн игра)
- Лага рендеринга.
Ссылки
Спасибо Denis Major за его исследования. Благодаря этому видео я впервые узнал, что проблема не в измененной физике игр, а именно в задержках ввода.
Опция runahead на RetroArch
Год назад разработчики RetroArch заявили, что добились на своем эмуляторе задержек меньше чем на оригинальных консолях. Я сам не пробовал эту опцию, но ее нужно иметь в виду.
Заключение
Мои замеры не учитывают задержку вывода монитора, но все измерения сделаны на одном и том же мониторе, поэтому она не влияет на результаты. Каждый замер я повторил 10 раз, получая иногда разброс в показаниях около 4 кадров, то есть 16мс. Полагаю, что дело в задержке вертикальной синхронизации при формировании изображения на консоли.
В целом, считаю, что мои измерения дают общие представления о задержках на двух сетапах и, возможно, будут полезны тем, кто выбирает себе способ.
Мои поиски
В детстве у меня была Sega Mega Drive, именно ее игры вызывают самую сильную ностальгию. Поэтому я буду описывать свои поиски комфортного сетапа именно для этой консоли. Сразу хочу сказать, что мое исследование не претендует на абсолютную точность измерений.
- Беспроводные геймпады — возможно меня осудят консольные гики, но я хочу комфортно играть сидя на диване в любой позе. Проводные геймпады это жутко неудобно, об них все задевают и долго так не поиграешь.
- Вывод по HDMI или DisplayPort — на моем мониторе нет аналоговых входов, поэтому купить оригинальную Sega Mega Drive я не могу. USB-адаптеры для аналогового захвата видео вносят свою задержку и неудобны. Покупать отдельный CRT-телевизор для приставки тоже не хочется
Эмуляторы
Всем хочется играть на современном железе, нормальных телевизорах и мониторах с HDMI, а еще запускать все возможные игры на одном устройстве. Для этого используются эмуляторы популярных консолей, которые запускаются на обычных X86 или ARM компьютерах. Вот самые популярные из них:
Retroarch
Самый популярный и продвинутый эмулятор. Умеет эмулировать PlayStation1, SNES, NES, GameBoy, Sega Genesis/CD и другие консоли. Работает на десктопных ОС Windows, Linux, MacOS и на современных консолях Xbox, Android, PlayStation2/3/4/Vita, Nintendo Wii/Switch и других. На его основе сделан популярный дистрибутив Recallox.⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
OpenEMU
Очень удобный и простой эмулятор для macOS. Поддерживает большинство популярных консолей и имеет удобную галерею игр, отсортированную по платформам. Из коробки поддерживает геймпады от Playstation 4 по bluetooth. Он уступает по возможностям RetroArch, но на мой вкус намного более удобный в использовании. Для своих замеров я буду использовать его, так как он сразу работает на macOS без пердолинга с настройкой геймпада.⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
В чем проблема?
Задержка ввода — это время от момента нажатия кнопки на геймпаде до реакции персонажа на экране. Здесь играет роль сразу множество факторов:
-
Задержка монитора/телевизора — некоторые современные телевизоры имеют задержку вывода изображения более 100мс. Это связано с постобработкой изображения, буферизацией, фильтрами и т.д. Здесь наглядно показано сравнение CRT и LCD телевизора с высокой задержкой. Обычно производители мониторов указывают в спецификациях скорость матрицы, имея в виду скорость переключения между цветами, но это не имеет отношения к задержке вывода изображения.
Про Хакспейс Нейрон
В нашем Хакспейсе Нейрон мы регулярно играем в ретро-приставки, реверсим железо и делаем много других штук. У нас вы сможете воспользоваться паяльником, осциллографом, частотным анализатором и пообщаться с веселыми задротами. Приходите в гости.
Тут у некоторых и аватары женские.
А так. Это не он фото крепил.
Vs, на счёт фото понятно,про трансов с их авами бог им судья.
подозреваю что надо некий золотой серединный баланс найти в прошивках и не перебарщивать так сказать.
Алкоголь мне всегда и во всем помогает. Попробуй пару чекунцов.
У меня с Nes играми всё отлично. Просто в телевизоре включаю игровой режим
Единственная консоль на которой нет Input Лага этой PSP
У меня порядка 10 портативных консолей, retron 5, всё равно на PSP input lag самый мелкий.
Вячеслав, так и сделал, ретроарч на х*р, со всеми модулями, и игры тоже туда же, кроме снесовских((
Марат, лол, если что почти на всех новых теликах есть такой режим, и он как раз уменшает импут лаг создаваемый телевизором
Марат, совет был тупой, я тебе написал о том что игровой режим импут лаг уменшает
Марат, потому что он есть, но не так заметен, просто инпутлаги от эмулятора, свистоперделок телевизора и матрицы складываются и он получается большой, игровой режим позволяет отключить свистоперделки и уменьшить задержку вывода на экран. Но он не в коем случае не убирает её, а лишь уменьшает до комфортных значений при которых играть приятно и его не заметно
Иван, просто не пойму, на родном снес мини эмуляторе, он намного меньше:/
Клон Sega Genesis
Беспроводные геймпады
Больше всего меня напрягали геймпады, работающие на частоте 2.4GHz. Зная проблемы bluetooth и WiFi на этом диапазоне, я первым делом попробовал измерять задержку самих геймпадов. Консоль поддерживает одновременное подключение проводных и беспроводных геймпадов. Оказалось, что беспроводная часть сделана с помощью отдельного модуля, который замыкает контакты так же, как проводной геймпад. То есть по сути эмулирует обычный проводной, с такой же распиновкой.
Радиомодуль, который эмулирует нажатия проводного геймпада
Я подключил щуп 1 осциллографа к светодиоду на геймпаде, а другой к контакту, соответствующему клавише Up на консоле. Когда сигнал будет обработан радиомодулем, он сэмулирует нажатие клавиши, и я увижу это на щупе 2. Сравнив разницу во времени между сигналами 1 и 2, я смог очень точно получить задержку, которую добавляет беспроводной геймпад. На осциллографе масштаб одной клетки 5мс, значит задержка беспроводных геймпадов 25мс.
Сравнение сигналов на геймпаде и консоли
Беспроводной модуль добавляет 25мс задержки
Замеры
Задержка на Sega Retro Genesis примерно 70мс
За вычетом 25мс задержки радимодуля получается, что сама консоль имеет задержку 50мс, что соответствует оригинальной Sega. При подключении проводных геймпадов, задержка, очевидно, будет меньше на 25мс. В целом геймплей ощущается как на оригинальной приставке, и я доволен. Огорчает только невозможность загружать свои игры (ROM-ы), но я попробую решить эту проблему с помощью перезаписываемого картриджа, либо попытаюсь найти возможность заливать на встроенную флешку игры самостоятельно.
CPU + GPU
Современные GPU — устройства максимально асинхронные. CPU отдает команды видеодрайверу, и идет заниматься своими делами. Драйвер накапливает команды в пачки, и пачками отправляет на видеокарту. Видеокарта рисует, а CPU в это время занимается своими делами. Максимальный FPS, который вы можете получить в этой системе ограничен одним из условий:
1. CPU не успевает отдавать команды видеокарте, потому что видеокарта очень быстро рисует. И нафига вы покупали такую мощную видеокарту?
2. Видеокарта не успевает рисовать то, что дает ей CPU. Теперь CPU халявит…
Для того, чтобы посмотреть, как красиво в паре работает CPU и GPU — есть различные профайлеры. Мы воспользуемся GPUView, который идет в составе Windows Performance Toolkit.
Лог от GPUView может выглядеть как-то так:
Вертикальные синие линии — это VSync. Наваленные горы кубиков — это горы пакетов, которые отправятся на видеокарту, когда та освободится. Штрихованный кубик — это пакет, содержащий переключение буферов. Иными словами — конец кадра. Любой кубик можно выбрать, и видеть, как он постепенно опускается в стопке, и отправляется на видеокарту. Видите на скриншоте кубик с желтой обводкой? Он обрабатывался аж на протяжении 3-х vsync-ов. А целый кадр занимает около 4-х VSync-ов (судя по расстоянию между разными штрихованными кубиками). Между двумя горами пакетов от разных кадров есть маленький зазор. Это то время, пока GPU отдыхал. Этот зазор маленький, и оптимизация на стороне CPU не даст большого выйгрыша.
Но бывают зазоры большие:
Это пример рендера из World of Warcraft. Расстояния между пакетами в очереди просто огромные. Более мощная видеокарта не даст прироста ни одного FPS. Зато если оптимизировать рендер на стороне CPU, то можно получить более чем двукратный прирост FPS на данном GPU.
Чуть более подробно можно почитать тут, а мы пойдем дальше.
Так где же лаг?
Так уж сложилось, что разрыв в производительности между Hi-End и Low-End видеокартами поистине огромен. Поэтому у вас обязательно будут возникать обе ситуации. Но самая грустная ситуация — это когда GPU не справляется. Выглядеть это начинает вот так:
Обратите внимание, сколько времени заняла обработка одного пакета. Кадр занимает 4 VSync-а, а обработка пакета занимает в 4 раза дольше! DirectX (OpenGL ведет себя так же) накапливает данных аж на 3 кадра. Но ведь когда мы кладем в очередь свежий кадр — все предыдущие кадры для нас уже не актуальны, а видеокарта по прежнему будет тратить время на отрисовку. Поэтому наше действие появится на экране спустя аж 3 кадра. Давайте посмотрим, что мы можем сделать.
1. Честное решение. IDXGIDevice1::SetMaximumFrameLatency(1)
Я честно, не представляю зачем копить данных на 3 кадра в буфере. Но MS видимо поняла ошибку, и начиная с DX10.1 у нас появилась возможность задать это количество кадров через специальный метод IDXGIDevice1::SetMaximumFrameLatency. Давайте посмотрим, как нам это поможет:
Ну что же. Стало значительно лучше. Но по прежнему не идеально, т.к. все равно ждем 2 кадра. Еще один недостаток решения — то что оно работает только для DirectX.
2. Трюк с ID3D11Query
Идея заключается в том, что в конце кадра мы устанавливаем D3D11_QUERY_EVENT. В начале следующего кадра — ждем, постоянно проверяя событие, и если оно прошло, то только тогда начинаем отдавать команды на отрисовку, и с наисвежайшими Input данными.
Картина практически идеальная, не находите? Ожидание я реализовал вот так:
Установка эвента тривиальна:
Ну и в сам рендер добавляем вначале ожидание. Затем перед самой отрисовкой собираем свежие Input данные, а перед самым Present-ом устанавливаем евент:
Недостаток костыля метода — работает только с DirectX. Но можно дождаться синхронизации другим оригинальным способом.
3. Воркэраунд через текстуру
Вот что мы делаем. У нас есть механизмы прочитать данные из видеоресурсов. Если мы заставим видеокарту что-то нарисовать, а потом попытаемся забрать, то произойдет автоматическая синхронизация между GPU-CPU. Мы не сможем забрать данные раньше, чем они будут нарисованы. Поэтому вместо установки евента я предлагаю генерить мипы на видеокарте для текстуры 2*2, а вместо ожидания евента — забирать данные из этой текстуры в системную память. В результате подход выглядит так:
Вот так мы ожидаем евент:
а вот так его устанавливаем:
В остальном подход полностью аналогичен предыдущему. Преимущество: работает не только на DirectX но и на OpenGL. Недостаток — маааленький оверхед на генерацию текстуры и передачу данных назад + потенциально потраченное время на «пробуждение» потока шедулером операционной системы.
Про попробовать
Конечно я тут растекался по дереву… но насколько проблема серьезная? Как пощупать это? Я написал специальную демонстрационную программу (требует DirectX11).
Программа представляет собой такое окно:
Тут рисуется 40*40*40=64000 (кстати каждый кубик — отдельный дравколл). GPU workload трекбар дает нагрузку на GPU (с помощью бесполезного цикла в вершинном шейдере). Просто опускаете с помощью этого трекбара фпс до низкого уровня, скажем 10-20, а потом пробуете правой кнопкой мыши крутить кубики, и переключать методы уменьшения Input лага с помощью радиобаттонов.
Вы только оцените какая огромная разница в скорости отклика. C Query Event комфортно крутить кубик даже при 20 фпс.
TL;DR В статье описывается известная проблема задержки ввода (input lag), которая проявляется при попытках играть в старые игры на современном железе: эмуляторах ретро-консолей, bluetooth-геймпадах и т.д. Иногда задержки настолько большие, что играть становится невозможно. Я опишу свой путь поиска приемлемой конфигурации для запуска моих любимых игр.
С волной популярности одноплатных компьютеров RaspberryPi, OrangePi многие знакомые накупили себе их пачками. Не придумав что с ними делать, они начали лепить из них ретро-консоли на базе эмулятора RetroArch и дистрибутива Recallbox. Когда я попробовал поиграть на этом в свои любимые игры детства я был удивлен: "Как я мог в это играть?". Физика игр казалась какой-то неправильной, ощущение отвратительное. Спустя время мне рассказали, что все дело в задержке ввода, которая на первый взгляд не ощущается как задержка, а именно как другая физика.
Оказалось, что проблема давно известна среди консольных гиков и ее активно исследуют. Я разберу чужие исследования и попытаюсь замерить задержку своего сетапа.
Macbook + Dualshok 4 + OpenEMU
Мне очень нравится геймпад от Playstation 4, я считаю его самым удобным из существующих геймпадов. Он может работать как по bluetooth, так и по проводу USB. Полностью поддерживается в OpenEMU из коробки без настроек.
Несмотря на все удобство OpenEMU, его главная проблема это просадка FPS в полноэкранном режиме. Я не уверен в чем причина, и возможно это исправляется, но у меня не получилось. Поэтому я играю в оконном режиме.
Интерфейс эмулятора OpenEMU. Все игры отсортированы по платформам.
Замеры
Задержка на макбуке с контроллером Dualshock4, подключенным по bluetooth равна примерно 150мс. Это много!
Макбук + Dulashock дает примерно 150мс задержки. Это достаточно много для комфортной игры, такая задержка заметно ощущается и в хардкорные платформеры вроде Contra Hard Corps играть некомфортно.
Несмотря на то, что задержка такой связки непростительно большая, она все равно заслуживает право на жизнь. Так как достаточно кинуть в рюзкак к ноутбуку геймпад, и получить в любом месте игровую консоль. Еще до замеров мне было понятно, что это не лучший вариант и я продолжил поиски.
Методика измерений
Самый доступный способ измерения задержки — запись на видео экрана и момента нажатия на кнопку джойстика. Современные смартфоны легко снимают видео в 240 FPS и больше, что вполне достаточно для замеров. Чтобы точно зафиксировать момент нажатия, можно припаять светодиод к контактам кнопки, который будет загораться в момент нажатия. Светодиод загорается за наносекунды, что позволяет точно фиксировать момент нажатия.
Brunnis c форума проекта libretro провел большое исследование проблемы задержки ввода. Его исследования считаю наиболее полными и объективными.
USB геймпад с припаянным светодиодом для фиксирования момента нажатия кнопки
Кнопка не нажата
Кнопка нажата
Начало анимации на экране спустя 24 кадра (100 миллисекунд)
Формула расчета
В секунде 1000 миллисекунд.
Камера телефона снимает в 240fps.
Значит 1 кадр видео = 1000 / 240 = 4,16мс.
Здесь также важно учитывать частоту кадров на которой работает монитор и компьютер. Например для режима работы 30fps, один кадр монитора будет равен 33мс, а для 60fps — 17мс. Это нужно учитывать, так как время между кадрами не может быть меньше этих значений, а значит события происходящие в промежуток обновления кадров на мониторе будут округляться до последнего кадра.
Я не буду приводить здесь все результаты измерений чувака, кому интересно предлагаю ознакомиться самостоятельно.
Главное что нужно запомнить: оригинальные консоли имели в среднем задержку от 50 до 70мс, в зависимости от консоли и режима PAL/NTSC. Хорошо настроенный эмулятор на PC добавляет 60-80мс задержки, в зависимости от эмулируемой платформы. Эмулятор на raspberry pi может в сумме иметь до 150мс задержки.
Читайте также: