Не надо жалости, у меня все отлично ;) Специально спрятал под спойлер, он появился после выхода книги для обратной связи. Вы еще про бусти забыли сказать...
Есть такие понятия как комерческая тайна, авторское право и мнение игроков. Если пользоваться открытами тулами, то рано или поздно код или его части утекут. Если код пишет ИИ, то нет явного авторства кода и условный ChatGPT может взять кусок как есть и встроить его в игру, если код взят из открытых источников и имеет специфичную лицензию, то автор лицензии намример может потребовать открыть всю кодовую базу изза этого небольшого фрагменты. Есть мнение игроков, которые считают что игры должны писать люди для людей, и пока их большинство.
Ну так там не про современный с++, а про базовые вещи, структуры данных, работу с памятью, строки, паттерны оптимизации. Это все мало связано с конкретным стандартом, если охота 20/23 стандарта - это уже отдельно, в нескучное программирование.
Ага, семплирующие это только верхушка чтобы наметить самые явные области куда смотреть: А смотреть надо на Self time (exclusive) проведённое непосредственно в теле функции. Высокое значение = внутри функции есть дорогой код, Total time (inclusive, если есть) время вместе со всеми вызываемыми функциями. Высокое значение = функция является точкой входа в дорогой пайплайн, т.е. надо разбираться не самой функцией, причиной почему функции внутри дорогие, но смотреть выше 3-4 уровня смысла нет, main и update всегда будут дорогими по понятным причинам. Я тут про книгу рассказывал, вся вторая часть посвящена оптимизациям, как, зачем и где смотреть.
Определенно стоило, думаю опыт разработки и оптимизации AoE2, Sims, WarThunder, Metro, Deathloop, Stellaris и еще пары крупных проектов интересен многим. Не всем надо писать с нуля игровой движок. Заглянуть стоит в оглавление, там темы не такие вялые ;)
Таже, просто не все из тех кто на меня подписан читают блог bhv, поэтому с разрешения издательства я утащил текст к себе. Ну и тут часть материала, которая появилась у меня уже после постов в bhv и на линкеде.
Очень многое зависит от сферы применения. Нет отдного какого-то инструмента который мог бы ответить на все вопросы. Начать надо с чегото простого вроде verysleepy, собрать статистику прогонов,чем больше тем лучше. Посмотреть на результаты, но если время работы устраивает, то нет смысла что-то менять. Дальше если действительно есть потребность уменьшить время работы, и есть доступ к исходникам, по интегрируем pix, tracy, optick, mpro или что еще душе угодно, это абслютно неважно, можно и студийным профайлером смотреть. Если есть внутренняя уверенность, что функция должна работать быстрее, ставим метки и смотрим. В половине моих кейсов случаев получить x2 можно просто избавившись от аллокаций, строк, массивов и копирования, но опять же... оптимизировать надо только если действительно надо. По поводу программирования без аллокаций могу вас зазвать на свой курс на степике, будете понимать о чем разговор. Если хочется окунуться еще глубже в теорию оптимизации, то вот здесь еще очень много. Универсального рецепта нет, надо смотреть код
ОпасТное упрощение, потому что автоматический лод (nanite для геометрии, и streaming mips для текстур емнип) лишь автоматизирует часть пайплайна. Nanite работает только с определёнными типами мешей и не поддерживает скелетную анимацию (не поддерживал насколько я помню), прозрачные материалы и еще какие кейсы были, так что художник всё равно обязан понимать, какие ассеты подходят, а какие требуют ручных LOD-ов. текстурный стриминг тоже надо настраивать, и судя по томуже хогвардсу на это тупо забивают, потому что надо потратить столько же времени если не больше на каждую модель.
Чтобы не прийти через некоторое время к "ээээ ууу гугл, давай добавь еще что-нить на этой как, его.. вот сюда вообщем" приходится не только читать, но и слушать. На удивление я сейчас читаю больше разных техматериалов, чем лет десять назад, когда не было клода, чатика и иже с ними
Именно в шутерах вроде контры или валоранта разброс строго детерминирован и есть такое понятие как высокоточные дуэли, которые происходят с выцеливанием по пикселю. Там разница в несколько мс решает, особенно при реакции топовых игроков ближе к ~100–150 мс, это 5–7% от общего времени реакции. Серверный предикшн компенсирует пинг при регистрации хита, но не компенсирует то, что вы видите противника позже из-за интерполяции и низких фпс на своей стороне. Peeker's advantage потому и существует, что клиент атакующего показывает ему противника раньше, чем клиент обороняющегося показывает атакующего, и фпс здесь напрямую влияет на этот разрыв.
Есть такое, но тут надо различать две категории игр, супертяжикам вроде BF пофиг на ваше железо, потому что они выходят для консолей и там всё норм, и вы либо миритесь с низкими настройками либо покупаете новый пк, а еще лучше приставку, потому что приставка это постоянный денежный поток от большого числа игроков. А вот вторая, которым опять же пофиг на ваше железо, вроде инди, AA‑проектов, всякого «долгоиграющего» онлайна с модами и воркшопом. Для них ситуация принципиально другая, потому что они ориентированы на стимовское картофельное железо, которое отстает года на 4 от рынка. Вы приходя c ноутбучной gf1650 поиграть в последний BF не попадаете в ЦА игры. Ну и не стоит забывать, что японский и американский рынки сильно оконсолены, и топовые тайты выходят и собирают основные деньги на консолях, а не пк и там всё норм. И потом -- оптимизировать игры сложно, дорого и затратно по времени, а прироста аудитории дает мало, так скажите будет ли студия тратить условно десять процентов ресурсов, чтобы привлечь еще 1% игроков?
Вот насчет memcpy я бы поспорил, видимо автору чудесным образом удавалось избегать этой черной дыры, ожидая, правильного поведения, но:
это законно с точки зрения сях, но там есть lifetime, и там есть проблемы
компилятор может и оптимизирует это в «невыровненную загрузку», но чаще нет - ибо мемкопи для другого
Компилятор можетраспознать шаблон int32_t x; memcpy(&x, addr, sizeof x); и заменить его на невыровненную загрузку, если целевая архитектура такое поддерживает.
Вы что-то совсем в лесу потерялись: Предложенный Вами подход "просто тестируй и наблюдай" работает только для самых поверхностных задач, впрочем как и большинство ваших предыдущих высказываний. В компьютерной графике без понимания теории вы будете годами наступать на одни и те же грабли, и те же кватернионы имеют неинтуитивные свойства (некоммутативность умножения), которые невозможно понять просто "наблюдая" и вы будете получать странные результаты и не понимать почему.
Описание со сферами вообще какая-то динь непонятная, "3 сферы будут вершинами треугольника" это что это значит? Сферы имеют центры и радиусы, вершины треугольника это точки. "Пересекла треугольник" это кто пересекает? Сфера с плоскостью треугольника? С другими сферами? "Вставляем в формулу"... это в какую? Для проверки чего? Очень нечёткая формулировок как раз показывает отсутствие теоретического понимания.
Едем дальше: труд без направления будет просто потерянным временем и можно годами экспериментировать с двойными кватернионами методом тыка, так и не поняв почему они представляют винтовые движения через алгебру клиффорда, ну зачем вам об этом знать? ведь у вас же опытный путь познания через блендер
"Математика точнее программирования" вы точно в этом уверены? Это все равно, что сравнить тёплое с мягким. Математика это язык моделей, программирование способ их реализации. Программирование реализует математические модели, и если вы не понимаете математику, ваш код будет полон багов, которые вы не сможете отловить никаким тестированием. сигфолты возникают не от недостатка экспериментов, а от непонимания модели языка, памяти, и кучи еще вещей внутри ОС... давай те ка уроним пару раз ось и покопаем дамп, ну а чё - эсперимент же? эсперимент. посмотрим надолго нервов у коллег на вас с такими опытами?
Резковато? Ну извините, достало уже читать этот бред сбежавшей нейросети
Не надо жалости, у меня все отлично ;) Специально спрятал под спойлер, он появился после выхода книги для обратной связи. Вы еще про бусти забыли сказать...
Есть такие понятия как комерческая тайна, авторское право и мнение игроков. Если пользоваться открытами тулами, то рано или поздно код или его части утекут. Если код пишет ИИ, то нет явного авторства кода и условный ChatGPT может взять кусок как есть и встроить его в игру, если код взят из открытых источников и имеет специфичную лицензию, то автор лицензии намример может потребовать открыть всю кодовую базу изза этого небольшого фрагменты. Есть мнение игроков, которые считают что игры должны писать люди для людей, и пока их большинство.
@Kotyara99А у вас была возможность разобрать фрейм через RenderDoc? Может получится вытащить реверснутые шейдеры?
Благодарю, надеюсь найдёте полезные моменты и практики
Ну так там не про современный с++, а про базовые вещи, структуры данных, работу с памятью, строки, паттерны оптимизации. Это все мало связано с конкретным стандартом, если охота 20/23 стандарта - это уже отдельно, в нескучное программирование.
Ага, семплирующие это только верхушка чтобы наметить самые явные области куда смотреть: А смотреть надо на Self time (exclusive) проведённое непосредственно в теле функции. Высокое значение = внутри функции есть дорогой код, Total time (inclusive, если есть) время вместе со всеми вызываемыми функциями. Высокое значение = функция является точкой входа в дорогой пайплайн, т.е. надо разбираться не самой функцией, причиной почему функции внутри дорогие, но смотреть выше 3-4 уровня смысла нет, main и update всегда будут дорогими по понятным причинам.
Я тут про книгу рассказывал, вся вторая часть посвящена оптимизациям, как, зачем и где смотреть.
Выложил оглавление под спойлер, всё есть.
Добавил ссылку на ozon, там есть оглавление.
Определенно стоило, думаю опыт разработки и оптимизации AoE2, Sims, WarThunder, Metro, Deathloop, Stellaris и еще пары крупных проектов интересен многим. Не всем надо писать с нуля игровой движок. Заглянуть стоит в оглавление, там темы не такие вялые ;)
Таже, просто не все из тех кто на меня подписан читают блог bhv, поэтому с разрешения издательства я утащил текст к себе. Ну и тут часть материала, которая появилась у меня уже после постов в bhv и на линкеде.
Google docs + word. Aнатлий работал в Corel насколько я знаю
Очень многое зависит от сферы применения. Нет отдного какого-то инструмента который мог бы ответить на все вопросы. Начать надо с чегото простого вроде verysleepy, собрать статистику прогонов,чем больше тем лучше. Посмотреть на результаты, но если время работы устраивает, то нет смысла что-то менять. Дальше если действительно есть потребность уменьшить время работы, и есть доступ к исходникам, по интегрируем pix, tracy, optick, mpro или что еще душе угодно, это абслютно неважно, можно и студийным профайлером смотреть. Если есть внутренняя уверенность, что функция должна работать быстрее, ставим метки и смотрим. В половине моих кейсов случаев получить x2 можно просто избавившись от аллокаций, строк, массивов и копирования, но опять же... оптимизировать надо только если действительно надо. По поводу программирования без аллокаций могу вас зазвать на свой курс на степике, будете понимать о чем разговор. Если хочется окунуться еще глубже в теорию оптимизации, то вот здесь еще очень много. Универсального рецепта нет, надо смотреть код
ОпасТное упрощение, потому что автоматический лод (nanite для геометрии, и streaming mips для текстур емнип) лишь автоматизирует часть пайплайна. Nanite работает только с определёнными типами мешей и не поддерживает скелетную анимацию (не поддерживал насколько я помню), прозрачные материалы и еще какие кейсы были, так что художник всё равно обязан понимать, какие ассеты подходят, а какие требуют ручных LOD-ов. текстурный стриминг тоже надо настраивать, и судя по томуже хогвардсу на это тупо забивают, потому что надо потратить столько же времени если не больше на каждую модель.
Чтобы не прийти через некоторое время к "ээээ ууу гугл, давай добавь еще что-нить на этой как, его.. вот сюда вообщем" приходится не только читать, но и слушать. На удивление я сейчас читаю больше разных техматериалов, чем лет десять назад, когда не было клода, чатика и иже с ними
Именно в шутерах вроде контры или валоранта разброс строго детерминирован и есть такое понятие как высокоточные дуэли, которые происходят с выцеливанием по пикселю. Там разница в несколько мс решает, особенно при реакции топовых игроков ближе к ~100–150 мс, это 5–7% от общего времени реакции.
Серверный предикшн компенсирует пинг при регистрации хита, но не компенсирует то, что вы видите противника позже из-за интерполяции и низких фпс на своей стороне. Peeker's advantage потому и существует, что клиент атакующего показывает ему противника раньше, чем клиент обороняющегося показывает атакующего, и фпс здесь напрямую влияет на этот разрыв.
Есть такое, но тут надо различать две категории игр, супертяжикам вроде BF пофиг на ваше железо, потому что они выходят для консолей и там всё норм, и вы либо миритесь с низкими настройками либо покупаете новый пк, а еще лучше приставку, потому что приставка это постоянный денежный поток от большого числа игроков.
А вот вторая, которым опять же пофиг на ваше железо, вроде инди, AA‑проектов, всякого «долгоиграющего» онлайна с модами и воркшопом. Для них ситуация принципиально другая, потому что они ориентированы на стимовское картофельное железо, которое отстает года на 4 от рынка.
Вы приходя c ноутбучной gf1650 поиграть в последний BF не попадаете в ЦА игры. Ну и не стоит забывать, что японский и американский рынки сильно оконсолены, и топовые тайты выходят и собирают основные деньги на консолях, а не пк и там всё норм.
И потом -- оптимизировать игры сложно, дорого и затратно по времени, а прироста аудитории дает мало, так скажите будет ли студия тратить условно десять процентов ресурсов, чтобы привлечь еще 1% игроков?
Вот насчет memcpy я бы поспорил, видимо автору чудесным образом удавалось избегать этой черной дыры, ожидая, правильного поведения, но:
это законно с точки зрения сях, но там есть lifetime, и там есть проблемы
компилятор может и оптимизирует это в «невыровненную загрузку», но чаще нет - ибо мемкопи для другого
Компилятор может распознать шаблон
int32_t x; memcpy(&x, addr, sizeof x);и заменить его на невыровненную загрузку, если целевая архитектура такое поддерживает.поймайте для начала момент, когда в предложения надо вводить точки.
Что за бред
Вы что-то совсем в лесу потерялись:
Предложенный Вами подход "просто тестируй и наблюдай" работает только для самых поверхностных задач, впрочем как и большинство ваших предыдущих высказываний. В компьютерной графике без понимания теории вы будете годами наступать на одни и те же грабли, и те же кватернионы имеют неинтуитивные свойства (некоммутативность умножения), которые невозможно понять просто "наблюдая" и вы будете получать странные результаты и не понимать почему.
Описание со сферами вообще какая-то динь непонятная, "3 сферы будут вершинами треугольника" это что это значит? Сферы имеют центры и радиусы, вершины треугольника это точки. "Пересекла треугольник" это кто пересекает? Сфера с плоскостью треугольника? С другими сферами? "Вставляем в формулу"... это в какую? Для проверки чего? Очень нечёткая формулировок как раз показывает отсутствие теоретического понимания.
Едем дальше: труд без направления будет просто потерянным временем и можно годами экспериментировать с двойными кватернионами методом тыка, так и не поняв почему они представляют винтовые движения через алгебру клиффорда, ну зачем вам об этом знать? ведь у вас же опытный путь познания через блендер
"Математика точнее программирования" вы точно в этом уверены? Это все равно, что сравнить тёплое с мягким. Математика это язык моделей, программирование способ их реализации. Программирование реализует математические модели, и если вы не понимаете математику, ваш код будет полон багов, которые вы не сможете отловить никаким тестированием. сигфолты возникают не от недостатка экспериментов, а от непонимания модели языка, памяти, и кучи еще вещей внутри ОС... давай те ка уроним пару раз ось и покопаем дамп, ну а чё - эсперимент же? эсперимент. посмотрим надолго нервов у коллег на вас с такими опытами?
Резковато? Ну извините, достало уже читать этот бред сбежавшей нейросети