Войти
ПрограммированиеФорумГрафика

ECS во все поля (6 стр)

Страницы: 1 2 3 4 5 6
#75
(Правка: 11:51) 11:46, 17 апр. 2020

Suslik
ну вот, как я и говорил - букв много, толку ноль
ты вот лучше скажи сколько систем на реальном проекте а не демке

#76
11:53, 17 апр. 2020

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

#77
12:27, 17 апр. 2020

/A\
> DOD зависит от архитектуры железа
выравнивание по размеру кэшлинии для каждой железке,да

#78
13:28, 17 апр. 2020

innuendo
> выравнивание по размеру кэшлинии для каждой железке,да
То что сейчас архитектура всех популярных процессоров более менее одинаково это плюс.
Суть то в том, что при DOD производительность цпу приближается к максимальной.
Вот если бы был умный префетч, умный бранч предикшн, кэш оптимизированный под рандом аксесс, то можно было и не запорачиваться со всякими DOD и ECS, а использовать всем понятное ООП.

А как в анриле с DOD ?

#79
13:31, 17 апр. 2020

/A\
> а использовать всем понятное ООП.

да ты шо - если не брать PowerPC в старых конзолях то всё чикипуки

> А как в анриле с DOD ?

я после последней правки её не вышел из запоя

#80
15:30, 17 апр. 2020

Suslik
> Существуют игровые сущности, которые не являются обособленными объектами.
> Например, дождь, или отладочный рендер, который рендерит всё, что только можно.
> Или, например, логгер. Приянто ли такие сущности называть системами
Не осилил пока все сообщения в теме, но от себя хочу сказать, что например в моем доморощенном ECS отладочный рендер, да и простой рендер довольно удачно легли в отельную систему. К тому же очень удобно, надо отключить отладочный рендер - отключил систему и все.
А вот логгер просто сделал как синглтон для удобства использования везде где хочу.

Suslik
> короче, TL;DR, они как раз рассказывают про то, как ввели паттерн singleton
> component, который им показался полезным для инпута (потому что им тоже
> показалось странным для всех объектов хранить копию инпута или хранить один
> объект с компонентом ипута) и ВНЕЗАПНО у них 40% всех компонентов переехало в
> этот паттерн
Я эту презу не смотрел, но мне как-то сразу показалось логичным ввести сингл-компоненты. Я даже заточил свою ECS для оптимального и удобного использования таких. Ладно инпут, а тот же игрок (точнее компонент-маркер, который позволяет из множества персонажей определить где персонаж игрока) или камера которые предполагаются в единственном экземпляре. Да и много еще чего может быть такого. Тут главное не ограничивать себя.

#81
16:23, 17 апр. 2020

Dimm Smile
> > Существуют игровые сущности, которые не являются обособленными объектами.
> > Например, дождь, или отладочный рендер, который рендерит всё, что только
> > можно.
отладочный рендер как отдельный компонент? спасибо не надо

#82
11:14, 18 апр. 2020

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

#83
23:14, 19 апр. 2020

вспомнил еще видео

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

#84
10:33, 20 апр. 2020

Dimm Smile
> Как отдельная система, которая работает с набором других компонентов.

для простых примеров пойдёт

#85
2:52, 21 апр. 2020
Suslik
> не отвечай ему ничего
однострочные подъёмы теме даже хорошо, к тому же "во все поля" почему-то в разделе "графика"
Прошло более 7 месяцев
#86
2:19, 21 ноя. 2020

Подглядел в entt хорошую идею хранить разреженный массив индексов постранично, а не одним большим куском. Заимплементил себе :)
Теперь не страшно иметь редкие компоненты с большим entity_id - их индексный массив будет занимать минимум памяти, независимо от величины entity_id.
Query производительность чуть ухудшилась из-за дополнительной индирекции, но в целом время работы систем почти не изменилось. А в синтетических тестах на 10 млн сущностей наоборот всё ускорилось, точно не понял почему, мб L2/L3 кеш стал эффективнее использоваться.

Ещё интересный момент в entt - они не создают длинный variadic template с типами всех компонентов, а создают контейнеры под компоненты в рантайме. С одной стороны очень удобно, но с другой есть фатальный недостаток (с) - нельзя проитерироваться по списку всех типов компонентов, потому что сделано это на шаблонной конвертации типа в type_id (uint32), которая работает только в одну сторону. Есть метод visit(func), который вернёт этот type_id типа для каждого компонента, по которому можно максимум строковое имя вытащить, но сам тип уже не получить. Это же жутко неудобно.

То есть чтобы запилить что-то подобное (отображение инфы по каждому компоненту для конкретной сущности):
Изображение

Нужно будет городить огород с интерфейсами или visiter'ами для каждого типа компонента и прочие бесполезные обёртки.

В то время как у себя я просто итерируюсь по всем типам std::tuple и бесплатно получаю каждый контейнер компонентов с их исходными типами, и могу безо всяких лишних обёрток заимплементить редактор/browser сущностей с отображением всех компонентов.

#87
11:42, 21 ноя. 2020

Alexander K
> мб L2/L3 кеш стал эффективнее использоваться.

опять писькомизации

Страницы: 1 2 3 4 5 6
ПрограммированиеФорумГрафика