Т.е. нельзя хранить адреса на чужие компоненты. Хотя это правило касается автоматической памяти, тот же принцип применяется к динамической памяти - нельзя хранить указатели, которые могут стать невалидными. Какой указатель может стать невалидным в кодовой базе на 2М loc? А тем более еще и не на своих компонентах и либах, это еще один инструмент отладки и тестирования (как и ASan и ему подобные), но который специально создает стрессовые условия для выявления скрытых багов. Если вы каким-то образом смогли выделить, получить или сохранить сырой адрес, то в какой-то момент это "рванет", лучше пусть "рвется" на тестовом стенде. Ну вот пример - простой, вы получили const char* объект, насколько это невалидное поведение?
что-то для отладки, что-то в прод (например телеметрия разная, где и что вы на экране нажимали, каких монстров убивали и в какую часть уровня ходили). Опять же лог надо писать и гдето его сохранять, чтобы отослать в случае краша. Ок, мы выделили буфер для условно одной системы (ИИ), для другой (телеметрия), а для третьей, четвертой и дизайнерской тоже придется делать отдельные?
Это строка, которая выделяет память через фрейм аллокатор (разновидность линейного аллокатора, который сбрасывается в начале фрейма). Т.е. такие строки очень дешевые, вы их можете создавать сотнями и тысячами без какого-то существенного влияния на время кадра. Например вы захотели проийтись по сцене и собрать типы и имена юнитов для каких-то своих нужд, это работа со строками, если вы будете использовать обычный std::string, то это приведет к большому числу аллокаций памяти, которые не нужны. А тут мы знаем что эти данные не живут дольше одного фрейма, мы их собрали обработали и вывели в консоль или файл. Это один пример. Второй пример - это дебаг AI. Есть BT (дерево поведения), оно определяет как себя ведет юнит в данный момент, какую отрабатывает атаку, или прыжок или другое действие. Никакого более удобного способа сериализации состояния БТ кроме строки, которую можно положить в буфер и потом распарсить - игрострострой не придумал. Теперь имеем 30-50-100 и больше объектов на уровне, каждый с запущенным БТ и каждый фрейм может сработать в одном дереве до 100 нод (надо проверить что враг на дистанции, что есть оружие, что выполнены подходящие условия для действия) - каждый вход-выход-проверка в ноде это отдельная строка, которую надо собрать, обработать, отфильтровать и сохранить для дальнешей обработки игровым дизайнером. Если вы будете делать это через стандартный аллокатор, то получите 1 фпс, возьмете самый быстрый TLSF - 10 фпс, но играть на 10 фпс очень сомнительное удовольствие - и дизайнеры вам об этом скажут непременно. Поэтому вы берете самое быстрое что у вас есть, фреймовый или линейный аллокатор и начинаете на нем строить вашу систему отладки ИИ.
А всё общение - это конструкции на основе слов, другого пока не придумали. Не всем интересно, а иногда и скучно, читать углубленные технические детали и код (которого полно на работе, а на Хабр приходят чтобы отдохнуть, а не работать), тем более что часто приводимые технические решения нельзя применить без серьезных доработок, даже если выложены полные исходники. Да и читать плюсовые исходники и разбираться, что там автор понаписал - то еще удовольствие и задача скорее техревью, а не таких текстов. Но не зная определенных подходов или опробованных решений вы будете вынуждены повторять все те ошибки, которые уже были совершены до вас, вместо того чтобы поискать решение на гитхабе или других ресурсах, возможно пейперах или статьях. Ну выложу тут исходники хаос аллокатора - серьезно думаете кто-то будет их смотреть и применять, я сам его использовал последний раз 15 лет назад на паре проектов и больше не хочу.
Это открытая площадка и у Вас всегда есть возможность написать детальный разбор. Я здесь и не ставил целью приводить схемы и графики. В минусах есть соответствующий пункт
Я правильно понял что Вы описываете систему, где движок и "плейграунд" (редактор на базе движка) разделены по слоям, с возможностью отладки через gdb/lldb, кастомным интерфейсом вместо ImGui, и использованием Lua для настройки и рефлексии — то есть речь о модульной архитектуре с возможностью сериализации отдельных компонентов? В теории всё верно, на практике зависит от того как развивался движок
Лучше если Вы будете давать более точные термины в своих ответах, тогда можно это обсуждать с одинаковым их пониманием, общепринятые (когда речь идёт о делении сцены/мира) - регионы (octree, quadtree, grid, BVH, BSP). Сейчас несколько неточно использовано словосочетание "регион в объеме", оно наверное что-то значит, но при таком написании совершенно теряется технический смысл. На сцене есть регионы, в регионе существуют кластеры - это группы чанков или секторов, чанк разбивается на ячейку (cell, если это навмеш или другая сетка) и нода (если это граф или непериодческая структура). Теперь вопрос, в каких терминах вы хотите описать эту зеленую картинку? Прочтите, если будет возможность, Эриксона, там это все объяснено очень доступно
Опять не очень понятно, что вы хотите спросить. Если вы под "подобъемами" подразумеваете окто- и квадродеревья или другие виды spatial разбиения пространства, региона как вы выразились, то да таких методов достаточно много и они давно и хорошо описаны в технической литературе и применяются повсеместно. Могу посоветовать для начала Real-Time Collision Detection Кристофера Эриксона, там подробоно все разобрано. Еше есть Artificial Intelligence for Games Миллигтона, она довольно скучная и с кучей теории, но там тоже все подробно изложено.
Физика есть, но она в стражках специфичная, пользовались разными, Havok -> Box2D -> Jolt -> потом ушли на свое решение поверх box2d -> потом опять вернулись к Jolt. В других проектах обычно PhysX/Bulllet
Это действительно чит, если посмотреть историю комитов Августуса, то он был в технических настройках, видимо для QA и его в какойто момент как и кучу других читов просто вытащили в настройки игры. Если я правильно помню, то глобальный пул был еще в Caesar II, но там это было оправдано механиками игры сразу
там есть боевка (Pharaoh) - форты, отряды, враги. Но я только начал её восстанавливать в Akhenaten, в оригинальной игре была возможность выбирать "мирную" или "опасную" миссию, мирные даже интереснее в чем-то были. В Зевсе боевка очень простая и случайная, можно было засейвскамить часто, ну и баги - частый баг, когда враги умирали после загрузки уровня и только одном построенном храме Зевсу, похоже какая-то ветка условий включалась
MISRA C:2012 Rule 18.6 (https://www.mathworks.com/help/bugfinder/ref/misrac2012rule18.6.html) "The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist"
Т.е. нельзя хранить адреса на чужие компоненты. Хотя это правило касается автоматической памяти, тот же принцип применяется к динамической памяти - нельзя хранить указатели, которые могут стать невалидными. Какой указатель может стать невалидным в кодовой базе на 2М loc? А тем более еще и не на своих компонентах и либах, это еще один инструмент отладки и тестирования (как и ASan и ему подобные), но который специально создает стрессовые условия для выявления скрытых багов. Если вы каким-то образом смогли выделить, получить или сохранить сырой адрес, то в какой-то момент это "рванет", лучше пусть "рвется" на тестовом стенде. Ну вот пример - простой, вы получили const char* объект, насколько это невалидное поведение?
что-то для отладки, что-то в прод (например телеметрия разная, где и что вы на экране нажимали, каких монстров убивали и в какую часть уровня ходили). Опять же лог надо писать и гдето его сохранять, чтобы отослать в случае краша. Ок, мы выделили буфер для условно одной системы (ИИ), для другой (телеметрия), а для третьей, четвертой и дизайнерской тоже придется делать отдельные?
не угадали
Это строка, которая выделяет память через фрейм аллокатор (разновидность линейного аллокатора, который сбрасывается в начале фрейма). Т.е. такие строки очень дешевые, вы их можете создавать сотнями и тысячами без какого-то существенного влияния на время кадра. Например вы захотели проийтись по сцене и собрать типы и имена юнитов для каких-то своих нужд, это работа со строками, если вы будете использовать обычный std::string, то это приведет к большому числу аллокаций памяти, которые не нужны. А тут мы знаем что эти данные не живут дольше одного фрейма, мы их собрали обработали и вывели в консоль или файл. Это один пример.
Второй пример - это дебаг AI. Есть BT (дерево поведения), оно определяет как себя ведет юнит в данный момент, какую отрабатывает атаку, или прыжок или другое действие. Никакого более удобного способа сериализации состояния БТ кроме строки, которую можно положить в буфер и потом распарсить - игрострострой не придумал. Теперь имеем 30-50-100 и больше объектов на уровне, каждый с запущенным БТ и каждый фрейм может сработать в одном дереве до 100 нод (надо проверить что враг на дистанции, что есть оружие, что выполнены подходящие условия для действия) - каждый вход-выход-проверка в ноде это отдельная строка, которую надо собрать, обработать, отфильтровать и сохранить для дальнешей обработки игровым дизайнером. Если вы будете делать это через стандартный аллокатор, то получите 1 фпс, возьмете самый быстрый TLSF - 10 фпс, но играть на 10 фпс очень сомнительное удовольствие - и дизайнеры вам об этом скажут непременно. Поэтому вы берете самое быстрое что у вас есть, фреймовый или линейный аллокатор и начинаете на нем строить вашу систему отладки ИИ.
String(framemem_ptr()) вас устроит? Вот пример прям из рабочего проекта.
А всё общение - это конструкции на основе слов, другого пока не придумали. Не всем интересно, а иногда и скучно, читать углубленные технические детали и код (которого полно на работе, а на Хабр приходят чтобы отдохнуть, а не работать), тем более что часто приводимые технические решения нельзя применить без серьезных доработок, даже если выложены полные исходники. Да и читать плюсовые исходники и разбираться, что там автор понаписал - то еще удовольствие и задача скорее техревью, а не таких текстов. Но не зная определенных подходов или опробованных решений вы будете вынуждены повторять все те ошибки, которые уже были совершены до вас, вместо того чтобы поискать решение на гитхабе или других ресурсах, возможно пейперах или статьях. Ну выложу тут исходники хаос аллокатора - серьезно думаете кто-то будет их смотреть и применять, я сам его использовал последний раз 15 лет назад на паре проектов и больше не хочу.
Это открытая площадка и у Вас всегда есть возможность написать детальный разбор. Я здесь и не ставил целью приводить схемы и графики. В минусах есть соответствующий пункт
А можно переформулировать этот текст? К сожалению, я ничего не понял :(
Я правильно понял что Вы описываете систему, где движок и "плейграунд" (редактор на базе движка) разделены по слоям, с возможностью отладки через gdb/lldb, кастомным интерфейсом вместо ImGui, и использованием Lua для настройки и рефлексии — то есть речь о модульной архитектуре с возможностью сериализации отдельных компонентов? В теории всё верно, на практике зависит от того как развивался движок
Лучше если Вы будете давать более точные термины в своих ответах, тогда можно это обсуждать с одинаковым их пониманием, общепринятые (когда речь идёт о делении сцены/мира) - регионы (octree, quadtree, grid, BVH, BSP). Сейчас несколько неточно использовано словосочетание "регион в объеме", оно наверное что-то значит, но при таком написании совершенно теряется технический смысл. На сцене есть регионы, в регионе существуют кластеры - это группы чанков или секторов, чанк разбивается на ячейку (cell, если это навмеш или другая сетка) и нода (если это граф или непериодческая структура). Теперь вопрос, в каких терминах вы хотите описать эту зеленую картинку? Прочтите, если будет возможность, Эриксона, там это все объяснено очень доступно
Original Game (ресурсы оттуда нужны), а то хождение под веселым роджером сильно карается даже со стороны компаний, которых уже нет
Опять не очень понятно, что вы хотите спросить. Если вы под "подобъемами" подразумеваете окто- и квадродеревья или другие виды spatial разбиения пространства, региона как вы выразились, то да таких методов достаточно много и они давно и хорошо описаны в технической литературе и применяются повсеместно. Могу посоветовать для начала Real-Time Collision Detection Кристофера Эриксона, там подробоно все разобрано. Еше есть Artificial Intelligence for Games Миллигтона, она довольно скучная и с кучей теории, но там тоже все подробно изложено.
Физика есть, но она в стражках специфичная, пользовались разными, Havok -> Box2D -> Jolt -> потом ушли на свое решение поверх box2d -> потом опять вернулись к Jolt. В других проектах обычно PhysX/Bulllet
Могли бы вы переформулировать предложение? Я не очень понял о чем речь идет.
И вы не далеки от истины, Фараон это тот же самый движок с возможностью строить монументы. Изменения видны только в императоре и частично в Зевсе.
Максимальный размер в оригинальной 248х248, но технически это просто матрица тайлов, так что проблем нет
Ага, очень интересная мехника была, жаль что её не сильно развили.
Это действительно чит, если посмотреть историю комитов Августуса, то он был в технических настройках, видимо для QA и его в какойто момент как и кучу других читов просто вытащили в настройки игры. Если я правильно помню, то глобальный пул был еще в Caesar II, но там это было оправдано механиками игры сразу
там есть боевка (Pharaoh) - форты, отряды, враги. Но я только начал её восстанавливать в Akhenaten, в оригинальной игре была возможность выбирать "мирную" или "опасную" миссию, мирные даже интереснее в чем-то были. В Зевсе боевка очень простая и случайная, можно было засейвскамить часто, ну и баги - частый баг, когда враги умирали после загрузки уровня и только одном построенном храме Зевсу, похоже какая-то ветка условий включалась
если objPtrs не уходит дальше локального стека, зачем вы делаете его через вектор?