All streams
Search
Write a publication
Pull to refresh
0
0
Send message
Думаю проблема всё же в коде движка, сторонние библиотеки здесь не играют роли, разные версии движка тестировались на разных ОС и железе(конечно количество установленной оперативной памяти позволяло диагностировать ошибку), ошибка везде одинаковая, количество свободной памяти при возникновении ошибки достаточно большое(в случае 32х гб свободными остаются более 22х), ос и библиотеки движка 64х битные. А так понятно что дело сложное, тем не менее при возникновении ошибки дебаггер первым делом скидывает на модуль CrySystem, впрочем я ещё толком не смотрел что там, нужно сначала его скомпилировать чтобы сгенерировалась информация для дебаггера. В общем движок сам по себе стал нестабилен со времён пятой версии, иногда зависает на начальном этапе загрузки без видимых причин, бывает что вылетает на загрузке уровня указав на atidxx64.dll. В предыдущих версиях (EAAS) подобные проблемы отсутствовали, за исключением конечно ошибки выделения памяти.
Версия библиотек 64х битная, 32х битная версия не поддерживает редактор уровней,.ехе файл редактора давно не поставляется с ней в комплекте, потому то я и не посчитал нужным указать информацию о версии. Спасибо за ответ, значит проблема всё же в 64х битных ошибках.
Здравствуйте. Я очень давно работаю с движками серии «CryEngine», и у меня есть несколько вопросов касательно ошибок которые нашёл ваш анализатор, конкретно меня интересуют ошибки связанные с функциями и алгоритмами выделения памяти объектам в движке. Дело в том, что в движке есть очень серьёзные проблемы с выделением памяти, зачастую движок не в состоянии задействовать более 3.5 гигабайт системной памяти, иногда меньше, иногда чуть больше, зависит от того чем заполнять память, инстанциями каких объектов и т.д. Это наблюдается на любом железе с достаточным объёмом оперативной памяти и любой 64х разрядной ОС. Данная проблема, скорее всего, уже имела место быть с самой первой версии движка, однако я с ней столкнулся начиная со второй версии движка(CryEngine 2), первую не тестировал на предмет наличия.

Собственно, при достижении указанного значения потребления памяти движок просто выдаёт ошибку выделения памяти(memory allocation for x bytes failed) по сей день на самой последней версии СЕ 5.1.1, прямо «из коробки», т.е без каких либо изменений кода и прочих элементов. На систему установлено 32 гигабайта оперативной памяти, в других движках, например «Юнити 5», подобных проблем с выделением памяти не наблюдалось. Память 100% остаётся свободна при возникновении ошибки, были протестированы конфигурации с 8ю и 16ю гигабайтами памяти, ошибка проявляется всегда при одинаковых условиях, появление ошибки так же не зависит от размера файла подкачки(при размере меньше 1го гб появляется похожая ошибка но уже с рекомендацией увеличить размер «heap» памяти).

Что меня конкретно интересует по результатам анализа: ошибки и спорные места в файлах GeneralMemoryHeap.h и cpp, MemoryFragmentationProfiler.h, MemoryAddressRange.h и cpp, MemoryManager.h и cpp, CryMemoryManager.cpp, CustomMemoryHeap.h и cpp, MTSafeAllocator.h и срр, PageMappingHeap.h и срр, CryDLMalloc.c, CrySizerImpl.h и срр, LevelHeap.cpp, MemReplay.h и срр а так же SystemWin32.cpp. Крайтек игнорирует сообщения об этой ошибке на своих форумах уже довольно давно, или в некоторых случаях просто не может сказать ничего вразумительного. Учитывая тот факт что за 10 лет проблема как была так и осталась то просто очевидно что фиксить они её не собираются в ближайшее время.

Данная проблема проявляет себя во всей красе при работе с большими уровнями, или уровнями с хорошей детализацией( в большом количестве мелкие объекты, инстанции растительности и пр.), всё это в совокупности может привести к заполнению движком 3.5 гб памяти с последующим возникновением ошибки выделения памяти. При тестировании такого уровня в дальнейшем в режиме игры проблем не возникает, т.к в режиме игры включаются определённые оптимизации и часть объектов просто не загружается в память полностью, тем не менее можно вызвать данную ошибку выделения даже во время игры заспавнив определённое количество объектов в любых местах уровня, при этом количество объектов не обязательно будет слишком большим, скажем 1700 объектов, что далеко от предела количества объектов на одном уровне обозначенного в офиц. документации.

Буду также очень рад если вы поделитесь своими идеями по поводу корней данной проблемы а так же возможных теоретических способах её решения. Вообще я стараюсь работать только с 2мя модулями движка — СryGame и CryAction и не лезть в другие модули, но моя надежда на то что Крайтек решит эту проблему в каком нибудь обновлении движка давно утрачена, а учитывая что теперь исходный код почти всех модулей доступен — почему бы не попробовать решить её?

Information

Rating
Does not participate
Registered
Activity