Комментарии 22
Есть ли у uGUI те же проблемы что у NGUI с производительностью? И решаются ли они так же как описано в статье?
C uGUI на самом деле всё ещё интересней. Советую обратиться к документу с Best Practices https://unity3d.com/learn/tutorials/topics/best-practices
Товарищ с последнего юнайта так же достаточно много времени уделяет проблемам и оптимизации uGUI https://www.youtube.com/watch?v=n-oZa4Fb12U
От себя скажу что хак с прокруткой листа в uGUI ещё больше в тему из-за особенностей построения батчей в канвасе
Товарищ с последнего юнайта так же достаточно много времени уделяет проблемам и оптимизации uGUI https://www.youtube.com/watch?v=n-oZa4Fb12U
От себя скажу что хак с прокруткой листа в uGUI ещё больше в тему из-за особенностей построения батчей в канвасе
Очень значительное улучшение производительности дает выключение PixelPerfect.
Значительно — это 20 раз разница на больших списках:
Значительно — это 20 раз разница на больших списках:
В статье речь про оптимизацию производительности, а не о решении проблем с какой-то конкретной системой. Поэтому в примере — несколько обобщённых примеров, которые можно обыграть в любом фреймворке.
Большое спасибо за статью, но хотелось бы отметить, то что не упомянуто в статье (во всяком случае я не заметил)
1) Правильно ли я понял про списки? — данный подход можно использовать, только если на Canvas (на котором находится список) стоит Render mode — World Space:
1.1) Если будет стоять Overlay — то там камера вообще ненужна, т.к рендер UI происходит и без нее
1.2) Если Camera — то все UI элементы будут двигаться в 3D пространстве вместе с камерой (оставляя в кадре тот элемент который и был ранее) — получается прокрутку не осуществить двигая камеру…
2) Для небольших списков есть лайфхак, во Viewport списка, замест компонента Mask, установить Rect Mask 2D. Повышает производительность на слабых девайсах примерно в 1.5-2 раза.
1) Правильно ли я понял про списки? — данный подход можно использовать, только если на Canvas (на котором находится список) стоит Render mode — World Space:
1.1) Если будет стоять Overlay — то там камера вообще ненужна, т.к рендер UI происходит и без нее
1.2) Если Camera — то все UI элементы будут двигаться в 3D пространстве вместе с камерой (оставляя в кадре тот элемент который и был ранее) — получается прокрутку не осуществить двигая камеру…
2) Для небольших списков есть лайфхак, во Viewport списка, замест компонента Mask, установить Rect Mask 2D. Повышает производительность на слабых девайсах примерно в 1.5-2 раза.
В статье речь об NGUI, в uGUI всё гораздо печальнее с производительностью.
Тогда в этом есть смысл) почему то перемкнуло что в пункте 2 про NGUI, в пункте 3 про UGUI (наверно сыграла ассоциация UI и Unity часто в контексте) — обычно данное словосочетание ассоциируется с UGUI (наверно у тех кто мало работал с NGUI и много с UGUI) — спасибо
Если рассматривать NGUI и UGUI «из коробки», то NGUI сильно проигрывает. Но, ввиду открытости последнего, в случае с NGUI у разработчика больше возможностей по оптимизации, всё упирается лишь в его скил. В то время как на стороне UGUI поддержка и гарантия развития.
По моим ощущениям, UGUI проигрывает, NGUI из коробки работает хорошо. С UGUI через какое-то время начинаются адовые тормоза, и не понятно почему так происходит. Потом ты набредаешь на статьи и видео где рассказывают что всё это время ты проектировал интерфейс неправильно. И что все те оптимизации которые по идее должны были срабатывать, не работали вовсе. Т.е. он сделан контринтуитивно в этом плане. Например все объекты на Canvas считаются будто-бы с прозрачностью, любое перемещение или изменение элемента на экране это практически всегда перестройка всего меша до Canvas (а он обычно один, никто не говорит что их надо делать побольше). Деактивированные объекты участвуют в создании меша (по крайней мере я об этом слышал из видео юнити разраба, может я его неправильно понял) и т.д. и т.п.
В этом плане NGUI хорош, делаешь как нибудь, а оно будет работать нормально, даже если ты специально об этом не заботишься. Хочешь сделать лучше, можно сделать понятные и очевидные оптимизации.
Ну и как бы оба движка, условно говоря, поставляются с исходниками. Но разобраться в логике работы UGUI весьма и весьма затруднительно. Всё это лишь, конечно же, мое мнение, основанное на довольно обширном опыте работы с обоими движками. Мой выбор NGUI.
В этом плане NGUI хорош, делаешь как нибудь, а оно будет работать нормально, даже если ты специально об этом не заботишься. Хочешь сделать лучше, можно сделать понятные и очевидные оптимизации.
Ну и как бы оба движка, условно говоря, поставляются с исходниками. Но разобраться в логике работы UGUI весьма и весьма затруднительно. Всё это лишь, конечно же, мое мнение, основанное на довольно обширном опыте работы с обоими движками. Мой выбор NGUI.
Согласен, что разобраться в логике работы UGUI не всегда просто ввиду того, что открыт он лишь частично. Честно говоря, никогда не было ситуации вроде «UGUI через какое-то время начинаются адовые тормоза», выпустили достаточно крупный проект в котором примерно 90% 2d контента и крайне «тяжелый» UI — проблем с производительностью относительно UGUI не было в принципе. На NGUI были «собраны» два не менее крупных проекта, в итоге, попробовав UGUI, единогласно решили полностью перейти на него. К тому же тут большую роль играет наличие саппорта, когда можешь прямо в скайпе написать ответственному из Unity и попробовать разрулить проблему.
1) Да, только с таким Render mode канвас будет неподвижен относительно камеры.
данных. Чтобы отображать их, мы реализовали виртуальные списки. В них есть определенное количество элементов, которые отображают контент. Это количество обусловлено размером видимой области списка и несколькими экстраэлементами для перестраховки. Когда элемент выходит за границы видимой области, ему определяются новые данные, и он переставляется в списке таким образом, чтобы пользователь, проскроллив дальше, увидел его следующим. Этот подход позволяет не создавать много объектов и отображать сколько угодно данных.
Выложили б ответственный код. Вполне себе библиотечная функция, на которую интересно посмотреть.
И всё равно найдусь я, у которого будет лагать. От этого никуда не денешься.
Можете подробнее разобрать как работает GIF с отрисовкой карты?
Это inactive геймобъекты или же динамическая подрузка с последующей выгрузкой?
Это inactive геймобъекты или же динамическая подрузка с последующей выгрузкой?
И то, и другое. Если вкратце, то там динамически подгружаемые из ресурсов при первом использовании объекты, которые по мере того, как выходят из области видимости, складываются в пулы, в inactive состоянии.
Тут важна сама идея, как и со списками, как и глобальным сulling'ом, не рендерить то, чего игрок не видит, а так же максимально-возможное переиспользование всего: один из первых заветов любого гейм-девелопера.
Тут важна сама идея, как и со списками, как и глобальным сulling'ом, не рендерить то, чего игрок не видит, а так же максимально-возможное переиспользование всего: один из первых заветов любого гейм-девелопера.
Артём, раз уж вы первый начали про списки, хочу вас попросить от лица всех игроков. Доведите пожалуйста до ума списки в мобильных играх.
Суть проблемы. По любому событию (например, приход войск разведки обратно на базу, или завершение строительства) список, который находится на экране, даже не связанный с этим событием (например, список заметок на карте), пересоздается и изменением точки отрисовки, говоря повседневным языком — мгновенно скроллируется наверх. Ладно в заметках, поматерился, отмотал на 5 экранов вниз и по новой, а если событие настигает в момент выбора количества юнитов на списке войск? Список под движущимся пальцем перерисовывается и вот ты уже выбираешь других юнитов. Люди так много теряли по невнимательности.
Багу этому 2 года, он кочует из игры в игру, многократно репортился, но максимум, чего игроки добились — введение настройки отключения всплывающих уведомлений у событий. На предложение исправить баг целиком комьюнити-менеджеры отвечали, что сие никак не представляется возможным. Но это же какой-то позор? Фиксируйте положение списка до перерисовки и после перерисовки рисуйте его так, чтобы для пользователя он визуально не менялся, сделайте очередь на изменение списка войск, которая фризится в момент выбора войск, добавляйте вернувшиеся войска в список в конец, чтобы при перерисовке у пользователя оставалось все на прежних местах, сделайте запрет перерисовки списка заметок в принципе, не знаю, вариантов огромное количество.
Очень ждем.
Суть проблемы. По любому событию (например, приход войск разведки обратно на базу, или завершение строительства) список, который находится на экране, даже не связанный с этим событием (например, список заметок на карте), пересоздается и изменением точки отрисовки, говоря повседневным языком — мгновенно скроллируется наверх. Ладно в заметках, поматерился, отмотал на 5 экранов вниз и по новой, а если событие настигает в момент выбора количества юнитов на списке войск? Список под движущимся пальцем перерисовывается и вот ты уже выбираешь других юнитов. Люди так много теряли по невнимательности.
Багу этому 2 года, он кочует из игры в игру, многократно репортился, но максимум, чего игроки добились — введение настройки отключения всплывающих уведомлений у событий. На предложение исправить баг целиком комьюнити-менеджеры отвечали, что сие никак не представляется возможным. Но это же какой-то позор? Фиксируйте положение списка до перерисовки и после перерисовки рисуйте его так, чтобы для пользователя он визуально не менялся, сделайте очередь на изменение списка войск, которая фризится в момент выбора войск, добавляйте вернувшиеся войска в список в конец, чтобы при перерисовке у пользователя оставалось все на прежних местах, сделайте запрет перерисовки списка заметок в принципе, не знаю, вариантов огромное количество.
Очень ждем.
Горизонтальную ориентацию экрана что мешает сделать для планшетов, кстати?
Платят мало? И не будут платить, играть неудобно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Особенности разработки мобильной MMO RTS. Часть 3