Comments 29
С первой же фотки меня посетило неуловимое чувство deja vu. Да, PatientZero и эту статью переводил: https://habr.com/ru/post/419043/
Правда, там уже видео на ютубе поломались, а тут хоть одно есть. Спасибо за обновлённый вариант перевода.
Boomburum, неужели простая проверка по массиву ссылок на оригиналы при вставке ссылки источника сильно нагружало бы сервер? Не первый раз ведь уже постят "баян", зазря перепереводят. А так — сначала проверяли бы на использованность ссылки другой статьёй ранее.
Решается проблема не то чтобы просто, но ничего особенного — уменьшением общей нагрузки в целом и побольше борьбы с пиками.
Этому толком не помогут программноаппаратные средства — проблема перенесётся на монитор и там так же будет показываться дергающееся нечто. Даже наоборот, в некоторых случаях это станет более заметным. Единственный плюс здесь — уменьшится пинг между вводом и выводом.
Вопрос в определении того, ЧТО нужно рисовать.(игровую ситуацию на какой момент времени)
Попытался описать всё подробно, не получилось.
Поэтому дам только сторону в которую копать.
У нас много разных времён.
Время в игре(если в игре идёт таймер, то именно его мы увидем на скриншоте)
Реальное время в которое был выведен кадр. и именно эти 2 времени нам нужно синхронизировать.
Т.е. если разница в реальном времени между кадрами постоянна.
Но разница времени в игре не константа у нас всё равно будут подёргивания как буд-то кадры выпадают.
Выпадение кадра это как раз частный случай несовпадения времени в игре и настоящего времени.
А без предсказания времени кадра никак.
Вот у тебя есть кадр N, соответствующий игровому времени M.
Тебе нужно вывести на экран кадр N+1.
Вопрос: на какой игровой момент времени считать положение предметов?
Пытаться предсказать время кадра — глупое занятие
А теперь пишите что нужно вычислять время кадра. Так вот не существует идеального способа его вычислить. Поэтому все вычисления превращаются в предсказания. Которые иногда ошибаются.
Лаг так и так есть, и он куда больше 16 мс) Но оба эти метода создают лаг.
С кабелем проблема скорее в другом. На сколько помню, некоторые конфигурации подключения создают довольно большое время задержки.
16 мс заметить сложно) Во многих играх используется программная мышь, но при хорошем fps разница не ощущается. Вот в шутерах, во время ожидания(кемпер), это заметно и сколько-то влияет.
Общая задержка может и больше. Главное что разница в 16мс заметна и создаёт дискомфорт.
Проблема не в кабеле. 60гц в меньшем разрешении работает нормально.
Сам тип подключения может влиять на лаг.
DVI-DVI=hdmi-hdmi Проверял фотографируя 2 экрана. Из серии в 10 снимков на 60гц. Только 2 раза hdmi-hdmi отстал на 1 кадр. Тут уже думаю влияет не способ ввода, а мозги монитора(по DVi был подключен другой монитор).
hdmi-hdmi=DP-hdmi(по ошущениям)
Предикт не создаёт ошибок движения. В том смысле, что в любом случае, что с предиктом, что без вначале комп должен получить ввод, и только потом он будет рассчитывать что-же этот ввод сделал.
Я понимаю что рациональное зерно есть в обработке изображения без предиктов… но как мне кажется минусы перевешивают плюсы. И судя по статье разработчики игр согласны с моим мнением.
Предикт в любом случае создаёт ошибку движения. И последствия как раз этого могут быть хорошо заметны.
Т.н. «разработчики игр из статьи» придумали вертикальную синхронизацию… Которая существует уже много лет. Возможно просто какой-то некрофил(сэм 2003) поднял старую тему и наложил на существующие сегодня баги, либо ещё что-то.
Знатоки, всё уже придумано
Проблема в том, что кадры в секунду считаются не по определению. Вместо того, чтобы реально считать количество кадров за прошедшую секунду, за основу берется время на прорисовку последнего кадра и если оно достаточно короткое, то выдает FPS 123, потом тормознуло и внезапно 45, и это число дико скачет. Правильнее было бы считать фактическое число отрисованных кадров за единицу времени, или хотя бы усреднять интервал по нескольким предыдущим и
переключать режимы 30 — 60 с гистерезисом. Рывков бы стало меньше.
Я тоже раньше думал что 60 это о-го-го! Пока мне не дали пройтись при 60 и при 120. Честно, обратно на 60 не хочется, совсем.
15" — 3.3 мм
24" — 5.3 мм
54" — 11,9 мм
что как бы уже заметно глазами.
Вряд ли Вам показывали 120 к/с на 15" мониторе.
в VR шлеме 45к/с(1/2 от базовой 90) смотрится примерно как 30к/с на 27" с расстояния вытянутой руки по уровню дерготни.
PS: на деле мозг и глаза штука довольно хитрая, и считывание глазми в не малой части так же идёт кадрами, читайте про микросаккады.
Вряд ли Вам показывали 120 к/с на 15" мониторе.
Нет, конечно. Там было нечто гнутое, за 40".
Как раз столкнулся со статтерингом, моя игра просто летает на 1000 фпс, но при VSYNC появляется микролаг, который бывает заметен и неприятен. Экзотика типа вулкан апи не поможет на моей видяхе, которая его не поддерживает, так что придётся придумывать правила игнорирования микролага. Ещё советуют тройную буфферизацию, поможет ли
Ста-ста-статтеринг, или откуда в игре берутся микрофризы и как с ними бороться