Comments 26
К сожалению, UniRx умирает. Обновления взять все реже и реже (последнее полгода назад), автор на контакт толком не выходит… А жаль, действительно ведь крутая вещь.
Попробуйте Akka.Streams
Живой проект с похожим функционалом.
Про 3.5 в юнити не знал.
А вообще Akka.Streams это про реактивные стримы, а не про акторов.
Вообще не рядом.
Akka.Strems — отдельный продукт, который реализует стандарт Reactive Streams.
Да он использует акторов из фреймворка Akka для своей внутренней деятельности, но используя Akka.Streams программист пишет код как на обычном RX (подписка, мёржи потоков, параллелизация, тротлы, буферы, вот это вот всё).
При этом "нормальные" Reactive Extensions не реализуют стандарт Reactive Streams, а back pressure в issue висит с 2014го года
forum.unity.com/threads/unirx-reactive-extensions-for-unity.248535/page-6#post-3064218
Последний пример написан совершенно непонятно.
1) Смотрим на преобразования с кнопкой. Взяли кнопку, преобразовали ее с помощью OnClickAsObservable. На подписке уже странность: мы в место того что бы взять кнопку из параметра, хардкодим передачу в параметр конкретной кнопки на которую мы подписались. Далее еще странне: мы передаем даже не кнопку, а ее ид. А в самом методе опять сравниваем ее с захардкоженой конкретной кнопкой. В чем выгода относительно простой подписки?
2) Почему someView.AnimateButton происходит при нажатии в обработчике события кнопки, а не рядом с someView.RenderCount? Суть же в том, что бы 1 раз написать как должно вью работать при изменении модели, а здесь этот момент совершенно упущен.
2) Суть показать mvp и reactive properties. someView.AnimateButton вызывается в обработчике событий кнопки потому что анимируется кнопка от нажатия этой кнопки. А не потому что увеличивается каунт.
В Rx, да и вообще в паттерне Observable, в самой по себе подписке выгоды нет, это обычный callback. Выгода и вся мощь этого подхода проявляет себя в комбинации стримов друг с другом. Скажем, слушать какое-то событие только между событием А и событием Б. На обычных коллбеках это все реализуется через какое-то внешнее состояние и очень легко ломается при изменениях. В случае observable — все сравнительно легко покрывается тестами и чутко относится к изменениям.
Есть куча игр которые были разработанны без Rx. Я бы посоветовал вам пока просто присмотреться к UniRx. А потом если почувствуете надобность вы всегда можете использовать его. Придерживаетесь KISS принципа.
en.wikipedia.org/wiki/KISS_principle
Рекомендую этот канал всем кого заинтересовал UniRx. Там скоро должен появиться толковый тутор https://m.youtube.com/watch?v=kFoBvjwzbNA
Может кто знает как решить проблему?
Для процедурно генерируемых это основная часть расчетов.
А создавать сам меш и текстуру — в основном.
Так сейчас жив UniRx? Последний коммит в репозитории - лето 19го года.
UniRx — Rx для Unity3d