Воскресенье, 22 Декабря 2024, 14:05

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
Насколько медленнее GetComponent от gameObject.tag
alexsilentДата: Суббота, 11 Августа 2018, 06:35 | Сообщение # 1
почти ветеран
Сейчас нет на сайте
Хочу создать свою систему тэгов с помощью GetComponent,
и задумался насколько эта функция медленная, стоит ли её использовать для таких целей?

То есть не будет ли затратно каждый кадр проверять у всех столкнувшихся объектов на GetComponent?


Сообщение отредактировал alexsilent - Суббота, 11 Августа 2018, 06:46
drcrackДата: Воскресенье, 12 Августа 2018, 03:18 | Сообщение # 2
старожил
Сейчас нет на сайте
если нужна своя система с поддержкой нескольких тегов
проще и быстрее наверно сделать глобальный Dictionary<int, HashSet<int>>
где первый int это instance id обьекта, а в хешсете хеши твоих тегов
по крайне мере такое решение приходит в голову первым
очевидно что GetComponent будет намного медленнее и сложнее
RangerДата: Воскресенье, 12 Августа 2018, 06:13 | Сообщение # 3
почти ветеран
Сейчас нет на сайте
1. с 17й Unity используется встроенная система кэширования компонентов. т.е. вопрос быстродействия не стоит остро.(я правда всё равно по старинке руками кэширую)
2. objectID бесполезен, тк получить по нему объект возможно только через EDITOR. ID используется лишь для сравнения объектов.
3 если компонент который нужно получить скрипт, то в нем на awake добавлять в статический словарь Dictionary comp<GameObject,IMyComponent>, на OnDestroy удалять его из этого словаря.


pixeyeДата: Воскресенье, 12 Августа 2018, 08:27 | Сообщение # 4
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()
Хочу создать свою систему тэгов с помощью GetComponent,
и задумался насколько эта функция медленная, стоит ли её использовать для таких целей?


Медленная. Но это все относительно и не настолько как кажется. Даже юнитивское встроенное кеширование медленее чем когда ты кешируешь сам так что в этом досих пор есть смысл.

1) Тест - 100 000 вызовов гет компонент 40 раз подряд - у меня даж не подтормаживает. На то чтобы в редакторе отработать 100 000 вызовов гет компонент уходит 0.019260503 секунды.

2) Проверять каждый кадр GetComponent уже не оч привлекательно НО зависит опять таки от масштабов. Если ты делаешь "total war" из юнитов которым надо постоянно каждый кадр что-то вызывать через GetComponent - это да, плохая идея.

3) Если у тебя сравнительно небольшая игра с небольшим кол-во одновременно действующих лиц то без разницы. Текстуры и аудио гораздо больше будут сжирать твоей производительности чем твои скрипты : )

У GameObject.tag только одна функция - на старте игры найти объекты по этим тэгам. Обычно такое в различных ECS вижу.

Мой пример логических тэгов - я использую словарь где ключом выступает число и значением выступает число отвечающее за кол-во одинаковых тэгов на сущности. Зачем я так сделал:
Нередко бывают ситуации когда состояния стэкаются и для проверок тебе надо быть уверенным что весь стэк пустой. Например тебя оглушили с интервалом в 1 секунду на 3 сек два гоблина. Если делать слишком наивно то у начинающих разрабов может возникнуть ситуация что по выходу из первого оглушения герой начнет бегать. Допустим была просто булева переменная Stunned и когда хоть один стан проходит она меняется на false - в моем случае можно застэкать тэг Stunned и делать проверки когда в нем ничего не останется.

Как удобно работать с int чтобы редактировать на человеческом языке отдельная тема. Я это делаю через const int с атрибутами

Мой скрипт тэгов не привязан к монобехейверу. Я юзаю один монобехейвер для связки всей логики на игровом объекте - он хранит все компоненты объекта в словаре.

Код


private Dictionary<int, object> components = new Dictionary<int, object>(EngineSettings.ComponentsDefaultCount);

public T Add<T>(T component, Type overrideType= null)
  {
   // иногда нужно обращаться по типу родителя к объекту - для этого юзаем overrideType
   var hash = overrideType== null ? typeof(T).GetHashCode() : overrideType.GetHashCode();
   components.Add(hash, component);
   return component;
  }

// Вытаскиваем объект
    public T Get<T>()
  {
   object obj;
   if (components.TryGetValue(typeof(T).GetHashCode(), out obj))
   {
    return (T) obj;
   }
  }


Сами объекты тебе тоже надо как-то кешировать. Простейший способ делать статик list и толкать туда объекты из OnEnable и убивать из листа по OnDisable


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю



Сообщение отредактировал pixeye - Воскресенье, 12 Августа 2018, 08:42
alexsilentДата: Воскресенье, 12 Августа 2018, 11:34 | Сообщение # 5
почти ветеран
Сейчас нет на сайте
pixeye, спасибо! Тогда не так всё и плохо, у меня не стратегия на овер 1000 юнитов, но юнитов 100 на 100 планирую устраивать сражения (и это не стратегия, а просто средней массовости побоища, максимум на 200 юнитов на карте), попробую потестировать.

А словаря я боюсь, я не знаю как он работает, мне всё время кажется, что с такими вещами может быть происходить либо утечка либо ещё какая-то трабла, или когда словарь накопит под 3000 слотов, начнёт тормозить. Это скорее доисторическая боязнь неизвестности :D


Сообщение отредактировал alexsilent - Воскресенье, 12 Августа 2018, 11:39
InsaneSystemsДата: Воскресенье, 12 Августа 2018, 11:46 | Сообщение # 6
участник
Сейчас нет на сайте
Цитата
Насколько медленнее GetComponent от gameObject.tag

Быстрее.
pixeyeДата: Воскресенье, 12 Августа 2018, 16:37 | Сообщение # 7
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()
pixeye, спасибо! Тогда не так всё и плохо, у меня не стратегия на овер 1000 юнитов, но юнитов 100 на 100 планирую устраивать сражения (и это не стратегия, а просто средней массовости побоища, максимум на 200 юнитов на карте), попробую потестировать.

А словаря я боюсь, я не знаю как он работает, мне всё время кажется, что с такими вещами может быть происходить либо утечка либо ещё какая-то трабла, или когда словарь накопит под 3000 слотов, начнёт тормозить. Это скорее доисторическая боязнь неизвестности :D


если у тебя бой на 200 объектов вообще не сильно парься из-за оптимизации кода ( особенно если это компы ) . Базовой оптимизации будет достаточно + грамотная работа с самими объектами.


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг