Можно посмотреть на вполне себе вменяемых конкурентов от dualtron, а если денег мало или хочется что-то полегче (до 35кг) - тот же g-booster/x8 от kugoo. К сожалению, кгб вроде сняли с производства, теперь только остатки где-то искать.
Пулинг нужен, да. Основной посыл был - в выборках энтитей по условиям вообще не должно быть аллокаций в принципе. Как это сделано - достаточно посмотреть любой популярный фрейм, ссылки можно погуглить в соседнем посте https://habr.com/ru/post/665276/
Осталось посмотреть количество аллокаций на каждый чих и больше никогда не пытаться пилить геймдев-код в enterprise стиле. Про статику во всех-всех вызовах апи вообще молчу - это за гранью добра и зла (TDD отдельно отпинают за углом за невозможность нормально писать тесты ко всему этому добру).
Если не можешь контролировать js вне песочницы - перестань использовать электрон. Даже не так - перестань использовать на хосте ноду, электрон в песочнице - ок.
Лучше расскажите про полное отсутствие аудита в их unity hub, что по сути позволило выполнять произвольный код на всех машинах пользователей, став одним из самых крупных ботнетов.
Но в итоге ты вынужден давать доступ на запись, если ты пилишь unityhub (ланчер движка с автоапдейтом, выкачиванием зависимостей и т.п). Т.е не помогут никак эти запреты.
Их конечность. Изначально классика была на масках и была лимитирована 64 (1x ulong) компонентами. Потом было расширение на 128, 256, 512 (2-4-8x ulong). Но в любом случае сразу прилетел фидбек. И пришло осознание, что проверка масок много жрет - в случае 512 компонентов это 8 итераций цикла по полной маске. В итоге маски были выкинуты и вместо них стал массив интов индексов типов (пулов) компонентов, повешенных на энтити. В среднем на энтити висит 4-6 компонентов, т.е будет 4-6 итераций для проверки совместимости энтити с фильтрами, что уже выгоднее. И к тому же количество компонентов в мире не ограничено.
Ecs-подход рассматривается с 2 сторон - как архитектурный, так и перфоманс-паттерн. Dots - это не ecs, а скорее dod, ecs там пришит сбоку. К слову, в большинстве популярных фреймов возможно использование jobs/burst, т.е тот самый dod вполне возможен и вне dots. В общем, когда берут 3dparty ecs-фрейм - пытаются как раз не в dod, а в архитектуру. Архитектурно ecs дает легкость рефакторинга, расширяемость - можно перекроить все механики достаточно быстро, что невозможно в случае классического ООП подхода (ригидность иерархии наследования и вот все это). Об этом писалось не раз, в том числе и на хабре.
"Классическая" версия не использует спарсеты, там просто пулы с масками компонентов на энтитях и дикты в фильтрах. Советую поглядеть кишки lite-версии, там больше нет никаких масок компонентов и все на спарсетах (пулы, фильтры). Ну и да, нет больше никакой статики в ядре - плохая идея была позаимствована.
Про итерацию через лямбду - это очень медленно, она не инлайнится и в итоге колбек вызывается для каждой энтити, но думаю ты это и так знаешь.
Про сортинг энтитей "по порядку" - это тоже возможно в лайте как постпроцессинг, причем порядок можно задавать самому на основе данных с энтити.
В каждом тике система пробегалась по всем энтити и выбирала соответствующие, но производительность такого подхода оказалась, мягко говоря, неудовлетворительной.
Надо было бежать не по всем, а по самому короткому пулу из констрейнтов с чеком остальных на совместимость - это резко уменьшает количество перебираемых данных в общем случае. Такие проверки дают падение производительности на 20% примерно, но зато убирают необходимость фильтров в принципе - это дает буст на перекладывании данных по фильтрам (убирает все накладные расходы), что чаще является затыком, чем линейный процессинг.
К сожалению, ни чем не могу помочь - прошло 4 года с момента публикации комментария, бот сгинул с сорцами в районе 2018 после перехода на ApplePay + выписку из банка.
А еще на моноколесе несоизмеримо больше нагрузка на колени по сравнению с самокатом, после 35-40 годков это становится проблемой :)
Можно посмотреть на вполне себе вменяемых конкурентов от dualtron, а если денег мало или хочется что-то полегче (до 35кг) - тот же g-booster/x8 от kugoo. К сожалению, кгб вроде сняли с производства, теперь только остатки где-то искать.
На мот нужны права, самокаты до сих пор считаются пешеходами, а закон по СИМ так и не приняли вроде как.
Пулинг нужен, да. Основной посыл был - в выборках энтитей по условиям вообще не должно быть аллокаций в принципе. Как это сделано - достаточно посмотреть любой популярный фрейм, ссылки можно погуглить в соседнем посте https://habr.com/ru/post/665276/
Осталось посмотреть количество аллокаций на каждый чих и больше никогда не пытаться пилить геймдев-код в enterprise стиле. Про статику во всех-всех вызовах апи вообще молчу - это за гранью добра и зла (TDD отдельно отпинают за углом за невозможность нормально писать тесты ко всему этому добру).
Если не можешь контролировать js вне песочницы - перестань использовать электрон. Даже не так - перестань использовать на хосте ноду, электрон в песочнице - ок.
Лучше расскажите про полное отсутствие аудита в их unity hub, что по сути позволило выполнять произвольный код на всех машинах пользователей, став одним из самых крупных ботнетов.
https://forum.unity.com/threads/unity-hub-3-1-release-overview.1253823/
https://github.com/vuejs/vue-cli/issues/7054
https://github.com/RIAEvangelist/node-ipc/issues/233
Но в итоге ты вынужден давать доступ на запись, если ты пилишь unityhub (ланчер движка с автоапдейтом, выкачиванием зависимостей и т.п). Т.е не помогут никак эти запреты.
Который поможет только если лоды будут совпадать.
Их конечность. Изначально классика была на масках и была лимитирована 64 (1x ulong) компонентами. Потом было расширение на 128, 256, 512 (2-4-8x ulong). Но в любом случае сразу прилетел фидбек. И пришло осознание, что проверка масок много жрет - в случае 512 компонентов это 8 итераций цикла по полной маске. В итоге маски были выкинуты и вместо них стал массив интов индексов типов (пулов) компонентов, повешенных на энтити. В среднем на энтити висит 4-6 компонентов, т.е будет 4-6 итераций для проверки совместимости энтити с фильтрами, что уже выгоднее. И к тому же количество компонентов в мире не ограничено.
Собственно, гугль тоже в курсе пары "ecs gamedev".
Ecs-подход рассматривается с 2 сторон - как архитектурный, так и перфоманс-паттерн. Dots - это не ecs, а скорее dod, ecs там пришит сбоку. К слову, в большинстве популярных фреймов возможно использование jobs/burst, т.е тот самый dod вполне возможен и вне dots. В общем, когда берут 3dparty ecs-фрейм - пытаются как раз не в dod, а в архитектуру. Архитектурно ecs дает легкость рефакторинга, расширяемость - можно перекроить все механики достаточно быстро, что невозможно в случае классического ООП подхода (ригидность иерархии наследования и вот все это). Об этом писалось не раз, в том числе и на хабре.
А, не заметил, сорян. Да, тогда нормально, но зачем лямбда, если можно через тот же итератор и foreach-loop или просто через for-loop?
"Классическая" версия не использует спарсеты, там просто пулы с масками компонентов на энтитях и дикты в фильтрах. Советую поглядеть кишки lite-версии, там больше нет никаких масок компонентов и все на спарсетах (пулы, фильтры). Ну и да, нет больше никакой статики в ядре - плохая идея была позаимствована.
Про итерацию через лямбду - это очень медленно, она не инлайнится и в итоге колбек вызывается для каждой энтити, но думаю ты это и так знаешь.
Про сортинг энтитей "по порядку" - это тоже возможно в лайте как постпроцессинг, причем порядок можно задавать самому на основе данных с энтити.
Надо было бежать не по всем, а по самому короткому пулу из констрейнтов с чеком остальных на совместимость - это резко уменьшает количество перебираемых данных в общем случае. Такие проверки дают падение производительности на 20% примерно, но зато убирают необходимость фильтров в принципе - это дает буст на перекладывании данных по фильтрам (убирает все накладные расходы), что чаще является затыком, чем линейный процессинг.
Скорее "решение в лоб".
https://stackoverflow.com/questions/257331/how-do-i-explain-what-a-naive-implementation-is
"Вы были распознаны нашими супер-алгоритмами как перекуп, ваша сосноль уезжает к следующему более сговорчивому покупателю, прощайте!"
домра выдает белую статику в регионах за 20р в месяц.
Но, но... это же не Марс, а Арракис на КДПВ.
К сожалению, ни чем не могу помочь - прошло 4 года с момента публикации комментария, бот сгинул с сорцами в районе 2018 после перехода на ApplePay + выписку из банка.