-
Автор темы
- #1
В этом посте собранно несколько советов, которые новички (а может и некоторые продвинутые) часто не знают или забывают при работе с блюпринтами.
Эти советы могут легко увеличить фпс в игре в несколько раз не прибегая к оптимизации графики, настройке лодов и всего прочего. Здесь только про блюпринты.
Первое и пожалуй самое основное - используй как можно меньше кастов!
Касты тратят очень много ресурсов из-за чего игра будет работать гораздо медленнее, так же это часто может стать причиной фризов.
Лучшее что можно сделать, это провести все касты в начале логики (на begin play или event construct) или же до неё начала если это виджет блиюпринт (event pre construct) а потом записать результат каста в переменную, которую потом использовать по необходимости. Если есть вариант обойтись без каста, то им лучше всего воспользоваться.
Пример сохранения результата каста в переменную и дальнейшего использование переменной (кэширование)
Совет №2. Не выстраивай логику на основе event tick. Event tick вызывается каждый кадр (К примеру если у игрока 40 фпс, то логика будет вызываться 40 раз в секунду) из-за этого повторение большой логики многократно, будет сильно нагружает пк, да и небольшая логика тоже пару фпс вполне может съесть. Помимо этого и сама логика привязанная к event tick'у может работать по разному у разных пользователей, ведь у кого-то 30 фпс и логика вызывается 30 раз в секунду, а у кого-то 60 фпс и логика соответственно будет вызываться вдвое чаще. Для решения этой проблемы в блюпринте можно выставить Tick interval, тогда зависимости от фпс не будет, но производительность всё равно страдать не перестанет.
Лучшее решение проблемы - это заменить использование event tick на таймеры и таймлайны.
Пример использования таймлайна
Ну и напоследок довольно очевидная вещь про которую я почему-то узнал достаточно поздно - это нода switch. Если вы всё ещё делайте многократные проверки через branch, то лучше использовать switch. Нода "Switch" проверяет полученную информацию (как правило это int, string или значение из enum таблицы) и выполняет последующую логику в зависимости от полученного значения. Помимо оптимизированности, её использование сильно упрощает работу и помогает избежать большого количества проверок. Особенно хорош switch при использовании enum таблиц.
Пример использования ноды switch on int
Лично мне эти советы помогли увеличить фпс примерно в 4- 5 раза и избавиться от фризов, но для полной оптимизации проекта этого может не хватать. Если вам так же интересны темы оптимизации моделей и интерфейса, то я буду рад рассказать о них.
Спасибо за прочтение и удачи в разработке!
Эти советы могут легко увеличить фпс в игре в несколько раз не прибегая к оптимизации графики, настройке лодов и всего прочего. Здесь только про блюпринты.
Первое и пожалуй самое основное - используй как можно меньше кастов!
Касты тратят очень много ресурсов из-за чего игра будет работать гораздо медленнее, так же это часто может стать причиной фризов.
Лучшее что можно сделать, это провести все касты в начале логики (на begin play или event construct) или же до неё начала если это виджет блиюпринт (event pre construct) а потом записать результат каста в переменную, которую потом использовать по необходимости. Если есть вариант обойтись без каста, то им лучше всего воспользоваться.
Пример сохранения результата каста в переменную и дальнейшего использование переменной (кэширование)
Совет №2. Не выстраивай логику на основе event tick. Event tick вызывается каждый кадр (К примеру если у игрока 40 фпс, то логика будет вызываться 40 раз в секунду) из-за этого повторение большой логики многократно, будет сильно нагружает пк, да и небольшая логика тоже пару фпс вполне может съесть. Помимо этого и сама логика привязанная к event tick'у может работать по разному у разных пользователей, ведь у кого-то 30 фпс и логика вызывается 30 раз в секунду, а у кого-то 60 фпс и логика соответственно будет вызываться вдвое чаще. Для решения этой проблемы в блюпринте можно выставить Tick interval, тогда зависимости от фпс не будет, но производительность всё равно страдать не перестанет.
Лучшее решение проблемы - это заменить использование event tick на таймеры и таймлайны.
Пример использования таймлайна
Ну и напоследок довольно очевидная вещь про которую я почему-то узнал достаточно поздно - это нода switch. Если вы всё ещё делайте многократные проверки через branch, то лучше использовать switch. Нода "Switch" проверяет полученную информацию (как правило это int, string или значение из enum таблицы) и выполняет последующую логику в зависимости от полученного значения. Помимо оптимизированности, её использование сильно упрощает работу и помогает избежать большого количества проверок. Особенно хорош switch при использовании enum таблиц.
Пример использования ноды switch on int
Лично мне эти советы помогли увеличить фпс примерно в 4- 5 раза и избавиться от фризов, но для полной оптимизации проекта этого может не хватать. Если вам так же интересны темы оптимизации моделей и интерфейса, то я буду рад рассказать о них.
Спасибо за прочтение и удачи в разработке!
Последнее редактирование модератором:
