Запишите звонок с рекламой и в фас отправьте. Я так периодически отправляю, а фас меня держит в курсе: создали дело, вызвали в суд (рекламщиков), в суд не явились, им выставили взыскание на 20к.
Я не знаю почему он у вас оказался медленным тут надо в код смотреть и искать где именно Вы ошиблись.
Структурные изменения в Unity ECS происходят только на главном потоке. Чтобы запустить эти изменения из привычной логики, внутри джобов, требуется командный буфер, который точно также воспроизводит эти структурные изменения, просто медленней и чуть позже. Скейлится это всё очень плохо, почему я и решил обойти стороной структурные изменения.
По сути, с точки зрения логики-обработчика это одно и тоже. Отличается лишь то, как именно данные добираются до него.
Если нам нужно например написать кастомную логику интеракшена с допустим дверью то мы заводим под это систему и пишем в ней фильтр который отбирает сущности с компонентами Door и Interacted и пишем туда свою кастомную логику, посути это и есть аналог виртуального метода.
Это самый первый - наивный метод, рассмотренный в статье. Его проблемы там же и описаны.
Что касается ивентов они в ECS так же реализуются через ентити с компонентом события, который отлавливается системой в обычном порядке и обрабатываются.
Этот подход я тоже пробовал, но при написании статьи он совсем вылетел у меня из головы.
В рамках Unity ECS он оказался невероятно медленным и скейлить его по этой причине - невозможно.
Первостепенно проблема заключается в исполнении кастомной логики без постоянного оверхеда, с чем решение справилось удовлетворительно.
Если прямо сейчас потребуется использовать это для интерфейса - то достаточно будет для каждого сообщения создать систему, которая переотправит сообщение через другой мессенджер. Но это шаблонный код и его конечно хочется избежать, подписываясь напрямую.
И это тоже не первый MVVM фреймворк. Ранее я на харбе видел ещё одну реализацию, но мне она не понравилась т.к. для биндов там требовалось создавать новые кастомные контролы для UI Toolkit.
Дотс живой и здоровый. Им завезли поддержку 2023 долгожданную. В последние апдейты завезли много обнов движка спецом для дотса.
Это делает встроенное решение Entities.Graphics, которое они благополучно не использовали.
Менять нагрузку АЭС раз в минуту не выйдет.
Ну так-то, Android - это опен сорс.
Запишите звонок с рекламой и в фас отправьте. Я так периодически отправляю, а фас меня держит в курсе: создали дело, вызвали в суд (рекламщиков), в суд не явились, им выставили взыскание на 20к.
На самом деле Unity 2022.2+ поддерживает 4.0.1 roslyn.
А по виджетам не совсем понятно почему просто нельзя сохранить class declaration в переменную и явно добавить всё необходимое?
Например:
myClass.WithMembers(member1,member2)но это происходит очень быстроВ малых масштабах - да. Но далеко не так быстро, как могло бы быть, что собственно и причина для статьи.
Я не знаю почему он у вас оказался медленным тут надо в код смотреть и искать где именно Вы ошиблись.Структурные изменения в Unity ECS происходят только на главном потоке. Чтобы запустить эти изменения из привычной логики, внутри джобов, требуется командный буфер, который точно также воспроизводит эти структурные изменения, просто медленней и чуть позже. Скейлится это всё очень плохо, почему я и решил обойти стороной структурные изменения.
По сути, с точки зрения логики-обработчика это одно и тоже. Отличается лишь то, как именно данные добираются до него.
Если нам нужно например написать кастомную логику интеракшена с допустим дверью то мы заводим под это систему и пишем в ней фильтр который отбирает сущности с компонентами Door и Interacted и пишем туда свою кастомную логику, посути это и есть аналог виртуального метода.Это самый первый - наивный метод, рассмотренный в статье. Его проблемы там же и описаны.
Что касается ивентов они в ECS так же реализуются через ентити с компонентом события, который отлавливается системой в обычном порядке и обрабатываются.Этот подход я тоже пробовал, но при написании статьи он совсем вылетел у меня из головы.
В рамках Unity ECS он оказался невероятно медленным и скейлить его по этой причине - невозможно.
Ну это как раз размышления для будущего.
Первостепенно проблема заключается в исполнении кастомной логики без постоянного оверхеда, с чем решение справилось удовлетворительно.
Если прямо сейчас потребуется использовать это для интерфейса - то достаточно будет для каждого сообщения создать систему, которая переотправит сообщение через другой мессенджер. Но это шаблонный код и его конечно хочется избежать, подписываясь напрямую.
Из того что знаю: их стор написан на дотнете.
Я делал свою реализацию MVVM с биндами и локализацией. Статья если что не о MVVM, а скорее просто презентация того что я делал.
https://habr.com/ru/post/717286/
И это тоже не первый MVVM фреймворк. Ранее я на харбе видел ещё одну реализацию, но мне она не понравилась т.к. для биндов там требовалось создавать новые кастомные контролы для UI Toolkit.
У них же есть всё готовое для сплит-скрина. Прямо в мануале
https://docs.unity3d.com/Packages/com.unity.inputsystem@1.5/manual/PlayerInputManager.html
Зачем они сделали Dark и Light Editor Theme, которые выглядят совсем иначе и не связаны с игрой, только им известно.Потому что UI Builder также используется для создания интерфейса для Editor.
Есть же UniTask без GC аллокаций. Зачем в 2022 использовать корутины?