Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 16
И при всех этих средствах мы все равно попадаем в ситуацию, где разработчики видеоигр повально забивают на оптимизацию, и мы приходим к ситуации где длсс не просто приятное дополнение, чтобы твоё железо жило подольше, а необходимость, без которой ты банально не сможешь поиграть :)
Есть такое, но тут надо различать две категории игр, супертяжикам вроде BF пофиг на ваше железо, потому что они выходят для консолей и там всё норм, и вы либо миритесь с низкими настройками либо покупаете новый пк, а еще лучше приставку, потому что приставка это постоянный денежный поток от большого числа игроков.
А вот вторая, которым опять же пофиг на ваше железо, вроде инди, AA‑проектов, всякого «долгоиграющего» онлайна с модами и воркшопом. Для них ситуация принципиально другая, потому что они ориентированы на стимовское картофельное железо, которое отстает года на 4 от рынка.
Вы приходя c ноутбучной gf1650 поиграть в последний BF не попадаете в ЦА игры. Ну и не стоит забывать, что японский и американский рынки сильно оконсолены, и топовые тайты выходят и собирают основные деньги на консолях, а не пк и там всё норм.
И потом -- оптимизировать игры сложно, дорого и затратно по времени, а прироста аудитории дает мало, так скажите будет ли студия тратить условно десять процентов ресурсов, чтобы привлечь еще 1% игроков?
Пример с герцовкой фпс как обычно глупый и нужен чисто для лоббирования высокогерцовых мониторов. Если при 60 фпс модель на тике не оказывается там где она должна быть, то это проблема игры в любом случае. В реальности в нормальных компетитив играх есть серверный предикшн коллизий и все эти оффсеты на пол экрана завязаны на пинг, а не фпс, либо сами оффсеты поскейленные на расстояние и размеры экрана будут отличаться на десяток пикселей, то бишь на ширину мушки прицела и с учётом разброса оружия не будет иметь принципиального значения.
Именно в шутерах вроде контры или валоранта разброс строго детерминирован и есть такое понятие как высокоточные дуэли, которые происходят с выцеливанием по пикселю. Там разница в несколько мс решает, особенно при реакции топовых игроков ближе к ~100–150 мс, это 5–7% от общего времени реакции.
Серверный предикшн компенсирует пинг при регистрации хита, но не компенсирует то, что вы видите противника позже из-за интерполяции и низких фпс на своей стороне. Peeker's advantage потому и существует, что клиент атакующего показывает ему противника раньше, чем клиент обороняющегося показывает атакующего, и фпс здесь напрямую влияет на этот разрыв.
~100–150 мс
конкретно этот разброс - это реакция примерно любого человека. У про игроков разброс в районе 90-120.
что клиент атакующего показывает ему противника раньше, чем клиент обороняющегося показывает атакующего
звучит довольно бессмыслено. если я играю против кого-то то и этот кто-то играет против меня - кто из нас атакующий и кто обороняется, особенно если карта симметрична?
Peeker's advantage связан с геометрией перспективы камер игроков вокруг углов, а не фпс. И опять же ключевую роль сыграет именно сетевая задержка, а не фпс.
Ох уж эта секта свиделей 60(144)fps... Им хоть сколько доказывай... Помимо того что fps принципиально ничего по факту не решает в нормальной реализации игры , но они будут упорно рассказывать что они видят разницу... А ноги растут у этой сказки из такой гадости как андроид - где интерфейс обрисовывается из расчета 60кадров / секунду... Но это лиш значит что если в игре какое то движение длится 1/3 секунды - будет отрисовано 20 фреймов... Если перевести частоту отрисовки экрана в режим 120Hz - то эти 20 фреймов будут отрисовано уже не за 1/3 секунды, а за 1/6 ... Что даёт нам ощущение более производительного устройства ))).. я полагаю что в некоторых играх та же дыра ( ну и когда сталкивался с облачным геймингом на Андроиде - там ещё влиял встроенный фреймбуфер - если правильно помню 3 кадра , что давало дополнительные 1/20секунды задержки вывода , плюс тайм-аут сетевого соединения , плюс время кодирования на стороне сервера - там задержки на 1/3 секунды были , вот там да - играть крайне неудобно было...
До сих пор помню - когда PUBG только-только вышел в тест альфа версии, у всех была отвратительная производительность. Спустя некоторое время, появились видео где приводились причины такой плохой работы - одним из примером были текстуры пальцев персонажей, на которых были видны отпечатки пальцев! Естественно для игры со 100 игроками на гигантской карте это были излишне качественные текстуры.
К счастью Unreal Engine из коробки умеет подбирать уровни детализации как для текстур, так и для геометрии, что позволяет избежать подобных проблем с ресурсами. На сегодняшний день это уже не проблема художников и дизайнеров моделей, скорее проблема настройки и использования самого Unreal Engine и утилит. Пожалуй единственной проблемой слишком детализированных картинок будет итоговый размер игры на диске.
ОпасТное упрощение, потому что автоматический лод (nanite для геометрии, и streaming mips для текстур емнип) лишь автоматизирует часть пайплайна. Nanite работает только с определёнными типами мешей и не поддерживает скелетную анимацию (не поддерживал насколько я помню), прозрачные материалы и еще какие кейсы были, так что художник всё равно обязан понимать, какие ассеты подходят, а какие требуют ручных LOD-ов. текстурный стриминг тоже надо настраивать, и судя по томуже хогвардсу на это тупо забивают, потому что надо потратить столько же времени если не больше на каждую модель.
А есть какой-то гайд по профилированию приложений (или это он и был)?
Опишу кейс. У меня приложение - пример использования библиотеки, которую я делаю. Оно запускается, делает бизнес логику, завершается. На все около 1 секунды на моем железе. Там внутри установка подключения к серверу, формирование пакетов, шифрование, отправка, получение, дешифрование, парсинг пакетов, пакеты разные, отправляются и принимаются параллельно, основная логика в одном потоке, но есть еще парочка дополнительных. Как выбирать чем, что и как профилировать?
Раньше, на прошлой работе, использовал tracy для гуи приложения. Мне в целом хватало просто пройтись по записанным функциям и посмотреть, что сколько занимает, потом добавить детализации и посмотреть где именно тратится время. Тут часто ошибался, с тем, что менял одновременно и код, и добавлял точки для сбора трейсов, получалось, что время увеличивалось, хотя ожидал, что оно уменьшится.
Для меня это все еще самый очевидный подход, но он кажется трудоемким и сложно повторяемым.
Очень многое зависит от сферы применения. Нет отдного какого-то инструмента который мог бы ответить на все вопросы. Начать надо с чегото простого вроде verysleepy, собрать статистику прогонов,чем больше тем лучше. Посмотреть на результаты, но если время работы устраивает, то нет смысла что-то менять. Дальше если действительно есть потребность уменьшить время работы, и есть доступ к исходникам, по интегрируем pix, tracy, optick, mpro или что еще душе угодно, это абслютно неважно, можно и студийным профайлером смотреть. Если есть внутренняя уверенность, что функция должна работать быстрее, ставим метки и смотрим. В половине моих кейсов случаев получить x2 можно просто избавившись от аллокаций, строк, массивов и копирования, но опять же... оптимизировать надо только если действительно надо. По поводу программирования без аллокаций могу вас зазвать на свой курс на степике, будете понимать о чем разговор. Если хочется окунуться еще глубже в теорию оптимизации, то вот здесь еще очень много. Универсального рецепта нет, надо смотреть код
Я просто не понимаю как интерпретировать результаты семлпирования. По сути просто посмотреть на те функции, которые дольше всех выполняются, и прикинуть, должны ли они выполняться быстрее?
А дальше уже инструментированием разбираться конкретнее, на что и в каких пропорциях тратится время?
https://github.com/VerySleepy/verysleepy - что-то для windows. Для linux есть perf, который делает то же самое?
Ага, семплирующие это только верхушка чтобы наметить самые явные области куда смотреть: А смотреть надо на Self time (exclusive) проведённое непосредственно в теле функции. Высокое значение = внутри функции есть дорогой код, Total time (inclusive, если есть) время вместе со всеми вызываемыми функциями. Высокое значение = функция является точкой входа в дорогой пайплайн, т.е. надо разбираться не самой функцией, причиной почему функции внутри дорогие, но смотреть выше 3-4 уровня смысла нет, main и update всегда будут дорогими по понятным причинам.
Я тут про книгу рассказывал, вся вторая часть посвящена оптимизациям, как, зачем и где смотреть.
Уже читаю какую вашу статью и каждый раз кайфую, спасибо за труды, думаю сил вложено немало, приятно что можно почерпнуть у опытного разработчика вещи, на которые стоит обратить внимание.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Охота за красным fps