Привет, товарищ!
Из этой статьи ты узнаешь, как повысить частоту кадров в твоей игре до 60, а то и выше.
Даже если у тебя очень слабый компьютер, не переживай, решение есть.
Сегодня мы оптимизируем по полной

Часть первая: fragMOTION — Зло

Оптимизация в FPS Creator всегда оставляла желать лучшего.
На сравнительно небольшой карте частота кадров может значительно проседать даже на компьютере с неплохой видеокартой, и явно достаточным запасом оперативной памяти.
Процессор во внимание не берем, поскольку в нашей ситуации это никакой роли не играет.

Готовая собранная игра действительно имеет проблемы с производительностью, и в первую очередь связано это с кривым кодом. За свою многолетнею историю конструктор не раз переписывался под разные операционные системы, и разные нужды. Часто что-то вырезалось, либо на скорую руку добавлялось, в следствии чего мы имеем хоть и рабочий, но местами достаточно багованный продукт.
На протяжении всего существования проекта разработчики регулярно поставляли обновления, стараясь исправлять критические ошибки, добавлять новые возможности, и в целом поддерживать свое творение на плаву. Но, как бы там ни было, всему приходит конец, и движок все-таки был заброшен.
И некоторые упущения, как например плохая оптимизация, так и не были решены.


Благо, официальный разработчик опубликовал исходный код программы, что позволило начать создавать полноценные модификации, тем самым продлевая жизнь движка и по сей день.
Так, например, самый продвинутый и стабильный на данный момент Black Ice Mod существенно расширяет возможности конструктора, добавляя множество новых комманд, и выводя разработку игры в этой среде на новый уровень. Все достоинства обновления можно перечислять долго, но не благодаря одним только новым фичам этот мод так обязателен к установке. В первую очередь он исправляет критические ошибки, минимизирует вероятность сбоя программы, а так же улучшает производительность, чему собственно и посвящена эта статья.

Но не все проблемы можно решить одним только изменением исходного кода.
Многое зависит от самого игродела, и того, какой софт он использует для создание своего контента. Тут то мы и подбираемся к самой сути..

После многочисленных тестов я выяснил, что излюбленная креаторщиками программа fragMOTION имеет серьезную проблему с экспортом моделей имеющих риг.
Что конкретно не так, я ответить не могу, но с уверенностью могу сказать, что если такую модель импортировать в FPSC и сделать ее динамической, то частота кадров упадет на 10-15 единиц.
Чем больше таких компонентов будет в сцене, тем значительнее будет ухудшение производительности.
Если и вас достаточно мощная система, то на пустой карте вы можете не заметить разницу, но она точно будет ощутима на готовом уровне. Также fps будет падать при контакте с этим объектом.
В общем, суть в том, что либо fragMOTION криво экспортирует модель с ригом, либо движку сложно обрабатывать файлы из этой программы. Аналогичная проблема возникает и в работе с MilkShape — другой любительской программой для моделирования и анимации.

Не имеет значение, какой объект, и есть ли у него анимация. Если модель имеет кость и назначенные к ней вертексы, падения частоты кадров не избежать.
Для чистоты эксперемента вы можете поставить в редакторе любую стандартную дверь и запустить тест. Поскольку в последней версии мода максимальное значение fps установлено на 80, счетчик будет показывать честные 80-79 кадров в секунду.



А теперь попробуем открыть модель этой двери в fragMOTION и не внося никаких изменений экспортируем ее заменяя оригинал. Ву-а-ля, fps стал заметно ниже.



Решение проблемы простое и сложное одновременно: использовать 3DMax или Blender для экспорта моделей в Х формат.
Практически все официальные модельпаки были созданы именно в 3DMax, который имеет более детальные настройки экспорта, и FPSC отлично работает с файлами оттуда.
Подробную статью по экспорту из 3DMax в FPS Creator я опубликую позже, она будет доступна здесь.

Это была первая существенная проблема, значительно влияющая на производительность, с которой мы разобрались. И это действительно очень важный момент, поскольку многие анимированные модели, что были созданы сообществом, были сделаны или конвертированы именно с помощью fragMOTION или MilkShape. Также важно заметить, что со статическими объектами все нормально. Стоит избегать использования экспорта из этих программ именно в динамическом состоянии.

Часть вторая: Файлы BIN и DBO тоже Зло

Если ты более менее продвинутый креаторщик, ты обязан знать, что после каждого теста FPS Creator в папках с моделями создает BIN и DBO файлы.
Что это такое, зачем они нужны, и нужны ли вообще, сейчас разберемся.

Каждый разработчик уважающий свой продукт стремится создать свою файловую систему с собственными уникальными расширениями файлов, и наш конструктор в этом не исключение.
FPS Creator написан на языке Dark Basic и в качестве 3D моделей понимает только собственный формат Dark Bacic Object — DBO.
Поскольку этот формат не популярен в 3D среде, в FPSC сделали возможным использовать модели DirectX — X. Но напрямую эти файлы не читаются, и чтобы программа понимала их, в нее встроен автоматический конвертер в DBO. То есть, когда мы выбираем какую-либо ентити в библиотеке, ее Х модель конвертируются в DBO, и только потом движок загружает ее в свою память и отображает в редакторе. По этой причине программа подвисает при выборе некоторых компонентов. Они много весят, и конвертеру нужно больше времени, чтобы перегнать модель в нужный формат.
Когда мы в следующий раз выберем этот же объект, программа уже не будет обращать внимания на X, и сразу же будет использовать DBO.

Теперь, что касается BIN файла. Грубо говоря, это тот же FPE с характеристиками объекта, но закодированный в другой формат. Аналогично вышеописанной ситуации, конструктор будет игнорировать FPE, если уже имеется BIN.

Поэтому очень важно удалять эти файлы перед тестом, если вы вносили какие-либо изменения в модель или FPE файл, в противном случае разницы во время теста вы не увидите.
Лучше всего для этого подходит специальная утилита FPSC-Cleaner.

С предназначением файлов мы разобрались, но на этом их роль, к сожалению не заканчивается.
И чтобы понять, в чем же еще дело, нам придется заглянуть чуть глубже в устройство движка, и разобраться, как вообще устроен уровень..

Когда вы скомпилировали свою игру загляните в папку levelbank.
В ней вы обнаружите ZIP архивы с названием level1, level2 и т.д.
Да, это созданные вами уровни запаковынные в архивы, и защищенные паролем, чтобы никто не мог что-то вытащить оттуда. Пароль к этим архивам: mypassword.
На самом деле вытаскивать оттуда по сути нечего, поскольку имеющиеся там файлы непригодны для использования где-либо вне конкретной игры.
Если вы обратите внимание на имеющиеся папки в готовой сборке, то заметите, что там отсутствует папка segments. Нет ее там потому, что все сегменты были перекодированы в одну единую огромную модель, и лежит она в том самом ZIP архиве под названием universe.dbo.
Да, программа снова сконвертировала все наши модели. Если мы откроем этот файл во все той же fragMOTION, то увидим любопытную картину, где помимо сегментов оказывается есть еще и ентити.
Другими словами, конструктор берет всю статическую геометрию на уровне, конвертирует ее в один большой файл, и в дальнейшем работает непосредственно с ним.



Также в папке levelbank рядом с архивами можно обнаружить еще и папку testlevel.
Поначалу можно подумать, что она не нужна, и это просто остаточные файлы из конструктора, но это не так. Вы можете удалить её, но после первой же загрузки любого уровня она снова появится.
Суть здесь в том, что каждый раз при запуске определенного уровня в игре, он распаковывается из соответствующего ZIP архива непосредственно в папку testlevel, и уже с этими файлами работает движок.
То есть, в этой папке находится весь собранный уровень из сегментов и статических ентити в виде одной 3D модели, карты освещения, файл для обработки физики, и еще дополнительные файлы для обработки порталов (отсечения из видеопамяти тех объектов, которые находятся вне поля зрения).

А теперь пройдем в папку entitybank нашей готовой игры, и обнаружим, что там как обычно лежат все наши модельки в формате DBO. И тут следует резонный вопрос — а зачем?
Самые сообразительные сейчас могли догадаться, к чему я веду.
Как я и написал выше, все статические ентити уже находятся в том самом файле universe.dbo, и если движок достает его из архива при загрузке, тогда зачем эти модели лежат еще и в entitybank?
После многочисленных тестов я выяснил, что модели из entitybank действительно загружаются в память при запуске уровня. Но самое интересное, что если их удалить, то игра все равно успешно запустится, и все будет отлично.
Более того, частота кадров значительно повысится.

Нет, это не значит, что можно полностью удалить папку entitybank.
Файл universe.dbo хранит только статику. Динамические компоненты, а также текстуры движок берет именно из этой папки.
Если вы удалите динамическую модель, или ее текстуру, уровень успешно загрузится, но объекта там не будет.
А вот удаление статической геометрии способно повысить частоту кадров практически в два раза. Также, вместе с этим, загрузка уровня будет происходить в среднем на 10 секунд быстрее. Это еще одно очень большое упущение разработчиков, которое, к сожалению, мне удалось обнаружить только сейчас.



Я провел не один месяц тестируя все, что только можно, пытаясь понять, почему мой уровень выдает 25-30 кадров, а иногда и еще меньше. Огромное количество бессонных ночей ковыряния в конструкторе с порой совершенно абсурдными догадками. Я уверен, что нашел не все косяки, но устранив эти два, что я описал, мой уровень стал выдавать уверенные 79-80fps, хотя визуально ничего не поменялось.



Подведем итог:
— не использовать fragMOTION для создания динамических моделей с костями (анимацией)
— удалять BIN и DBO файлы статических моделей из готовой игры

Дабы было проще удалять ненужные файлы, на этапе разработки рекомендую динамические ентити помещать в одну отдельную папку, чтобы потом не перебирать все подряд.

Теперь о порталах: сегменты в FPSC работают по такому принципу, где все, что находится за стеной, отсекается из видеопамяти, тем самым улучшая производительность и облегчая работу движку. Чтобы эти порталы работали корректно, необходимо проектировать уровни таким образом, чтобы завернув за угол все невидимое игроку скрылось. Для правильной работы портала отдельно взятые комнаты или любые участки на карте должны иметь пол, стены и потолок, а между самими комнатами должно быть так называемое горлышко, условный коридор, проходя через который территория оставленная позади будет скрыта. Размер комнат при этом может быть любой, а стены могут быть невидимыми. Более подробно разобрать эту тему постараюсь в следующей статье.

Ну, и, конечно же, следите за размером текстур и моделей.
Старайтесь не использовать текстуры с разрешением выше 1024х1024. В редких случаях можно 2048х2048. Текстура не должна содержать MipMap'ы, поскольку конструктор их не поддерживает.
Аналогично и с 3D моделями. Больше 5.000 полигонов у динамического компонента начнет вызывать осложнения в движке, так как ему сложнее будет обрабатывать физику и пр.
Также необходимо следить за общим счетчиком полигонов, чтобы одновременно в поле зрения не было больше 100.000, иначе могут возникнуть проблемы.
Если вы используете SketchUp для моделирования, тогда откажитесь от плагина, что позволяет экспортировать в Х. Он очень кривой и движку аналогично сложно обрабатывать эти файлы.
Лучшим решением будет сохранить в 3DS, открыть в 3DMax или Blender, и уже там экспортировать в Х.

Еще раз напомню, что установка Black Ice Mod категорически обязательна, поскольку там решены многие проблемы с памятью и скоростью загрузки.
На этом пока всё.

Все вопросы по теме в комментарии. Также пишите, о чем еще следует написать.
Удачи!

Эта статья была полезной? Не забудь повысить репутацию 5wee†!