Повышение производительности проектов Construct 2

мобильный

Современные настольные компьютеры являются очень мощными. Как правило , основная проблема с производительностью получает вашу игру , чтобы хорошо работать на мобильные телефоны и планшеты. Это более трудно получить хорошую производительность на этих устройствах , потому что они часто имеют гораздо более слабое аппаратное обеспечение: медленные процессоры, более медленные графические чипы, и меньше памяти - часто в 10 раз и более по сравнению с настольным компьютером.

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

Следующие советы могут помочь вам достичь максимальной производительности для мобильных устройств:
Убедитесь , что WebGL включен , так как на устройствах , которые поддерживают его, как правило , значительно повышает производительность.
Избегайте использования слишком много объектов или частиц , так как мобильные устройства имеют более низкие пределы того , что настольные компьютеры могут обрабатывать.
Место объекты , используя одни и те же режимы наложения или эффекты на одном слое. Например, если у вас есть много объектов с использованием присадок режим наложения (обычно используется для взрывов, лазеров и других эффектов), убедитесь , что все эти объекты расположены на отдельном слое. Также убедитесь , что они созданы на этом слое , если объекты порождаются или созданные во время выполнения. Переключение между эффектами может привести к снижению производительности, и делает это гарантирует , что все объекты , которые используют один и тот же эффект нарисованы в то же время. Это описано более подробно в блоге , как работает Construct 2 WebGL визуализатор .
Избегайте объектов с большими площадями прозрачности. Прозрачные пиксели все еще занимают время рендеринга, даже если они не появляются визуально. Обрежьте все изображения, используемые для устранения расточительного прозрачное пространство. (Shift + Crop в редакторе анимации будет обрезать всю анимацию.) Дроблению крупных объектов с большими прозрачными областями , чтобы ряд более мелких объектов также может повысить производительность рендеринга и экономии памяти. Например, добавление границы окна с помощью экрана размером прозрачный спрайт с границами нарисованных по краям будут выполнять плохо , как она до сих пор , чтобы заполнить большую прозрачную область в середине; разделив ее на четыре отдельные объекты для каждого ребра является гораздо более эффективным.
Избегайте больших площадей перекрытия между объектами. Визуализатор работает спина к фронту, а если объекты имеют много перекрытия, перекрывающее область будет иметь пиксели , оказываемые снова и снова. Это может использовать до скорости заполнения емкости мобильного GPU довольно быстро.
Если у вас есть непрозрачный фон, установить Clear фон для Нет в свойствах проекта. Это позволит избежать избыточно очистки весь экран каждый кадр , когда он будет очищен так или иначе рендерингом непрозрачный фон.
Общие причины плохой работы

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

Нет аппаратного ускорения
Обычно даже медленнее Canvas 2D визуализации до сих пор аппаратное ускорение с помощью GPU (Graphics Processing Unit). Однако некоторые устройства имеют нестабильные драйверы графической подсистемы и производители браузеров отключить использование графического процессора , чтобы избежать аварий ( так называемые "ГПУ" черный список). На очень старых устройствах ускорения GPU может не просто быть поддержаны. Смотрите ниже раздел о Определение GPU в Chrome черный список ниже для получения дополнительной информации.

Изменение текстовых объектов каждый тик
Изменение размера или текст текстового объекта каждый тик - даже просто для анимации или перехода - скорее всего , обеспечить высокое быстродействие, особенно на мобильных устройствах. Проблема в том , что еще хуже , если текстовый объект велик. Рендеринг текста очень быстро до тех пор , пока объект не меняется, но при смене объекта должен сделать относительно дорогой перерисовки текста и замены кешированной текстуры. Попробуйте использовать небольшие текстовые объекты , которые регулярно не изменяются. Если вам необходимо регулярно менять текст, рекомендуется использовать Sprite Font вместо, который быстро , даже когда она меняется каждый тик.

Несоответствующий использование объекта Tilemap
не уместно использовать объект Tilemap для отображения больших изображений. Объект tilemap рисует плитку по-плитку, но можно оптимизировать , если есть области той же плитки. Это описано в блоге Tilemap лакомых кусочков . Если вставить большое изображение , чтобы объект Tilemap, а затем штамповать сетку плитки , чтобы отобразить увеличенное изображение, каждая плитка отличается. Поэтому никакая оптимизация не возможна, и вызов Жеребьевка должна быть выдана для каждой плитки. Если изображение нуждается в 10x10 сетки плитки для отображения, то ему нужно будет выдавать 100 вызовов отрисовки. Один спрайт или плиточный фон, путем сравнения, принимает один раздаточный вызов каждый. Поэтому этот тип использования объекта Tilemap может быть в сотни раз менее эффективно , чем использование другого объекта. Объект Tilemap следует использовать только для плитки на основе игр, где одна плитка является дизайн уровня блок полезен сам по себе, а не частью более крупного изображения.

Слишком много объектов с помощью физики поведение физики очень ресурсоемкие. Использование слишком большого количества объектов с поведением физики может вызвать значительное замедление. Вы должны создавать свои игры , чтобы использовать несколько крупных объектов : Физика , а не множество мелких объектов физики.


Создание слишком большого количества объектов
В то время как современные компьютеры очень быстро, они по- прежнему имеют ограниченные возможности обработки. Создание более 1000 объектов, вероятно , вызовет вашу игру , чтобы замедлить. Попробуйте разработать свою игру , чтобы использовать меньшее количество объектов. Система экспрессии objectcount может сказать вам , сколько объектов вы используете.

Использование слишком большого количества эффектов
Эффекты визуально впечатляет, но может замедлить производительность игры значительно , если используется чрезмерно, особенно на мобильных устройствах. Использование эффекта на объектах с большим количеством экземпляров особенно медленно - зачастую гораздо более эффективно разместить все объекты с влиянием на их собственном слое, а затем применить эффект к этому слою вместо этого. Это позволяет эффект обрабатывать все за один раз, вместо того , чтобы нерационально повторно запустить эффект для небольшого объекта снова и снова. Некоторые эффекты также имеют больше влияния на производительность , чем другие: размывает и пылает , как правило, самый медленный, искажение , имеющее среднее воздействие, а цвет смеси (например , умножить и экран ) , являющийся самым простым для GPU для обработки.

Ненужное использование эффектов
Никогда не использовать эффекты для обработки статического эффекта на объект. Например, не используйте "Оттенки серого" эффект , чтобы сделать объект всегда появляются в оттенках серого. Это позволит снизить производительность , когда вы могли бы просто импортировать изображения с оттенками серого объекта и не использовать какие - либо эффекты вообще.

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


Использование спрайтов вместо бесшовного фона
Создание слишком много объектов может привести к замедлению работы , и распространенная ошибка заключается в использовании сеток объектов Sprite вместо Плиточные фоновых объектов . Это похоже на использование tilemaps неадекватно. Например, 20x20 сетка спрайтов имеет 400 объектов, что является значительное влияние на счет объекта. Один плиточный фон может заменить сетку спрайтов и он рассчитывает только как единый объект. Плиточные фоны специально оптимизированы для повторения их текстуру так что в данном случае речь идет буквально в 400 раз эффективнее , чем сетка спрайтов. Всегда используйте бесшовного фона вместо того чтобы повторять спрайтов , где это возможно.

Не размещать все используемые объекты в макете
Если объекты не помещаются в макете , но создаются события, Construct 2 будет загружать текстуры для этих объектов момент их создания. Это может привести к кратковременному паузу или "Jank" и сделать игру чувствовать себя менее отзывчивым. Этого можно избежать путем размещения каких - либо используемые объекты в макете. Они могут быть размещены за пределами экрана и уничтожены при запуске , чтобы избежать вмешательства в игровой процесс. Затем Построить 2 подожмем все свои текстуры при запуске макета, избегая любого "Jank" , как они создаются и уничтожаются во время выполнения.

Использование слишком большого количества петель
Это встречается реже, но с использованием слишком много петель , как For , для каждого и повтора может привести к игре , чтобы замедлить. Вложенные циклы, особенно вероятно , чтобы вызвать это. Для того, чтобы проверить , если это проблема, попробуйте временно отключить циклических событий.
Распространенные заблуждения

Следующие вещи часто обвиняют в том, влияющим на производительность (как, частота кадров во время выполнения), но, вероятно, имеют мало или вообще никакого эффекта:

Объекты Закадровая являются не все еще отображается. Построить 2 не выдает рисовать вызовы для объектов , которые не отображаются в окне, и графический процессор также достаточно умен , чтобы знать , чтобы не оказывать любое содержание , которое выходит за пределы окна - даже тогда , когда одно изображение лишь частично на экране.

Форматы изображений (например , JPEG, PNG-8, PNG-32) влияет на размер загружаемого файла , но не оказывают никакого влияния на производительность во время выполнения или использования памяти (все они распакованы до 32-битного растрового изображения при запуске).

Аудио форматы также влияют только на размер загружаемого файла , но не оказывают никакого влияния на производительность во время выполнения.

Количество слоев , как правило , не имеет никакого эффекта, если большинство слоев не изменили их непрозрачность, имеют эффекты , применяемые, имеют режим наложения , отличный от "Normal", или использовать 'заставить собственную текстуру. Тем не менее , как правило , не влияет на производительность с помощью нескольких слоев с настройками по умолчанию.

Количество макетов также вряд ли будет иметь какой - либо эффект, отличный от размера загрузки. Размер макета также не имеет никакого прямого эффекта; большие макеты не использовать больше памяти или требует дальнейшей переработки, если вы не используете больше объектов.

Угол или непрозрачности спрайтов / плиточных фонов и с плавающей точкой позиции (например , позиционирование спрайт при X = 10,5) , вообще не имеет никакого эффекта, так как современные графические чипы очень хорошо справляется с этим, даже на мобильные телефоны. Очень большие спрайты могут все еще замедлить мобильные устройства, но и на рабочем столе они часто могут по- прежнему оказываться столь же быстро , как меньшие спрайтов.
Дополнительные советы

Для получения дополнительной информации и рекомендаций по производительности, увидеть сообщение в блоге Оптимизация: не тратьте свое время . Есть также несколько полезных советов о сохранности ваших событий эффективным в блоге пост Common MIS-используемых событий и подводных камней .
Измерения и испытания производительности

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

Проверьте свой проект на любом количестве устройств и браузеров, как это возможно.

Если вы думаете , что - то вызывает проблемы с производительностью в вашем проекте, это, как правило , легко проверить теорию: создать резервную копию проекта, удалите предмет о котором идет речь, и посмотреть , если фреймрейт улучшилось. Если она улучшается, что вы удалили была причина; если нет, то это должно быть что - то еще. В качестве альтернативы следует использовать вкладку профилировщика отладчика , чтобы увидеть , если непропорционально большое количество процессорного времени тратится в одной области игры.

Всегда измерения производительности. Компьютерные системы являются очень сложными, и есть много неожиданных или нелогичным результаты в производительности. Только способ узнать , какой эффект имеет что - то на производительность , чтобы измерить его . Если вы не можете измерить разницу, он , вероятно , не имеет никакого серьезного влияния на производительность.
Как измерить производительность

Лучший способ увидеть разбивку , какие части игры используют процессорное время, чтобы посмотреть на вкладке Профили отладчика . Если игра упираются на рендеринг логики , а не GPU CPU, то это должно помочь вам быстро определить ту часть проекта, которая использует большую часть времени процессора.

Есть три системы выражения , которые также важны для индикации производительности:

кадров в секунду - возвращает текущие кадров в секунду. Обычно максимальная скорость составляет 60 кадров в секунду, но она может меняться в зависимости от системы.

cpuutilisation - возвращает текущую оценочную использование главного потока Javascript. Это приближение , сколько доступного процессорного времени для обработки Javascript используется. Она варьируется от 0 до 1, поэтому выражение раунд (cpuutilisation * 100) будет возвращать процент. Несмотря на свое название это не сообщает общее использование системы центрального процессора, и может быть неточным , так как это оценка производится из временных измерений в Javascript, поэтому не слишком сильно полагаться на него.

визуализатор - возвращает либо canvas2d или WebGL в зависимости от средства визуализации в использовании. WebGL визуализатор, как правило , значительно быстрее , чем Canvas2D, но только если браузер поддерживает его и не занесен в черный список ГПУ. Для получения дополнительной информации см Technology раздел.

Вы можете создать дисплей в игре этих значений с текстового объекта , чтобы держать глаза на производительность во время тестирования вашей игры, используя одно из следующих действий , чтобы обновить его Каждый тик :

Набор текста в кадр и "FPS" и круглые (cpuutilisation * 100) и "% CPU (" & рендерер & ")"

Это отображается строка как 60 FPS, 30% CPU (WebGL) , указывающий на частоту кадров, приблизительное время процессора и средства визуализации.
Определение GPU в черный список Chrome

Одной из наиболее распространенных причин низкой производительности является поддержка GPU выключению из-за неустойчивых водителей. Это приводит к тому, игра вернуться к разработке программного рендеринга, которые могут искалечить производительность на низких конечных устройств. Браузер Google Chrome обеспечивает некоторые диагностики, которые можно использовать, чтобы проверить это на Windows, Mac, Linux и Android устройств.
Статус Аппаратное ускорение

Для просмотра , какие функции аппаратного ускорения в Chrome, посетите хром: // графического процессора через адресную строку. Под Graphics Feature Status вы должны быть в состоянии увидеть ли Canvas (The canvas2d визуализатор) и WebGL аппаратное ускорение. Он должен сказать , аппаратное ускорение в зеленый цвет , если да, то в противном случае программное обеспечение только или аналогичное сообщение об аппаратном ускорении, отключенный в оранжевый или красный.

Аппаратное ускорение WebGL обеспечит наилучшую производительность. Если WebGL не аппаратное ускорение, но Холст, производительность все равно должны быть хорошими. Если даже не Холст аппаратное ускорение, производительность, вероятно, будет беден на этом устройстве.

Примечание производители браузеров сохраняют свои черные списки отдельно. Просто потому, что Chrome не использует аппаратное ускорение не означает, что другие браузеры последуют этому примеру. Переключение в качестве альтернативы, как Firefox может обеспечить лучшую производительность, если он может использовать ускорение GPU.
Принуждение аппаратное ускорение включено

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

Чтобы заставить аппаратное ускорение включен в Chrome, посетите хром: // флаги через адресную строку. В верхней должен быть пункт под названием Override списка программного рендеринга . Нажмите Включить . Обратите внимание , что ваши изменения не вступят в силу до тех пор , пока нажмите Перезапустить кнопку , которая появляется в нижней части экрана после изменения параметра.



После перезапуска, устройство должно быть в состоянии в полной мере использовать ускорение GPU, в том числе с поддержкой WebGL. Это позволяет тестировать реалистичные аппаратные возможности устройства, не страдая из-за низкой производительности в черный список.