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