Перестало работать копирование поста с форматированием и картинками, в т. ч. из редактора. Ну и "любовь" вместо "пальца вверх" как-то смущает. И аплодисменты (а что это?) как "спасибо". Зато нет полезной реакции с английского форума "Saw it".

А вот если бы разработчики запилили многопоточность, увеличение количества игроков не так сильно сказалось на производительности. С этим экспериментом даже у меня начались микролаги. Надо постараться, чтобы на 1080 и i7 танчики перестали комфортно идти.

Что-то у меня FXAA не заводится для Хрома.

Эй, а если Интел? А если Линукс? А если - упаси боже - Мак? Лень Это же стандартный FXAA, можно загуглить сравнения в других играх.

Да, i7 какой-то там 8*** U. У меня тут есть экспериментальный скрипт с FXAA и desynchronized-контекстами, которые, вроде как, уменьшают инпут лаг. Что я могу сказать. Инпут лаг они действительно уменьшают, но начинаются микролаги даже на 60 ФПС. У меня так. Хотел опубликовать скрипт в стартовом посте, но испугался сами-знаете-чего. Завтра может быть здесь выложу.

Похоже, что да. Я проверял ТО на двух ноутбуках (один из них - ультрабук с U-процессором), одном десктопе и двух ОС. И я не могу сказать, что ТО где-либо работает по принципу "запустил - и наслаждаешься". Везде какой-то свой геморрой. На ультрабуке, например, нужно заходить в BIOS, там выставлять режим высокой производительности, и только тогда режим "максимальной производительности" в Винде не приводит к дропам частоты процессора. И то только от сети. С каких пор я в списке поехавших?

А я не спрашиваю, интересно им или нет. Кстати, вот этот эффект я прогнозировал, но считаю его нежелательным. "Статья" не имеет цели показать "вот разработчики рукoжопы не сделали многопоточность! в топку их!" Я понимаю, что везде присутствуют подводные камни, и пункты "что могут сделать разработчики" несут идею "да, у клиента имеются проблемы, но есть куда двигаться, есть что копать и анализировать". BTW. Не хочешь в новую Секту Свидетелей Двенадцати Миллисекунд Фрейм Тайма?

На самом деле эта "статья" незапланированно получилась. Я накопил некоторый объем информации по теме, плюс мне давно хотелось написать текст, ссылку на который можно давать игрокам вместо того, чтобы распинаться перед каждым чуваком о вертикальной синхронизации, контекстах и прочем (я этого никогда и не делал, мне лень ). А тут все в одном месте, удобно.

Похоже, разработчики заодно портировали тормоза en-форума. Что-то он совсем временами подыхает.

Есть Kotlin/WASM, он в разработке. Только там тоже свой GC, который не факт что умеет так же красиво выполнять сборку между фреймами.

Блин. Открой профайлер, зайди в битву и увидишь, что там догружается по ходу. Среди ресурсов - даже какие-то 3ds-ки. Там не в частотах дело, а в точности синхронизации. Винда предоставляет более точный способ, но Хром им не пользуется. И это только на Винде, да.

Режим не имеет к этому никакого отношения, насколько мне удалось понять. Важен источник питания. Конечно можно! Хороший ответ, да? Да хотя бы предзагружать то, что есть. Если даже я такой скриптик смог набросать - значит это не так сложно.

Иногда она все-таки отвечает. Один раз из пяти может быть. Как-то так. А я не могу играть с выключенным v-sync и без ограничения в панели управления. Прыжки от 800 до 200 - просто больно. Плюс там еще у GC не получается вклиниться с быстрыми сборками в idle time и периодически он запускает полную, что тоже сказывается. Зависит от пропускной способности оперативной и видеопамяти. Я был удивлен, насколько быстро текстуры загружаются в VRAM, по крайней мере у меня. А так да, лайт-перезагрузка. Но это всяко лучше :)

Ну, я тебе предоставлял информацию со своего скрипта без всяких профайлеров. Там все то же самое. Только он еще не фиксировал сетевые ивенты, которые, как выяснилось, тоже отъедают. Настолько же сложно, насколько сложно подготовить контекст изначально. Можно использовать тот же код. Да, это небыстро, но всяко несоизмеримо быстрее, чем перезапускать клиент, так еще со сбросом всех кэшей в памяти.

Откуда берутся лаги Сразу оговорюсь, что лаги в играх бывают сетевые - это когда данные с сервера вовремя не приходят на клиент (и наоборот) и локальные - когда сама игра не успевает среагировать на действия пользователя. Грубо говоря: если ваш танк плавно отзывается на управление, а другие танки ведут себя странно - мы имеем дело с сетевым лагом; если вы не можете управлять своим танком, картинка замирает на короткое время и падает FPS - лаг локальный. Так вот, эта часть о локальных лагах. На самом деле, есть еще лаги ввода - о них позже. Итак. Чтобы мы видели плавную картинку, приложение должно успеть подготовить новый кадр за отведенное время. В случае с монитором с частотой обновления 60 Гц это ~16.6 миллисекунд - 1000 / 60. В случае со 120-ти герцовым монитором - ~8.3 миллисекунды. Почему так? Потому что время подготовки кадра может быть разным - 1 миллисекунда, 4, 10 - не важно, но частота обновления монитора постоянна, и если приложение не укладывается - пользователь наблюдает предыдущий кадр вместо нового на протяжении еще 16.6 мс и, разумеется, не очень доволен. Снова не успевает - пользователь видит три одинаковых кадра целых 49.8 мс и совсем в ярости. (На самом деле только если это происходит часто, но мы же любим драматизировать!) Приложение не может сказать монитору "подожжи, сейчас дорисую!" или "готово, выводи!" - оно вынуждено подстраиваться под частоту обновления монитора. Этот механизм называется вертикальной синхронизацией или v-sync. Можно представить это так (извините за колхоз): Получается, у приложения есть достаточно времени, чтобы подготовить каждый кадр и переместить его в специальную область видеопамяти, откуда в назначенную миллисекунду монитор его прочитает и выведет. Но это в идеальном мире. А что если приложение замешкается и справится, скажем, за 20 мс? До того момента, как окончена подготовка нового кадра, в той области памяти находится предшествующий кадр. Его мы и увидим вновь. Теперь представим еще менее идеальный мир. В случае с ТО приложение - это браузер, а сам клиент - это сайт. Следовательно, помимо отрисовки наших танчиков нужно еще скомпоновать страницу - совместить изображение из битвы с интерфейсом на HTML5. И сам интерфейс браузера нужно также отрисовать. Но мы же жестокие, и менее идеальный мир нас все еще не торкает. Ухудшим его! Браузер работает в операционной системе, у которой есть оконный интерфейс рабочего стола, и необходимо объединить вывод браузера с окошечком на фоне нескучных обоев. Итого: Мы все говорим об отрисовке, но рисовать ведь целесообразно лишь обновленное состояние приложения. Значит прежде чем браться за рисование, приложение обрабатывает ввод, производит некоторые вычисления, и только затем вызывает функции рендеринга. У нас ввод - это нажатия клавиш, движения мыши и данные, полученные по сети с сервера. Вот как это выглядит: Здесь клиент обновляет битву, отрисовывает кадр и сразу же обрабатывает информацию с сервера, которая будет использована в следующих кадрах. Все хорошо: игре удалось подготовить новый кадр, а браузеру скомпоновать страницу за ~8 мс (обработка сетевых данных не мешает выводу). Но не все бывает так гладко: Что мы видим? Первый кадр из трех обрабатывается быстро, но напоследок прилетают сетевые данные. И еще. И еще. Второй фрейм начинает готовиться позже чем нужно, так еще и просчитывается долго. В общем, до обновления эрана мы не успели. Монитор не ждет. "Подумаешь, какие-то лишние 16.6 мс!" - могут возразить некоторые. Я предлагаю думать так: на короткое время ваш 60-ти герцовый монитор превращается в 30-ти герцовый. Для динамичных игр, тем более шутеров, чрезвычайно важна стабильность. Нет, не высокий FPS! К низкому, но стабильному FPS можно привыкнуть, а вот к чему привыкнуть нельзя, так это к непредсказуемым подергиваниям изображения. Вот почему 57 фэпээс гораздо, гораздо хуже 60-ти - и разница по пользовательскому опыту здесь далеко не в трех кадрах. Надеюсь, этого объяснения достаточно для понимания нижесказанного. Теперь по проблемам клиента, способным вызывать описанные микролаги. Однопоточность Все операции клиент выполняет последовательно в одном и - что немаловажно - основном потоке браузера. Это означает, что обработка сетевых данных и управления, обновление состояния битвы (в т. ч. просчет физики) и отрисовка результата взаимосвязаны и не могут происходить независимо друг от друга. Любая задержка по вине логической части отодвигает отображение с риском вылететь за пределы условных 16.6 мс с отчетливо ощутимым игроком лагом. Как это реализовано в "нормальных" играх? Два потока: поток отрисовки - выполняет рендеринг как можно быстрее, поток логики - одновременно просчитывает мир, затем передает его состояние потоку отрисовки, при этом задержки в логике не так сильно сказываются на пользовательском опыте. Что могут сделать разработчики: вынести обработку сетевых событий и внутриигровую логику в отдельный поток (workers, offscreen canvas). Что могут сделать игроки: выбирать процессор с высокой производительностью на ядро; использовать профиль питания "Максимальная производительность", повышающий частоту процессора и минимизирующий скачки во времени обновления/отрисовки. Дозагрузки "по ходу пьесы" Связано с предыдущей проблемой. Появление нового игрока в битве сопровождается загрузкой модельки, текстуры краски, текстуры эффекта выстрела, распаковки всего этого добра сначала в оперативную, а затем и в видеопамять. Если загрузка ресурсов и конвертация текстур из сжатого формата в формат, понимаемый видеокартой происходит параллельно (и это заслуга браузера), то применение загруженного непосредственно движком выполняется - правильно! - в основном потоке со всеми вытекающими. И иногда это становится причиной лага. Что могут сделать разработчики: предзагружать ресурсы во время нахождения в лобби и поиска битвы; добавить соответствующие настройки. Сломанный v-sync в Chrome Здесь интереснее. В некоторых случаях система способна сильно урезать точность вертикальной синхронизации. То есть вместо идеальных 16.6 мс до обновления экрана браузер и игра могут "очнуться" многим позже и не успеть выполнить процедуры отрисовки. Дело в том, что Хром использует способ синхронизации, подверженный сильному джиттеру (отклонениям во времени между вызовами), в частности при питании ноутбука от батарейки. И эти отклонения катастрофические. Энтузиасты даже сделали сайт, демонстрирующий сей эффект наглядно - vsynctester.com На моем древнем, но не самом слабом (i5, 860m) ноутбуке, который я специально откопал для тестов, переход на питание от аккумулятора приводит к неистовым скачкам всех графиков, не говоря уже о проверочной надписи "vsync", которая в идеале должна быть постоянно серой. И каждый такой скачок - потенциальный лаг в игре. Что могут сделать игроки: никогда не играть при питании от батарейки; отключить вертикальную синхронизацию. Инпут лаг aka "пьяная камера" Чтобы продемонстрировать инпут лаг наглядно и в ТО, можно открыть гараж и повертеть мышкой танчик. Курсор выводится с минимальной задержкой. Танчик же проходит все круги ада. Чувствуете? Танчик отзывается не мгновенно, а будто догоняет курсор, "пружинит", whatever. Еще более наглядная иллюстрация доступна на все том же сайте - vsynctester.com/game.html Поставьте галочку рядом с "Show software cursor" и ужаснитесь. Это и есть инпут лаг - время между совершением действия и отображением результата на экране. И здесь вновь стоит поблагодарить Хром: задержка ввода на нем, вероятно, гораздо больше, чем могла бы быть. Вспомним интерфейс операционной системы, который во всех вышеперечисленных примерах заменяет "вывод" на "скомпоновать окна, панель задач и нескучные обои и вывести через 16.6 мс": Отмечу, что этап "ОС" никогда не "тормозит" браузер на 16.6 мс, так как приложения выполняют отрисовку не напрямую в область памяти монитора, но в промежуточный буфер ОС: "Особенность" Хрома в том, что из-за бага, который не исправляется почти шесть лет получается вот что: В общем, между тем, как вы, например, прикажете танку ехать вперед нажав на соответствующую кнопку и моментом, когда вы увидите движение на экране... ну, как сказать... Забавно, что разработчики стараются пересадить игроков на мышь, с которой инпут лаг ощущается гораздо сильнее. Как эту проблему решают клиентские игры? У них нет Хрома и во многих случаях (в полноэкранном режиме) нет компоновки уровня ОС. Результат - инпут лаг вдвое меньше. Что могут сделать игроки: отключить v-sync. Отключение v-sync - не всегда выход Отключение синхронизации приводит к такой картине: Браузер не ждет следующего обновления экрана, а сразу начинает подготовку кадра, что сильно помогает при FPS ниже 60. Однако нестабильное время отрисовки никуда не девается, и при частоте выше целевой на монитор выводятся фреймы разной "давности" - от 1 мс (условно) до бесконечности. В один момент мы можем увидеть мир в состоянии, близком к последнему, в следующий - на 12 мс раньше. Разумеется, это сказывается на плавности анимаций и комфорте управления. Данный недостаток нивелируется на высоких фреймрейтах, но вот загвоздка: клиент ТО не способен держать стабильно высокий фреймрейт. На мощном компьютере он постоянно прыгает от 120 до 1000, на счетчике кадров красуется среднее число 560, но корова, как известно, утонула в реке, где ей в среднем было по колено. Почему так происходит (я не про корову, а про скачки во времени отрисовки), надеюсь, догадываетесь. Что могут сделать разработчики: многопоточность. Что могут сделать игроки: если отключаете v-sync - при возможности выставляйте ограничение максимум в 120 кадров в панели управления видеокартой. Серые экраны смерти Помните проблему с утечкой памяти, приводившей к серым экранам у многих игроков? Так вот, утечку памяти разработчики устранили, однако она - не единственная причина, по которой могут возникать серые экраны. Серый или черный экран - это потеря контекста. Контекст - это набор данных (например, текстур) и состояний, позволяющих игре пользоваться аппаратным ускорением для вывода изображения. Шокирующий факт: контекст может теряться по множеству причин, не зависящих от игры, нехватка видеопамяти - только одна из них. Шокирующих факт 2: игра не знает о потере контекста и не умеет его восстанавливать. А ведь техническая возможность восстанавливать контекст давно существует, более того - во многих "best practices" разработки для браузера советуется реализовывать восстановление контекста. Что это означает для игрока? Вместо серого экрана и полного перезапуска клиента - небольшое подтормаживание и дальнейшая нормальная игра. Еще у меня припасен Самый Шокирующий Факт. Утечка видеопамяти была устранена за полгода. У меня есть все основания полагать, что так произошло в том числе из-за того, что разработчики просто-напросто не подозревали о масштабе бедствия. Как я уже говорил, для ТО серый экран - нормальное состояние, клиент не только не умеет восстанавливать контекст - он продолжает работать как ни в чем не бывало. Игра не генерирует исключение и информация о нем не передается в систему учета ошибок. Представляете, да? Тысячи или, может быть, даже десятки тысяч игроков мучились с серыми экранами, а разработчики смотрели в свою систему и видели: все нормально, никаких проблем нет, только на форуме три человека жалуются. Прямо сейчас, возможно, некоторые игроки сталкиваются с серыми экранами - разработчики не знают об этом и отодвигают реализацию восстановления контекста как неприоритетную задачу. Добавлю еще, что система учета ошибок работает мягко говоря неидеально. Запросы к ней практически всегда неудачные. Может быть она перегружена, не знаю. В любом случае для разработчиков и другие проблемы выглядят менее распространенными, чем они есть. Что могут сделать разработчики: реализовать восстановление контекста; починить систему учета ошибок. Прожорливое сглаживание Чтобы избежать неприятного артефакта - "лесенок" по краям объектов - игры используют разные методы антиалиасинга. Клиент ТО говорит браузеру "сделай антиалиасинг за меня", ну а браузер применяет метод множественной выборки или MSAA. Проблема в том, что этот способ медленный и потребляет непомерное количество видеопамяти (в случае с 4K - 1 Гб плюсом!), и в "больших" играх давно вытеснен более современными и эффективными FXAA, SMAA, TAA и другими. Включение MSAA - последнее, что ты делаешь, и то только после того, как выставил остальные настройки на "ультра". Оцените: клиент работает в окружении, где лишняя миллисекунда в отрисовке - это лаг, а лишний мегабайт - часто серый экран, тем не менее он задействует один из самых прожорливых методов сглаживания. Что могут сделать разработчики: запилить "легкий" метод сглаживания для слабых компьютеров и добавить опцию в настройки. Что могут сделать игроки: если вы испытываете проблемы с FPS, но не хотите играть совсем без сглаживания и у вас видеокарта Nvidia - для скачиваемого клиента доступен метод FXAA в панели управления видеокартой. Итог. Я ни в коем случае не хочу сказать, что новый клиент никуда не годится и на нем невозможно играть. Нет, на множестве конфигураций он способен демонстрировать на счетчике кадров заветные 60 ФПС, но вот в чем он терпит неудачу в большинстве случаев - так это в предоставлении т. н. smooth user experience. Даже если вы включите профиль "Высокая производительность", подсоедините ноутбук к сети, отключите вертикальную синхронизацию, выставите ограничение в панели управления - все равно вы периодически будете ощущать микролаги. Время подготовки кадра - катастрофа. И эта катастрофа помножается на особенности браузерного окружения. В играх разработчики стараются минимизировать frame time в т. ч. используя многопоточность и дробя большие задачи на мелкие. В ТО мы наблюдаем картину, когда время между двумя фреймами может отличаться в 2-4 раза без всякой видимой на то причины иногда доходя до 8-12 мс. Вертикальная синхронизация маскирует эту разницу, но сама является проблемой. Кто-то может вспомнить две буквы - GC. Вот GC: А вот клиент ТО: И я замечу, что такое случается на i7 с постоянной частотой 4.2 ГГц. Что там будет на ноутбуках с низковольтными процессорами - страшно представить. А ведь ТО - браузерная игра и она должна "просто работать" без танцев с бубном со стороны игрока. Клиент должен быть стабилен как скала, а не вял и капризен как весенний цветочек, на который боишься дунуть. Ноутбуки - не будущее, а уже давно настоящее. Если разработчики все еще позиционируют ТО как преимущественно браузерную (нет) игру - им стоит подумать, что чувствует пользователь, запустивший игру впервые без предварительной настройки системы.

А как там по нагрузке на процессор? Во время загрузки. Извините за тавтологию. Надо же понять, что именно ее тормозит.

Никто не посмеялся над названием клавиатуры, надо же!

Смотря какие проблемы. Можешь как здесь записать видео? У меня имеется суперэкспериментальное решение проблем с загрузками, только я вам его не отдам.

Ага. Вообще внезапно вышло. Долгая загрузка из-за выключенной аппаратной растеризации - кто бы мог подумать! @Fizzika

На странице chrome://gpu в разделе "Graphics Feature Status" проверяем "Rasterization", если там написано "Software only" - практически наверняка проблемы с загрузкой именно из-за этого. Необходимо включить аппаратную растеризацию на странице chrome://flags переставив параметр "GPU Rasterization" (воспользуйтесь поиском) на "Enabled" и перезапустив браузер. Готово. А как так вышло-то? Насколько бы парадоксально это не звучало, но экран загрузки мешает загрузке. Сильно мешает. Всему виной прожорливая CSS-анимация (да-да, чертовы полосочки!), которая при выключенном ускорении на GPU забирает все процессорное время, а задачи по загрузке ресурсов и декодированию текстур, выполняемые асинхронно в отдельных потоках, не могут вернуть результат когда основной поток постоянно занят. Такая картина:

Никогда не переоценивай способности пользователей. "Забыл", "не обратил внимания на дату", "а че, все-таки первого декабря?!", "ой, уже первое декабря?" - вполне вероятные причины затупов пользователя. Вот если бы они сразу выключили Флэш и там появлялась какая-нибудь хтоническая ошибка вместо человеческого предупреждения - я бы воскликнул "вот рукожoпы". А так все нормально и я не могу не сказать: в кои-то веки и в данной конкретной ситуации разработчики - не рукожoпы. Ну а то, что там кто-то отключает эту табличку (судя по всему, пользуясь способом @Power.Bank и даже не указывая авторство!) - вообще не проблема, чтобы это можно было назвать фейлом.

Минутка для осмысленного коммента...

Такой:

А у меня начались микроподтормаживания. Ощущение, что движок не тянет столько игроков на карте.