Ста-ста-статтеринг, или откуда в игре берутся микрофризы и как с ними бороться
Представьте себе: вот вы ждете новую часть вашей любимой игры и, наконец, она выходит. Специально под это дело вы обновили свой ПК: установили новейшие ЦП и ГП, увеличили объем оперативки и даже заменили жесткий диск на SSD. Теперь игра должна запускаться у вас гладко, как шелк, с первого же экрана загрузки и до самого конца.
Вот вы скачиваете себе ранее оплаченный предзаказ. Завершается установка, вы запускаете игру. Все идет хорошо: игра «летает» с частотой кадров 60 FPS. Или, во всяком случае, так говорит вам счетчик кадров в оверлее вашего ГП. Но что-то идет не так. Вы водите мышкой туда-сюда и замечаете, что игра… фризится.
Как это возможно? Какие еще фризы при 60 FPS?
Это может казаться смешным до тех пор, пока не столкнешься с этим сам. Если вы встречались с такими фризами, то наверняка уже успели их возненавидеть.
Это не лаги. Не низкий фреймрейт. Это статтеринг. При высоких FPS и идеальной сверхбыстрой конфигурации.
Что это такое, откуда взялось и есть ли способ от него избавиться? Сейчас разберемся.
Со времен появления первых аркадных автоматов в 70-ых годах видеоигры работают на 60 FPS. Обычно предполагается, что игра должна работать с той же скоростью, что и дисплей. Только после популяризации 3D-игр нам пришлось столкнуться и принять более низкую частоту кадров. Еще в 90-х годах, когда «3D-карты» (которые теперь называют «графическими процессорами») начали заменять программный рендеринг, люди спокойно играли с частотой 20 кадров в секунду, а 35 FPS считалась уже частотой для серьезных соревнований по сети.
Теперь же мы располагаем сверхбыстрыми машинами, которые, конечно же, могут летать на 60 FPS. Тем не менее… похоже, что недовольных производительностью теперь стало больше, чем когда-либо. Как это возможно?
Дело не в том, что игры работают недостаточно быстро. А в том, что они фризятся даже с высокой производительностью.
Если вы пробежитесь по игровым форумам, то, вероятно, встретите в заголовках тем что-то вроде такого:
ПК-геймеры часто жалуются, что игры страдают от статтеринга даже при отсутствии проблем с частотой кадров.
Можно предположить, что это единичные случаи, но такие допущения развеивает статистика поиска в Google:
За последние 5 лет статтеринг стал (относительно) большей проблемой, чем производительность.
(Обратите внимание, что это относительные значения. Дело не в том, что люди ищут информацию о статтеринге чаще, чем о фреймрейте в целом. В то время, как количество поисковых запросов о частоте кадров остается прежним, поисковые запросы о статтеринге появляются все чаще, особенно в последнее время.)
Десятилетие поиска причин статтеринга
Пациент точно жив. Просто часто фризится.
Впервые автор столкнулся с этой проблемой где-то в 2003 году во время работы над Serious Sam 2. Люди стали сообщать о случаях, когда во время тестирования на пустом уровне движения экрана и мыши оказывались не плавными. Это сопровождалось очень специфическим паттерном на графике частоты кадров, который команда разработки назвала «сердцебиением».
Первой мыслью было то, что где-то в коде закралась ошибка, но никто не смог ее найти. Казалось, что проблема появлялась и исчезала случайным образом — при перезапуске игры, перезагрузке компьютера… но стоило изменить какой-либо параметр производительности, и она исчезала. Затем можно было поменять параметр обратно, и все продолжало работать идеально. Проблема-призрак.
Очевидно, проблема была не только в «Сэме». При запуске других игр она возникала точно так же, наводя на мысли, что тут что-то с драйверами. Но появление статтеринга не зависело от производителя вашего графического процессора. Оно имело место даже при разных API (OpenGL, DirectX 9, DirectX 11…). Единственное, что оставалось общим, так это что статтеринг появлялся то тут, то там на некоторых машинах и игровых сценах.
С выпуском новых игр эта проблема продолжала то появляться, то исчезать. Раньше это затрагивало лишь некоторых пользователей, и все ограничивалось просьбами со стороны техподдержки изменить кое-какие параметры производительности — что иногда помогало, а иногда нет, никогда не угадаешь.
Затем внезапно, в один прекрасный зимний день в начале 2013 года, ребята из Croteam обнаружили еще один пример этой проблемы, который на тот момент можно было относительно последовательно воспроизводить — на этот раз на одном из уровней в «Серьезном Сэме 3». Они долго возились с той сценой, пока вдруг не осенило. Все было настолько просто — неудивительно, что целое десятилетие это ускользало от всеобщего внимания.
Изменив всего одну простую опцию в игровом движке, у них получилось решить эту проблему. Однако сразу стало ясно, что на самом деле решение потребует гораздо больше времени и усилий. И не только от конкретной команды, но и от всей игровой экосистемы: разработчиков драйверов ГП, специалистов по сопровождению API, поставщиков ОС — всех.
Что происходило все это время
Вот как это выглядит, когда игра «тормозит» даже при 60 FPS. Вы могли испытать нечто подобное, играя в любую современную игру, и, вероятно, первым делом подумали бы, что игра не оптимизирована. Что ж, давайте пересмотрим эту теорию.
Если игра «слишком медленная», это означает, что в некоторых моментах она не сможет отрендерить один кадр достаточно быстро, и монитору придется снова показать предыдущий кадр. Поэтому, когда мы снимаем видео со скоростью 60 кадров в секунду, оно должно показывать «пропущенные кадры» — когда следующий кадр не был отображен вовремя, отчего один и тот же был показан дважды.
Однако это происходит только тогда, когда вы воспроизводите всю анимацию целиком. Если бы вы перебирали ее покадрово, то никаких разрывов бы не обнаружили.
Как такое возможно?
Давайте рассмотрим это подробнее. Ниже представлено параллельное сравнение идеального плавного видео и видео со статтерингом:
Шесть последовательных кадров с точной синхронизацией. Наверху — правильно расположенные кадры, внизу — кадры со статтерингом.
Здесь можно увидеть две вещи: во-первых, они действительно работают с одинаковой скоростью: всякий раз, когда появляется новый кадр сверху (правильный), тогда же появляется новый кадр и снизу (статтеринг). Во-вторых, по какой-то причине кажется, что они двигаются немного иначе — в середине изображения есть заметный «разрыв», который колеблется между большим и меньшим разделением по времени.
Самые внимательные могут заметить еще одну любопытную деталь: нижнее изображение — якобы более «медленное»… на самом деле идет «впереди» правильного. Странно, не правда ли?
Если мы посмотрим на несколько последовательных кадров и их время, мы можем наблюдать еще кое-что интересное: первые два кадра идеально синхронизированы, но на третьем кадре дерево на «более медленном» видео значительно опережает свой аналог на «правильном» видео (обведено красным). Также можно заметить, что этот кадр явно занял больше времени (обведено желтым).
Подождите, подождите… но если видео «медленнее», а кадр «занял больше времени», то как оно может идти с опережением?
Для понимания дальнейших объяснений сначала необходимо разобраться, как современные игры и другие 3D-приложения вообще выполняют анимацию и рендеринг.
Краткая история синхронизации кадров
Давным-давно, в далекой-далекой галактике… когда разработчики создавали первые видеоигры, обычно они это делали с учетом точной частоты кадров, на которой работал дисплей. В регионах NTSC, где телевизоры работают с частотой 60 Гц, это подразумевает 60 кадров в секунду, а в регионах PAL/SECAM, где телевизоры работают с частотой 50 Гц, — 50 кадров в секунду.
Большинство игр представляли собой очень простые концепции, работающие на фиксированном оборудовании — обычно на аркадной консоли или хорошо известном «домашнем микрокомпьютере», таком как ZX Spectrum, C64, Atari ST, Amstrad CPC 464, Amiga и т. д. Таким образом, создавая и тестируя игры для конкретной машины и определенной частоты кадров, разработчик всегда мог быть на 100% уверен, что фреймрейт никогда никуда не упадет.
Скорости объектов также сохранялись в «кадровых» единицах. Таким образом, вам необходимо было знать не на сколько пикселей в секунду будет перемещаться персонаж, а на сколько пикселей в кадре. Например, в Sonic The Hedgehog для Sega Genesis такая скорость составляет 16 пикселей на кадр. Многие игры даже имели отдельные версии для регионов PAL и NTSC, где анимация рисовалась от руки специально для 50 и 60 FPS, соответственно. По сути, работа с любой другой частотой кадров была просто невозможна.
И поскольку со временем игры стали запускаться на более разномастных устройствах, включая ПК с постоянно расширяемым и обновляемым оборудованием, нельзя было точно знать, на какой частоте кадров будет работать игра. Этот факт усугублялся тем, что сами игры стали более сложными и непредсказуемыми — особенно это заметно в 3D-играх, где могут быть большие различия в сложности сцены, иногда даже определяемые самими игроками. Например, всем же нравится стрелять по штабелям бочек с горючим, тем самым вызывая красочную череду взрывов… и неизбежное падение частоты кадра. Но поскольку это весело, то никто и не против.
Поэтому сложно предсказать, сколько времени потребуется для моделирования и рендеринга одного кадра. (Обратите внимание, что на современных консолях у нас, можно считать, фиксированное оборудование, но сами игры при этом все равно довольно непредсказуемы и сложны.)
Если вы не можете быть уверены, с какой частотой кадров будет работать игра, вам необходимо измерить текущую частоту кадров и постоянно адаптировать физику игры и скорость анимации под нее. Если один кадр занимает 1/60 секунды (16,67 мс), а ваш персонаж бежит со скоростью 10 м/с, то он перемещается на 1/6 метра в каждом кадре. Но если кадр вдруг начнет занимать 1/30 секунды (33,33 мс), то вы должны перемещать персонажа уже на 1/3 метра за кадр (в два раза «быстрее»), чтобы он продолжал двигаться с той же видимой скоростью.
Как это устроить? Как правило, игра замеряет время в начале соседних кадров и вычисляет разницу. Это довольно простой метод, но он работает очень хорошо.
Вернее, раньше работал очень хорошо. Еще в 90-х, когда 35 FPS считалась ого-го какой скоростью, люди были им более чем довольны. Но в то время видеокарты не были столь значительной частью ПК, и контроль надо всем происходящим на экране имел центральный процессор. Если у вас не было 3D-ускорителя, он даже сам рисовал объекты. Таким образом, он точно знал, когда они попадут на экран.
Ситуация на сегодняшний день
Со временем стали появляться все более сложные графические процессоры, и они неизбежно становились все более и более «асинхронными». Это означает, что когда ЦП дает команду ГП отрисовать что-то на экране, ГП просто сохраняет эту команду в буфере, чтобы ЦП мог продолжать свои дела, пока ГП выполняет рендеринг. В конечном итоге это приводит к ситуации, когда ЦП сообщает графическому процессору, когда наступает конец кадра, а графический процессор, сохраняя это среди своих данных, на самом деле не считает это чем-то приоритетным — ведь он все еще обрабатывает некоторые из ранее выданных команд. Он покажет кадр на экране только тогда, когда выполнит все, чем его загрузили до этого.
Итак, когда игра пытается вычислить время, вычитая временные метки в начале двух последовательных кадров, релевантность этого, откровенно говоря… весьма сомнительна. Поэтому вернемся к нашему примеру. Там у нас были такие кадры:
Шесть последовательных кадров с точной синхронизацией. Верхний ряд — правильный, нижний — с эффектом статтеринга.
В первых двух кадрах время кадра составляет 16,67 мс (или 1/60 секунды), и камера перемещается на одинаковую величину в верхнем и нижнем случаях, поэтому деревья синхронизированы. В третьем кадре (внизу, со статтерингом) игра увидела, что время кадра составляет 24,8 мс (то есть, больше 1/60 секунды) и оттого думает, что частота кадров упала, и бросается нагонять пропущенное… только для того, чтобы обнаружить, что на следующем кадре время составляет всего 10,7 мс, отчего камера замедляется, и теперь деревья снова более или менее синхронизированы.
Что же происходит? Измеряемое игрой время кадра колеблется из-за различных факторов — особенно в загруженной многозадачной системе, такой как ПК. Поэтому в некоторые моменты времени игра полагает, что частота упала с 60 FPS, и генерирует кадры анимации, рассчитанные на более низкую частоту кадров. Но из-за асинхронного характера работы ГП она всегда так или иначе возвращается к тем же 60 кадрам в секунду.
Это и есть статтеринг — анимация, сгенерированная для переменной частоты кадров (сердцебиения), отображающаяся с фактической правильной фиксированной частотой кадров.
Так что по существу можно считать, что никакой проблемы нет — все идет гладко, просто игра этого не знает.
Это подводит нас к тому, о чем мы говорили в начале статьи. Когда мы, наконец, выяснили причину проблемы (хотя мы знаем, что это иллюзия проблемы — ведь на самом деле проблемы нет, не так ли?), мы можем применить следующую волшебную пилюлю.
Что это за пилюля? В Serious Engine она обозначается как sim_fSyncRate = 60. Проще говоря, это означает вот что: «полностью игнорировать все эти махинации с синхронизацией и делать вид, что мы всегда измеряем стабильные 60 кадров в секунду». И это заставляет все работать гладко — только потому, что с самого начала все работало гладко! Единственная причина, по которой появлялся статтеринг, — это неправильное время, используемое для анимации.
И что же, на этом все?
Значит, решение настолько просто?
К сожалению, нет. Это было просто только на тестах. Если бы мы прекратили измерять частоту кадров в реальных условиях и просто предположили, что она всегда равна 60 FPS, тогда, когда она упадет ниже 60 — а на ПК она рано или поздно упадет по какой бы то ни было причине: работа программ в фоновом режиме, сохранение энергии или защита от перегрева, кто знает, — тогда все замедлится.
Итак, если мы измеряем время кадра, происходит статтеринг, а если нет, в какой-то момент все может замедлиться. И что тогда?
Реальным решением было бы измерение не времени начала/окончания рендеринга кадра, а времени, когда изображение показывается на экране.
Но как игра может узнать, когда кадр действительно отображается на экране?
Да никак: в настоящий момент этого сделать невозможно.
Странно, но факт. Можно было бы ожидать, что это будет базовой функцией каждого графического API. Но нет: они претерпели изменения во всех других аспектах, кроме этого. Нет способа узнать наверняка, когда кадр действительно отобразится на экране. Можно выяснить, когда закончился рендеринг. Но это не то же, что время отображения на экране.
Что теперь?
Ну, все не так уж и плохо. Много кто активно работает над реализацией поддержки правильной синхронизации кадров для разных API. Vulkan API уже имеет расширение под названием VK_GOOGLE_display_timing, которое зарекомендовало себя в реализации этой концепции, но оно доступно только для ограниченного числа устройств.
Ведется работа по предоставлению похожих и более лучших решений, хотелось бы верить, что уже во всех основных графических API. Когда? Сложно сказать, ведь проблема глубоко врезается в различные подсистемы ОС.
Тем не менее, мы надеемся, что вскоре это станет доступным для более широкой общественности.
Различные предостережения и другие детали
Будем считать, что это конец основного текста. Разделы ниже представляют собой «бонусные функции», в основном независимые друг от друга и от описанного выше.
«Композитор»
Это что, эффект матового стекла? Ага, так вот почему у нас обязательно должен быть композитор. Довольно важно, не правда ли?
Во всем этом за кулисами задействована концепция под названием Compositing Window Manager, также известная как композитор. Это система, которая теперь присутствует в каждой ОС и позволяет окнам быть прозрачными, иметь размытый фон, тени и т. д. Композиторы могут пойти и дальше — и показывать окна ваших программ в 3D. Для этого композитор берет на себя управление самой последней частью кадра и решает, что с ним делать, непосредственно перед тем, как он попадает на монитор.
В некоторых ОС композитор можно отключить в полноэкранном режиме. Но это не всегда возможно, и даже в таких случаях — разве не можем мы запустить игру в оконном режиме?
Управление питанием и температурой VS сложность рендеринга
Мы также должны принять во внимание тот факт, что современные ЦП и ГП не работают с фиксированной частотой, но у обоих есть системы, которые регулируют их скорость вверх и вниз в зависимости от нагрузки и текущей температуры. Таким образом, игра не может просто предположить, что они будут иметь одинаковую скорость от кадра к кадру. С другой стороны, операционная система и драйверы не могут ожидать, что игра будет выполнять одинаковый объем работы в каждом кадре. Сложные системы связи между двумя сторонами должны быть спроектированы таким образом, чтобы все это принималось во внимание.
Фризы в играх на мощном ПК (Подробно) | RTX 4080
Всем привет. Пишу от безысходности, так как уже не знаю что делать. Постараюсь описать все подробно со всеми нюансами, дабы вы смогли лучше понять суть происходящего. Всё буду описывать объективно и беспристрастно, дабы имелась чёткая картина того, что есть на самом деле.
Конфигурация:
Материнская плата | Gigabyte z390 Aorus Elite
Процессор | Intel core i9-9900k (без разгона)
Охлаждение процессора | be quiet! Dark Rock Pro 4
Видеокарта | Asus Rog Strix Gaming OC RTX 4080
Оперативная память | Corsair Vengeance LPX 16GB Black [2x8GB 3000MHz DDR4 CL15 DIMM] (память от Samsung, двухканал)
Блок питания | be quiet! Power Zone 750W
Монитор | Acer Nitro VG270UPbmiipx 27 (wqhd, 144hz, ips, g-sync, hdr)
OS | Microsoft Windows 11 version 2h22
Диски — HDD 2TB WD RED (Под файлы)
— SSD Samsung 980 M.2 PCIe NVMe 1TB (Под игры и некоторые программы)
— SSD Samsung 980 M.2 PCIe NVMe 500GB (Под систему)
Всё это в большом и хорошо продуваемом корпусе.
Все ненужные функции системы, по типу защиты от эксплойта, оверлей, игровой режим и тд — отключены. Не знаю имеет ли это хоть какое-то значение, но на ПК стоит Norton Security.
Пару слов о видеокарте, попалась со свистящими дросселями (coil whine), при подключении питания, в выключенном состоянии горит красная лампочка, но после запуска компьютера гаснет. По тестам всё хорошо, но об этом ниже.
История:
Началось всё с того, что моя старая видеокарта — Gigabyte 2080 super windforce oc перестала работать. Мой взгляд пал на ещё не вышедшую 4080. В день выхода я приобрёл одну и установил в ПК. После этого я сразу скачал драйвер и решил провести тесты. Проходили они на ура, без каких-либо проблем. Однако через буквально два дня начались какие-то непонятки с монитором. Под нагрузкой в лице игр экран начинал мерцать, если альттабнуться на любое другое окно. Не знаю с чем это связано, возможно с локом фпс в игре при сворачивании (30 кадров), может с чем-то ещё, но факт в том, что проблему удалось устранить выключив в Nvidia Control Panel функцию G-SYNC. Стоит отменить то пару раз было и так, что после выключения игры экран продолжал мерцать (списываю на не полностью завершённый процесс). Но не суть. Примерно в это же время начал замечать микрофризы / статтеры / фризы в играх. Появляются они случайно, не только во время сохранения или перехода в другую локацию.
Хотелось бы добавить, что также имеются своего рода провисания (не часто), как картинки, ТАК И ЗВУКА, при обычном использовании ПК, т.е браузер, папки, и тд.
P.S. При одном из первых запусков во время использовании системы наблюдалось сильное зависание (1 или 2 раза), но больше такого не случалось. (Точно не знаю произошло это до установки драйвера на видеокарту или после)
Опишу на конкретных примерах:
Все игры стоят на SSD.
Мне главное понимать всё ли с видеокартой в порядке?
[Продолжение в комментариях]
Недавно человек жаловался на статтеры в варзоне, а после перешёл с Win112h22 на Win10 и всё стало ок. Он тут писал про это:
1) A Plague Tale: Requiem
Настройки графики максимально возможные, отключена хром. аберрация(не помню точное название) и выключен motion blur. Разрешение QHD, ограничение кадров 60, DLSS разрешение отключено, DLSS генерация кадров включена, что по итогу дало максимальную детализацию и 120 фпс благодаря генерации кадров. Вот на этой конфигурации я играл большую часть времени, и временами без как-либо подгрузок(значок сохранения не появлялся), происходил микрофриз, довольно заметный, с просадкой фпс до 100 а иногда(реже) и до 80, но после этого счётчик сразу же возвращался в норму. И вот так постоянно, независимо от локаций. Также мне показалось, что даже находять на одной и той же локации, практически не передвигаясь, всё равно попадались микрофризы(но такое было очень редко). Для проверки запускал с минимальными настройками графики, не снижая разрешение (со всеми возможными комбинациями настроек DLSS 3). Фризы как были, так и остались.
Немного мониторинга в игре:
Процессор — 60-80 градусов, загрузка в среднем 80+%. Во время теста всей системы (кроме FPU, так как при нём сразу в тротлинг уходит) спустя несколько минут начинался 3-4% троттлинг, но во время тестов в играх вроде ничего подобного не было (может я не правильно читаю мониторинг).
Видеокарта — 45-55 градусов в среднем, загрузка 65-70%.
Пытался немного разогнать процессор — не помогло, ОЗУ поднял с 3000 до 3600 — аналогично, но по моим наблюдениям после манипуляций с оперативкой фризов стало значительно меньше (возможно просто повезло, так как нет определенной системы). Перезагрузка ПК по моим наблюдениям на вероятность возникновения никак не влияет.
2) CoD Warzone 2
Настройки графики максимальные, отключен motion blur, DLSS в режиме качество, ограничитель 140 кадров. В игре выдаёт от 120 до 140 в зависимости от локации и действий на экране. Но тут, так же, как и в предыдущей игре случались микрофризы с просадками до 80 кадров, причём в этой они были чаще(но только в самых первых играх после установки).
Немного мониторинга в игре:
После манипуляций с оперативной памятью, ситуация аналогична прошлой игре — кол-во фризов уменьшилось, но вот после перезагрузки вроде как вероятность микрофризов снизилась, в отличии от plague tale. (Однако я не берусь это утверждать, так как раз на раз не приходится)
3) Cyberpunk 2077
Настройки в максимум, лучши наивысшие, DLSS на качество. Раз в несколько бенчмарков проскакивают микрофризы (по моим наблюдениям максимум 1 на тест, но могу ошибаться). В самой же игре провисаний / фризов не замечал, но возможно это потому, что частота держалась в районе 60-70 кадров, не больше. К сожалению запечатлить на видео не удалось.
4) God of War
Максимальные настройки графики, без DLSS. Заметил довольно много фризов и провалов FPS.
5) Forza Horizon 5
Максимульные настройки графики, без DLSS. Значительных просадок нет, микрофризы имеются, но не так много.
Теперь по тестам (все скриншоты приложу ниже). С целью выявить слабое место, начал проводить тест всех комплектующих. Результаты хоть и положительные, но меня не обрадовали, так как яснее ситуация не стала. Дали наводку на сырые драйвера как от NVIDIA, так и от Microsoft, но к сожалению это никак не проверить, а уж тем более не исправить (или я чего-то не знаю).
Видеокарта в Furmark стабильная, выше 65 градусов не греется, выдаёт
340 фпс в режиме теста QHD. 3DMark в стресс тесте показал 99.1% стабильности видеокарты, все кривые "ровные", стабильные (только температура скакала на пару градусов). Тут же протестировал CPU, проблем так же нет. Диски тоже в порядке. Проверка PCIe слота показала положительный результат. Оперативную память прогнал через AIDA, и memtest86. Никаких проблем не выявлено. Тест общей конфигурации показал положительный результат. НО. фризы как были так и остались, и честно признаться не этого я ожидал, покупая карту за почти 1800$, и больше всего переживаю именно за неё, всё ли с ней хорошо, или быть может пока не поздно пойти и сдать / заменить её. Вроде бы ничего не забыл, если что вспомню — добавлю ниже.
Фризы в играх на нормальной системе
оперативная память MD Radeon R9 Gamer Series на 16 гиг две плашки и XMP профиль стоит 3200 гц тайминги 16 18 18 39
фризы в ведьмак 3, хогварт легаси, в метро исход иногда проскакивают.
файл подкачки стоит на 8гиг 8138
файл подкачки на 8 гигов 8139
- пожаловаться
- скопировать ссылку
Я не могу понять это — "на 16 гигов две плашки". Т.е. у тебя 2х16 или 2х8Гб стоит? Кроме того, отвратительная оперативная память.
1. Файл подкачки при 16 гигах, минимум 18-20. Вообще, лучше не трогай и оставь по требованию системы на SSD, лучше m2.
2. Ведьмак 3 и Хогвардс вообще не пример в качестве теста на фризы. Как и у многих других, ты не выделился по этим играм. Обрати внимание, что Хогвардс вообще на движке Unreal Engine 4, а на нём страдают чуть ли не все игры от статеров. Почитай про оптимизацию, хоть на реддите. Увидешь то же самое. Ведьмак — вертикалка ему помогает, и конечно игры уже все на SSD ставим. Посмотри видос, попробуй у себя. Мне вертикалка помогла. Кроме того, знатоки этой игры говорят о настройках и большом количестве нпс — погугли.
Из всего списка, выделяется только Метро. На чём стоит метро? Лучше его запиши и покажи. Остальное не интересно. У всех так.
3. В большинстве случаев, процессор перегружен. 6 ядер очевидно маловато. Нагрузка составляет больше 70-80%. пора менять уже.
На чём игры стоят? Пока больше похоже на подгрузку с медленного жестака. И файл подкачки исправь.
Как работу игр сделать отзывчивее, плавнее, убрать микро-фризы, задержки и лаги — несколько советов, на что нужно обратить внимание
Доброго дня!
Ну что, всех с новым учебным годом?! 😉 И сегодня решил снова коснуться темы игр — точнее их плавности и отзывчивости (тем паче, что вопрос это дискуссионный, и меня частенько им беспокоят).
Например, как часто бывает: игра вроде бы идет с 60+ FPS (что вполне нормально), но периодически случаются подвисания, лаги — картинка на экране дёргается — и от того играть крайне некомфортно!
Причем, далеко не всегда это происходит из-за устаревшего компьютера — можно и на новом относительно-мощном устройстве столкнуться с чем-то подобным.. 😥 Особенно это неприятно в сетевых онлайн-играх, где вы соревнуетесь (в той или иной степени) с др. людьми.
Собственно, несколько советов на что нужно обратить внимание, я приведу в сей заметке. Рекомендую всем любителям игрушек. 👌
Важно!
Если у вас тормозит игра из-за низкого FPS (обычно ниже 30-35) — то рекомендую ознакомиться с этой заметкой.
В этой же статье будет разбираться вопрос микро-фризов, когда дело не в кол-ве FPS (т.е. этот параметр находится на комфортной 45-60+ кадров/сек. (для данной игры) величине).
Улучшаем «отзывчивость» и плавность изображения, персонажа в игре
Инпут-лаги контроллеров
Далеко не все любители игр о них слышали.
Суть здесь в том, что от типа используемой мышки (клавиатуры, джойстика и т.д.) — зависит скорость отклика вашего персонажа в игре (ведь сначала ваше нажатие должна обработать мышка (например) —> затем подать сигнал на компьютер —> и лишь после он появится на экране. Время от начала и до конца сего действия — называют инпут-лагом ).
Если говорит в среднем, то отклик у проводной мышки <1 мс (миллисекунда), у беспроводной 5-15 мс! Т.е. при использовании проводных устройств вы можете выиграть около 10 мс!
Кажется, что это величина смешная, однако, в некоторых динамичных играх (например, CS) — разница в том же пинге 30-60 мс — уже сильно может ощущаться! (а добавьте к этому: мышку, клавиатуру, некорректные настройки видеокарты, монитор и т.д. — в сумме разница в миллисек. может набежать дай боже. )
Ключевой параметр для всех онлайн-игр, от которого напрямую зависит скорость вашего управления (пинг — это время, за которое ваш ПК отправит «кусок» данных на другой ПК, и получит от него ответ). Т.е., если говорить грубо, сначала есть «задержка в виде инпут-лага (мышка/клавиатура и пр.) — затем к этому добавляется еще и пинг.
Как его уменьшить:
- использовать 👉 высокоскоростное подключение к сети Интернет (только проводное!). Это может уменьшить пинг в разы (на десятки и сотни миллисек.!);
- желательно отказаться от использования роутера (и пр. устройств «посредников» между Интернет-кабелем провайдера и вашим ПК). Если всё же играете через Wi-Fi подключение — 👉 рекомендую прочитать эту инструкцию;
- во время игры отключите торренты, закройте браузеры (загрузки) и другое ПО, которое может нагружать сеть;
- ознакомьтесь 👉 с моей прошлой инструкцией по уменьшению пинга (там есть доп. рекомендации!).
Пинг до ya.ru // проверка отправки пакетов (инструкция тут)
О настройках видеокарты
В относительно-новых видеокартах от AMD и Nvidia появилась спец. настройка, позволяющая уменьшить время передачи кадров от момента их обработки до вывода на экран (что в свою очередь значительно сокращает скорость реагирования на нажатие кнопок!). По умолчанию — эта опция выключена!
Как она называется:
- у AMD — Radeon Anti-Lag;
- у Nvidia — режим низкой задержки.
Что это дает : обратите внимание на фото ниже 👇 — время реагирования персонажа, после нажатия кнопок, меньше на 10-20 мс! Что в общем-то неплохо, учитывая, что потребуется лишь передвинуть флажок в настройках видеокарты.
Radeon Anti-lag — что дает настройка в играх!
На двух скринах ниже (для AMD и Nvidia) я показал где искать данную опцию. Если не знаете как открыть настройки драйвера видеокарты — 👉 ознакомьтесь с этим.
Radeon Anti-lag — настройки профиля игры
Режим низкой задержки — панель управления Nvidia
Пару слов о мониторе
На мой взгляд, сегодня монитор под игры следовало бы брать с временем отклика в 1-2 мс + с частотой обновления в 120 Гц + с поддержкой технологии G-Sync. Всё это вкупе позволит выиграть от ≈5 до 50 миллисекунд (что положительно скажется на результатах в онлайн-сражениях!).
Да и само изображение в динамичных сценах будет идти более плавно, без «разрывов» и искажений.
👉 В помощь!
Как выбрать монитор для компьютера в 2020-2021: несколько важных заметок
Под какую задачу покупается монитор — базовые моменты!
По поводу дисков
👉 Совет первый : установите и саму систему, и игру на SSD-накопитель. Это позволит значительно повысить скорость чтения данных с диска. См. на скрин ниже 👇 (самую нижнюю строку «4k» — если сравнить HDD и SSD — то разница в 10 раз!).
Примечание : «4k» — скорость чтения/записи случайных блоков в 4 КБ. Более 70% операций при работе в Windows приходится на небольшие файлы, а значит производительность многих приложений (игр) очень сильно зависит от этой скорости.
Тест скорости накопителей SSD (NVMe, SATA), HDD
👉 Совет второй : проверьте состояние своего диска (на котором установлена система и игра), в особенности как он ведет себя под нагрузкой: не падает ли с него скорость чтения в ноль?! Сделать это можно с 👉 помощью спец. теста в «Виктории» (дело на 5 мин!).
Быстрый анализ графика (из Victoria 5) // пример
👉 Совет третий : если у вас установлено 2-3 и более накопителей — рекомендую 👉 зайти в настройки электропитания Windows и запретить отключать диски. 👇 Это позволит избежать «дерчков» при загрузки данных с накопителей, когда игра редко к ним обращается.
Настройки электропитания — не откл. жесткий диск
Проверка температур и нагрузки на основные компоненты
Если всё вышеприведенное не помогло сделать работу игры более качественной и она всё равно «притормаживает» — попробуйте вывести на экран температуры и нагрузку на основные компоненты (видеокарту, ЦП, ОЗУ и пр.), и понаблюдайте за показаниями. Не уходят ли они в «облака». Ссылка ниже в помощь. 👇
Скриншот с показаниями из игры WOW // пример работы FPS Monitor
После этого (когда будет более-менее ясна «картина») я бы порекомендовал вам ознакомиться с моим сборником заметок по оптимизации и разгону ПК/ноутбука. В некоторых случаях при помощи небольшой до-настройки — можно прибавить +50% к FPS (согласитесь, ведь неплохо? 😉). Ссылочка ниже.
👉 В помощь!
1) Как разогнать и увел. производительность ноутбука / компьютера — [см. сборник заметок 👍]
2) Как снизить температуру ЦП / ноутбука