лаги в играх что это
Что делать, если лагают сетевые игры. Как снизить инпут лаг и задержки сети
Чтобы успешно играть и побеждать в сетевых играх, важно добиться максимальной отзывчивости управления и плавности картинки. Ощущения от игры полностью зависят от нескольких независящих друг от друга факторов. Сюда можно отнести производительность оборудования, задержки системы и ввода на стороне пользователя (т.е. время от нажатия на клавишу мыши до отображения выстрела на экране) и качество сетевого соединения. Чтобы добиться идеального отклика, нужно оптимизировать каждый из этих пунктов.
Как снизить системные задержки (инпут лаг)
Системные задержки — это время, которое проходит от нажатия клавиши до отображения результата на экране. Если максимально упростить, то это инпут лаг. Однако только задержками ввода дело не ограничивается. Системные задержки зависят еще и от особенностей работы компонентов ПК и быстроты монитора.
Используйте проводные клавиатуру и мышь. По проводу подключение всегда будет быстрее и стабильнее. Впрочем, беспроводные геймерские модели тоже есть, но они стоят дороже проводных аналогов.
Выключите обработку картинки (шумоподавление, уплавнялка и т.п.) или переключите режим изображения на игровой. Если вы играете на телевизоре, то это особенно актуально. Но на мониторе тоже может быть переключатель режимов. Например, у MSI есть специальный игровой режим, который называется Zero Latency. Чтобы понять, если такой режим на вашей модели монитора, обратитесь к инструкции или на официальный сайт производителя.
Выставьте максимально возможную частоту обновления дисплея. Некоторые дисплеи могут не поддерживает частоту более 60 Гц при максимальном разрешении, в таком случае стоит опуститься до 1080p. Например, именно так работают консоли PlayStation 5 и Xbox Series X с телевизорами, у которых есть только вход HDMI 2.0. В совместимых играх таким образом можно выставить режим 120 Гц. Кроме того, некоторые мониторы могут работать при повышенной частоте, даже если она официально не поддерживается. К примеру, монитор BenQ GW 2470 может работать при 75 Гц, если выставить кастомный режим изображения в драйверах видеокарты.
Отключите вертикальную синхронизацию в настройках игры. Из-за этого картинка может быть менее приятной, так как будут возникать разрывы кадра — так называемый тиринг. Однако отзывчивость может увеличиться. Обратите внимание, что при наличии у вашего монитора и видеокарты функций VRR, G-Sync или FreeSync разрывов быть не должно.
Включите технологию NVIDIA Reflex. Чтобы снизить задержку на стороне пользователя, стоит включить технологию NVIDIA Reflex, которая поддерживается многими сетевыми играми. Она работает на всех видеокартах GeForce начиная с 900 серии. Кроме того, для нее не нужно специальное оборудование вроде монитора и мышки. Наибольший эффект технология дает на высоких настройках графики. Подробнее о работе технологии мы писали в отдельной статье «Как перестать сливать катки и начать тащить».
Включите режим низкой задержки. Также в панели управления NVIDIA можно включить режим низкой задержки. По своему эффекту он похож на NVIDIA Reflex, но работает только в DirectX 11. Про все настройки панели управления мы писали в гайде «Как настроить видеокарту NVIDIA для игр». У видеокарт AMD есть схожая функция — Radeon Anti-Lag, которую тоже можно включить в настройках дрйвера.
Как снизить сетевые задержки
Другой вид задержек — сетевые. Качество соединения в основном зависит от вашего провайдера. В первую очередь здесь важен такой показатель, как пинг.
Важно! Высокий пинг и нестабильное соединение — разные вещи. Если часть пакетов теряется, то это ощутимо влияет на геймплей. К примеру, вас отбрасывает назад или игровой мир замирает на некоторое время. При плохом пинге, как правило, таких проблем нет, но есть ощутимая задержка в действиях. Грубо говоря, вас будут убивать раньше, чем вы сможете среагировать.
Как проверить пинг
Проверить пинг можно с помощью специализированных сайтов или мобильных приложений. Один из наиболее популярных — speedtest.net. Однако этот инструмент лучше подходит для измерения скорости. Именно пинг лучше проверить штатными средствами операционной системы Windows.
Как настроить сетевой адаптер для снижения пинга
Если у вас проблемы с пингом, то стоит настроить сетевой адаптер. Перейдите в диспетчер устройств и найдите свой сетевой адаптер. Как правило, это Realtek, Intel, Qualcomm, Killer или другой. Также в списке может быть беспроводной Wi-Fi адаптер.
Зайдите в свойства адаптера и перейдите на вкладку «Управление электропитанием». Снимите галочку с «Разрешить отключение устройства для экономии энергии». Далее перейдите в дополнительно и отключите следующие пункты:
Буферы передачи и приема нужно поставить на максимальное значение — 128 и 512 соответственно. Максимальное число очередей RSS должно быть выставлено на доступный максимум. Выгрузка протокола ARP и NS должны быть включены.
Можно настроить и Wi-Fi адаптер, если вы им пользуетесь для игр. Сначала нужно также выключить «Разрешить отключение устройства для экономии энергии» и далее перейти на вкладку «Дополнительно». Здесь нужно также отключить настройки, связанные с энергосбережением. Для «Режима энергосбережения MIMO» выберите «Нет SMPS». Отключите также:
Программы для снижения пинга
В сети можно найти множество программ для снижения пинга. Суть их работы можно свести к выбору оптимального маршрута соединения, благодаря чему и снижается задержка. Одна из популярных программ — ExitLag. Она платная, но есть бесплатный трехдневный период для теста. Чудес от нее ждать не стоит и если у вас уже неплохой пинг, то программа вряд ли существенно его уменьшит. Однако попробовать все же стоит. В настройках программы вам нужно выбрать игру и регион сервера, для которого требуется оптимизация.
Общие советы
Если дело не в провайдере, то кое-что все же можно сделать для уменьшения задержек. Как правило, проблемы с соединением связаны с роутером.
Перейдите на диапазон 5 ГГц. Многие современные роутеры работают в двух диапазонах: 2,4 ГГц и 5 ГГц. Последний — более продвинутый. Он устойчив к помехам и лучше работает в многоквартирных домах, где в каждой квартире по роутеру. Если ваше оборудование поддерживает 5 ГГц, попробуйте переключиться на эту частоту. Обратите внимание, что приемник сигнала тоже должен поддерживать этот стандарт.
Смените канал Wi-Fi. При помощи бесплатной утилиты WifiInfoView можно проверить, насколько загружены разные каналы Wi-Fi в вашем доме. В настройках роутера стоит выбрать наименее загруженный канал.
Обновите прошивку роутера. Стоит также обновить прошивку роутера. Если вы купили новое устройство, то это стоит сделать первым делом. Зайдите на официальный сайт производителя и найдите свежую прошивку для своей модели роутера. Обратите внимание, что нужно точно выяснять модель устройства, включая ревизии. Возможно, наилучшим вариантом будет установить стороннюю прошивку. Если у вашей модели роутера мощное комьюнити, стоит поискать информацию на профильных форумах.
Измените DNS-сервер. Также можно попробовать поменять стандартный DNS-сервер от провайдера на альтернативный от Google. Предпочитаемый сервер — 8.8.8.8, альтернативный — 8.8.4.4.
Перезагрузите роутер. Если возникают какие-либо неполадки с роутером, стоит его перезагрузить. Возможно, после этого проблема уйдет сама собой.
Подключитесь к роутеру по проводу. Если размещение роутера и вашего ПК позволяет подключиться по проводу, то именно так и стоит сделать. Проводное соединение — самое стабильное.
Почему игры лагают? Или как убрать лаги в играх?
Не секрет, что все мы любим играть в компьютерные игры. Кому то нравятся онлайн шутеры, кому то квесты, кому то гонки. Игры помогают снять напряжение после тяжелого дня, поднять настроение, весело провести время, забыть о плохих моментах дня. В общем все мы любим провести вечерком часок другой за любимой компьютерной игрой. Но иногда бывает так, что игры начинают лагать, тормозить, глючить, очень медленно работать. И приятное время препровождения превращается в мучение. Как же бороться с такой проблемой? Как ускорить работу игр? Как убрать лаги в играх?
Вот перечень советов, помогающих решить подобные проблемы:
2) Вирусы. Вирусы так же могут являться причиной тормозов в играх. Ведь во время работы вирус занимает определенную част оперативной памятикомпьютера из за этого не хватает памяти для обработки процессов игры, и игра начинает тормозить, лагать, глючить. Для решения проблемы вирусов нужно установить хороший и надежный антивирус и полностью просканироватькомпьютер. Если антивирус уже установлен, то обязательно обновить его до последней версии.
3) Программы работающие в фоне. Часто бывает, что пользователь не особо разбирается в принципе работы компьютера, запускает 10-20 программ, а потом еще и запускает игру. Естественно игра будет тормозить, лагать и глючить, т.к. у компьютера просто будет не хватать оперативной памяти для обработки всех процессов. поэтому прежде чем запускать игру останоите работу программ, которые «жрут» много памяти (Photoshop, Coreldraw, AutoCAD, Adobe Flash Professional и др).
4) Забитый интернет канал. Любители поиграть в онлайн игры иногда даже не подозревают, что скачивания из интернета (скачивание с торрента к примеру) существенно нагружает интернет канал — это может привести к лагам в онлайн играх. Так чо перед тем как запустить онлайн игру желательно приостановить все текущие скачивания.
5) Настройки графики. Как бы просто это не звучало, но часто причиной лагов в игре являются высокие настройки графики, которые компьютер просто «не тянет». Возможно Ваш комьютер просто слишком стар, что бы «тянуть требовательную игру». Поэтому всегда изучаете системные требования игры перед тем, как скачивать её с торрента
ag
Так же для того, чтобы ускорить работу игр и оптимизировать работу оперативной системы можно сделать дефрагментацию дисков (пуск/ все программы/ стандартные/ служебные/ дефрагментация). Еще можно провести очистку дисков от «мусорных» и ненужных файлов (пуск/ все программы/ стандартные/ служебные/ очистка диска).
Оптимизация работы системы может существенно помочь и работе игр, существует множество программ для ускорения и оптимизации работы системы, это такие программы, как: Toolwiz Care, Auslogics BoostSpeed, CCleaner и другие.
Еще одной довольно распространенной причиной лагов в играх является высыхание термопасты между процессором и кулером. Паста высыхает, и из за этого процессор начинает перегреваться. Для решения этой проблемы нужно заменить термопасту, для этого лучше обратиться к специалисту, хотя продвинутые и опытные пользователи как правило делают это сами.
На этом я пожалуй закончу свою статью, теперь Вы знаете, как убрать лаги в играх. Надеюсь моя статья Вам понравилась. Удачи!
ab
Ста-ста-статтеринг, или откуда в игре берутся микрофризы и как с ними бороться
Представьте себе: вот вы ждете новую часть вашей любимой игры и, наконец, она выходит. Специально под это дело вы обновили свой ПК: установили новейшие ЦП и ГП, увеличили объем оперативки и даже заменили жесткий диск на 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, соответственно. По сути, работа с любой другой частотой кадров была просто невозможна.
Поэтому сложно предсказать, сколько времени потребуется для моделирования и рендеринга одного кадра. (Обратите внимание, что на современных консолях у нас, можно считать, фиксированное оборудование, но сами игры при этом все равно довольно непредсказуемы и сложны.)
Если вы не можете быть уверены, с какой частотой кадров будет работать игра, вам необходимо измерить текущую частоту кадров и постоянно адаптировать физику игры и скорость анимации под нее. Если один кадр занимает 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 сложность рендеринга
Мы также должны принять во внимание тот факт, что современные ЦП и ГП не работают с фиксированной частотой, но у обоих есть системы, которые регулируют их скорость вверх и вниз в зависимости от нагрузки и текущей температуры. Таким образом, игра не может просто предположить, что они будут иметь одинаковую скорость от кадра к кадру. С другой стороны, операционная система и драйверы не могут ожидать, что игра будет выполнять одинаковый объем работы в каждом кадре. Сложные системы связи между двумя сторонами должны быть спроектированы таким образом, чтобы все это принималось во внимание.