Падение производительности системы частиц Cocos2d-x с версии 1.x до 2.x

мы хотим изменить нашу базовую систему с Cocos2d-x 1.0 (Qt Port 0.6) на Cocos2d-x 2.0 (Qt Port 1.0), но есть несколько задач, которые необходимо протестировать перед изменением системы. Одной из таких задач является производительность системы частиц. Помните, что при увеличении производительности с 1,0 до 2,0 производительность возрастет, мы обнаружили обратное. Версия 1.0, кажется, работает намного лучше, чем Версия 2.0. Теперь мы хотели бы выяснить, может ли это быть правильным или нет, и, надеюсь, кто-то может дать нам подсказку, что мы можем пропустить (неправильные настройки Cocos2d-x, неправильные настройки, …).

Чтобы проверить производительность, мы создали простой тестовый сценарий: использование одной системы частиц, которую можно добавлять несколько раз при нажатии на сцену. Эта система частиц использует текстуры разного размера (4x4px и 32x32px) и Quad Particle System.

Основой теста является HelloWorld, пример Cocos2d-x. Кроме того, мы включили сенсорный приемник, создали пакет (при необходимости), преобразовали метку в счетчик и добавили процедуру вставки системы частиц. Исходный код и ресурсы прилагаются в виде ссылки на ZIP-архив ниже.

Мы сравнили версию Cocos2d-x для Linux и версию Cocos2d-x для Qt (MeeGo Harmattan). Результаты теста можно найти в листе Excel http://www.fantasyhaze.com/sof/Particle_Performance_Tests.ods. В каждом тестовом случае версия 1.0 была более эффективной, чем 2.0. В каждом тестовом случае система пакетированных частиц имела те же характеристики, что и система пакетных частиц из Cocos2d-x 2.0. Производительность была измерена в FPS / Particle Systems.

Результаты:

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

Следовательно, падение производительности в целом может происходить не только из-за графической стороны, но и из-за высокой загрузки ЦП (вычисление положений частиц в каждом кадре для тысяч частиц, т. Е. 47 систем частиц с 350 частицами создают полезную нагрузку 47 * 350 = 16450 частиц, которые необходимо пересчитывать каждый кадр). При использовании пакетированных частиц это также самое большое количество частиц, которое можно использовать, потому что функция рисования GL использует короткое значение без знака, которое достигается с 16450 частицами. 16450 * 4 (вершины) = 65800 (ushort = 65535). Это можно увидеть (на скриншотах), когда на настольном компьютере используются пакетные частицы и отдельные частицы. После добавления 47 частиц в пакет, он перестанет отображать новые эффекты. Когда добавлено больше эффектов, производительность все еще продолжает снижаться, что показывает, что потеря производительности в основном связана со стороной процессора, а не с графическим процессором. Это также может быть замечено при использовании текстур 4x4px вместо 32x32px только около 10 дополнительных эффектов (на рабочем столе).

Похожие темы:

Таблицу исключений, скриншоты и исходный код можно найти в архиве — http://www.fantasyhaze.com/sof/Particle_Perfromance_Tests.zip
http://www.fantasyhaze.com/sof/Particle_Perfromance_Tests.ods

2

Решение

Задача ещё не решена.

Другие решения

Других решений пока нет …