Комментарии 17
выйделяйте тогда игровые сущности на стеке никто не против, а кучай указатей еще никому не вредила если это игровые обьекты, конструкторы придётся делать под это дело, так как чтобы скопировать обьект векрнее просто его указатель надо скопировать всё что в нём
например еммитер партиклей, значительно имеет значение как делать - создаём вектор указателей удаляем партикль если время вышло, в емитере создаём новый по new, если так не делать то вроде возрастает фрагментация, или я ошибаюсь
другой пример пулл обьектов, у меня на указателях тоже указатели создаются на этапе распаковки, другой момент что такое программирование может быть не удобным типо vec<obj*>*
другой пример, по доступу к СТЛ С++ проще, отсюда вопрос есть кубик крафт, в чанке 270 тысяч пускай и оптимизированных обьектов вопрос как хранить по указателю или без тут уже хочешь не хочешь начнешь думать как хранить такое
а какая скорость будет если передать указатель на вектор в котором указатели на структуру
аля
sctruct/class
{
int a=0;
};а вижу вы сравниваете время вставки, простите
std::vector<float> t(5,0); or emplace_back еще можно resize(5); и будет аналог array, еще можно попробовать vec = {1,2,3,4,5};
Скрытый текст
и пример с new который в 0 работает (UPD не работает с new)
В играх динамическое выделение памяти в большинстве случаев запрещено, вам 95% завернут такой код на ревью.
тоесть произошла коллизия обьекта который летит в метаданные (буллет), арбитр засчитал коллизию иииииииииииии очень интересно если нельзя new/delete - у вас без указателя на обьекте который летит будет в мире висяк коллизии, тоесть (указатель как раз вроде в этом случае - случай для не фрагментации последовательности поидее могу ошибаться)
Ну скорее всего у вас есть пул объектов под это, он уже распределен, берете оттуда свободный объект и заполняете его. Но вот чтобы прям на лету создавать - лучше такого не делать
буллет геометрическая частица получается которая визуализируется эффектом, помимо мгновенного буллета по иерархии или еще какойто(структуре), есть медленные буллеты - скажем дифференцируемые по времени просто летят рисуя красивый еффект, такая частица 1 визулизируемая 1 еффектом красивым, поидее можно и удалить, потомучто ну даже не смотря на то какой движок, потомучто это частица по всем определениям всетаки, а игрок или актор это не частица, а постоянный резидент памяти (ну представьте у вас маны 100 процентов играем магом, у него 5 зарядов и в дереве талантов абилки ну 30-40 сфер на выбор их что хранить создавать когда уровень апается, проще держать данные статов, и во время вызова смотря от статов считать урон сферкой ), там в идеале разные еффекты будут (просто привет пример на сферках, сферка она 1 еффектов шкурок множество)
тоесть получается образно создаётся точное количество байт под функционал игры, допустим все элементы в базе данных или в сериализационном файле, структурированы, получается вот создали точный регион памяти и разрешили коллизию, в регионе висит обьект указатель, как без фрагментации внутри региона избавится от обьекта? то что в си++ можно посчитать байты понятно, а вот с функционалом из сериализации где почти всё на указателях очень интересно получается, помойму так и так фрагментация, ведь суть в том чтоб отдать занимаемую память в ОС чтоб она её зачла так сказать я вот раньше так думал
Для всего этого придумали ECS. Нужно создать объект - легко у нас выделеный чанк памяти. Нужно удалить? Муваем последний на место удаленного. Указатели не используем, используем линейно индексируемые идентификаторы. За O(1) получаем где реально хранится объект. Минимум Аллокаций, а если кэшировать размер архетипов, то вообще все чанки памяти можно выделить всё заранее. В итоге обход всех объектов - через линейное чтение чанков. Удаление создание без аллокаций, можно ещё и все в многопотоке все считать, при особом желании.
Вы ещё забыли сказать, что никаких исключений и rtti в геймдеве!
ну ислючения выключены по вполне понятным причинам, отдавать 3-4% за редко используемые штуки? Или вы считаете, что ловить в релизе ошибки это нормально? rtti же вполне себе есть, cast в обе стороны работает, а в девбилдах и обычный dynamic_cast оставляют, современные компиляторы не так много на этом теряют
Но все заменить на array тоже не получится - мы как-то столкнулись с проблемами при портировании игры c ps4 на Nintendo Switch, был некий код с условно с 20 if'ами', в каждой ветке создавался временный объект. Код прекрасно работал на ps4, но для cвича понадобился 21-ый if со своим временным объектом. На плойке стек был 2Мб, и на вызове этой функции уже было израсходовано условно 460кб. А вот на свиче, стек не мог быть больше 480Кб на любой тред, и для полного исчерпания стека тогда достаточно было, чтобы кто-то разместил на стеке еще порядка 20 килобайт.
Если я правильно представляю, это что-то вроде
if(...) {
Class1 obj1;
...
}
if(...) {
Class2 obj2;
...
}Разве obj1 и obj2 не создаются в одном и том же месте стека? Если одновременно может существовать только один объект, почему все их размеры суммируются?
Что-то я ничего ни в одном из каментов не понял :)
Game++. Cooking vectors