Как оптимизировать 2D игру?

[kripto289]

1. такой код дал прирост производительности этого метода примерно в 5 раз (было 0.16-0.2мс, стало 0.02-0.04мс)

Я вас умоляю, экономия на спичках.

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

В 5 юнити можно двигать статик коллайдеры без потерь. http://blogs.unity3d.com/ru/2014/07/08/high-performance-physics-in-unity-5/

2. У вас вообще не работает батчинг, нужно объединять все спрайты в атлас, разделать на отдельные при помощи этого
http://docs.unity3d.com/ru/current/Manual/SpriteEditor.html

Я не видел его проект в глаза, но уверен что это тоже из ряда "экономии на спичках".

Нужно качать adreno profiler, и смотреть загружен ли gpu и чем именно. Вырубать тени если есть, менять шейдеры на более простые, поставить multithreading в настройках билда андроида (это вообще даёт прирост огромный прирост фпс), вырубить vsynq если хочется убрать фпс лимит.
Скажу, что на adreno 305 тестил свои сценки. Несмотря на ущербность gpu, у меня в сценке бегали 20 юнитов, 40 выстрелов и 10 турелек с 30 фпс. Так что 2д (если конечно не 500 спрайтов) не должно лагать даже в кривых руках.

[kripto289]

P.S. Это нормально, что в Stats сколько было FPS при 42 DC, столько и осталось пр 9 DC (70-75 FPS).

Да потому что все разрабы слепо начитаются гайдов "уменьшайте Draw call" и всеми силами жопу рвут ради этого. А на деле, эти гайды были написаны лет 7 назад, когда мобилки были тормознутые донельзя. Сейчас пропускная способность у шины cpu/gpu в мобилках не является узким горлышком. Проверено на poverVr 544mp2, спокойно держит 500 drawcalls.
Поэтому и никакого профита это не дало, только время потратили на ненужную оптимизацию

Ах да, "WaitForTargetFPS" в первом посте это вертикальная синхронизация (настройки editor->quality -> vsynq).

[DbIMok]

если конечно не 500 спрайтов

спокойно держит 500 drawcalls

в чем разница?

[kripto289]

если конечно не 500 спрайтов

спокойно держит 500 drawcalls

в чем разница?

В том что это не эквивалентно.
Я например могу сделать 500 отдельных спрайтов с 500 dk, или 500 спрайтов с атласом и 1 dk. Но если шейдер будет не opaque, например additive или transparent, то один только оверхед сожрёт всё фпс. Даже без оверхеда, на 4к разрешениях мобилок, уже будет колоссальная нагрузка на пиксельный блок шейдера.
То есть разница в том, что графика не из одних draw calls состоит. Есть ещё скрипты, полигонаж и шейдеры, которые вносят свой вклад в отрисовку. И оптимизировать drawcalls глупая затея, когда например в твоей сцене 90% времени отдъедает анимация, или вертексная/пиксельная нагрузка шейдера.

[DbIMok]

могу сделать 500 отдельных спрайтов с 500 dk, или 500 спрайтов с атласом и 1 dk

при этом 500 спрайтов плохо, а 500 дк не страшно? так и не понял логики. или 500 спрайтов с 500 дк - хорошо, 500 спрайтов, 1 дк - плохо?

например additive или transparent

чем они отличаются, что в них плохого?

один только оверхед сожрёт всё фпс

что такое оверхед и как он связан с вышеназванными шейдерами?
какой вклад в отрисовку вносят скрипты?

[DualPain]

В 5 юнити можно двигать статик коллайдеры без потерь. http://blogs.unity3d.com/ru/2014/07/08/high-performance-physics-in-unity-5/

Как показал мой тест, без потерь нельзя, во всяком случае не в этом месте, производительность реально выше с динамик колайдерами и риджит боди.
Уменьшиние дк это обязательная процедура, тем более, если она делается в пару кликов и дает колосальную разницу.
Я не сказал что это единственные способы оптимизировать этот проект, описал первое что бросилось в глаза.

[kripto289]

могу сделать 500 отдельных спрайтов с 500 dk, или 500 спрайтов с атласом и 1 dk

при этом 500 спрайтов плохо, а 500 дк не страшно? так и не понял логики. или 500 спрайтов с 500 дк - хорошо, 500 спрайтов, 1 дк - плохо?

Вы попробуйте на сцену поставить 500 спрайтов занимающих хотя бы 10% экрана в сумме, но с Additive шейдером. Гляньте фпс
Плохо ориентироваться только на одни dk. 1 дк лучше 500, но не панацея. Например открываю стор и вижу какие-нибудь эффекты или вода в 1 drawcall, типо это огромное преимущество. Спрашивается для чего? Когда эта вода жрёт 95% фпс только за счёт пиксельного шейдера, и будь она хоть 1 dk, хоть 100, фпс бы не изменился.

например additive или transparent

чем они отличаются, что в них плохого?

Я просто привёл пример прозрачных шейдеров. На уровне рендера, оба рассчитываются в отдельном проходе (вместо opaque геометрии). Разница в смешении и коде шейдера.
Плохо именно overhead от них.

один только оверхед сожрёт всё фпс

что такое оверхед и как он связан с вышеназванными шейдерами?

Если наложить 500 спрайтов с opaque шейдером (которые занимают весь экран например 800*600) друг на друга, то отрисовываться будет только 1 спрайт (потому что остальные перекрыты, и пиксели отбрасываются). То есть отрисовывается 800*600 пикселей.
Если же использовать прозрачные шейдеры, то все 500 спрайтов будут отрисовываться. Нагрузка в 500 раз больше. (примерные цифры). То есть пиксельный шейдер будет исполнятся не 800*600 раз, а 800*600*500 за 1 фрейм.
Наглядный пример, как всего лишь замена шейдера может дать прирост в сотни раз, и draw calls тут вообще погоды почти не сделают.

[kripto289]

В 5 юнити можно двигать статик коллайдеры без потерь. http://blogs.unity3d.com/ru/2014/07/08/high-performance-physics-in-unity-5/

Уменьшиние дк это обязательная процедура, тем более, если она делается в пару кликов и дает колосальную разницу.
Я не сказал что это единственные способы оптимизировать этот проект, описал первое что бросилось в глаза.

Обязательная процедура это если этих dk на сцене 1к. Господи, да даже самая древняя мобилка не захлебнётся от 50 dk. Куда ещё то оптимизировать

[kodekq]

У меня в камере около 100 статичных спрайтов, всё расфасовано по атласам, DC 10-20, но при этом когда камера движется картинка дёрганная, профайлер показывает что рывки просиходят в момент подскакивания WaitTargetFPS и Overhead. Первое насколько я знаю это vsync, но при его отключении картинка рвётся, поэтому отключать его не вариант. Пойдём дальше, overhead пытаюсь победить уже который день, один из вариантов почему он лезет, это перебор с батчингом, т.к. в гайде сказано что на него требуется время, которое как раз таки суммируется в overhead, тогда получается что уменьшать DC иногда и вредно? Второй вариант как раз таки описан выше, но что делать если у меня спрайты имеют альфа канал и я не могу использовать opaque шейдер?

[i_am_kisly]

Написать свой шейдер ?

[kripto289]

У меня в камере около 100 статичных спрайтов, всё расфасовано по атласам, DC 10-20, но при этом когда камера движется картинка дёрганная, профайлер показывает что рывки просиходят в момент подскакивания WaitTargetFPS и Overhead. Первое насколько я знаю это vsync, но при его отключении картинка рвётся, поэтому отключать его не вариант. Пойдём дальше, overhead пытаюсь победить уже который день, один из вариантов почему он лезет, это перебор с батчингом, т.к. в гайде сказано что на него требуется время, которое как раз таки суммируется в overhead, тогда получается что уменьшать DC иногда и вредно? Второй вариант как раз таки описан выше, но что делать если у меня спрайты имеют альфа канал и я не могу использовать opaque шейдер?

WaitTargetFPS - это не вертикальная синхронизация. Этот метод показывает, что процессор простаивает, то есть не делает ничего полезного. А уж каким образом его заставили остановиться это другой вопрос. Если руками остановили - это вертикальная синхронизация. Но если видеокарта тормозит, то уже она остановит просчёт cpu.
Это значит, что WaitTargetFPS при выключенном vsinc показывает тормознутость видеокарты.
Оверхед - это перекрытие прозрачных объектов. Что это и почему плохо? Потому что в opaque режиме, невидимые пиксели отбрасываются и не нагружают шейдерный блок видеокарты. Если режим смешивания alpha, то пиксели не отбрасываются, даже если они невидны (alpha = 0). Можно попытаться использовать шейдеры cutout. Там хотя бы прозрачные участки будут отбрасываться. (alpha < 0.01). Но всё равно, если будет 100 объектов перекрытых, то это то же самое что отрисовка всех 100 объектов одновременно. В opaue режиме всегда(!) кол-во пикселей на экране и кол-во пикселей которые отрисовывает шейдер одинаковое. В прозрачном режиме, шейдер может рисовать в бесконечно раз больше.
Вывод. Используйте другой шейдер, либо меняйте кол-во объектов на сцене.

[KBEP]

Не overhead, а overdraw. Overhead - это накладные расходы, на вызов функции, например. Просто поправил

[i_am_kisly]

оверхед - это в принципе избыток над пользовательской информацией.

[Merklar]

Я так понимаю у вас GameManager - используется как Синглтон. В таком случае очень не дешевая операция в каждом кадре лезть в GameManager.Instance. Лучше сделать это оповещением, когда theEnd стало true

[DualPain]

Я так понимаю у вас GameManager - используется как Синглтон. В таком случае очень не дешевая операция в каждом кадре лезть в GameManager.Instance. Лучше сделать это оповещением, когда theEnd стало true

экономия на спичках