> сабскрайбер сам разберется когда прервать работу если активити уничтожается
unsubscribe надо делать вручную. RxJava ничего не знает про жизненный цикл Activity или каких-либо других сущностей Android. Немного подробнее можно прочитать здесь в разделе «Fragment and Activity life-cycle».
Да. Я даже скажу больше. Во всех современных 2D движках используется такой способ рендеринга. =) Наверное, только в Adobe Flash ещё не до конца к этому пришли, но прогресс идёт.
Добавлю, что 2d режим в юнити ещё сыроват. Я делал небольшой проект, где-то с десятком анимаций и сотней статичных спрайтов. Через некоторое время стало крашиться где-то в недрах движка на загрузке анимаций. Воспроизводилась эта бага месяц назад точно.
Коротко ответить на этот вопрос невозможно, слишком много различных факторов надо принимать во внимание.
Это зависит от того что меряете, относительно чего, как построена архитектура приложения, как используется скриптовый движок, как сделан биндинг, какие технологии используется в игре и как они используются итд итп. Если всё сделать грамотно, то просадки производительности заметно не будет.
Такие вопросы часто возникают при обсуждении скриптования в геймдеве и показывают, к сожалению, что до всеобщего понимания целей и задач скриптования ещё довольно далеко. Начать хотя бы с того, что при использовании скриптов никто не ставит цель рассчитывать в них сложные и тяжелые алгоритмы (понятно что это глупость), соответственно классическое влобное сравнение производительности теряет смысл в виду множества факторов (более важных).
Собственно вопрос уже давно нужно ставить не как «падает производительность или не падает», а «как мне использовать правильно встраиваемые скриптовые языки так, чтобы не падала производительность».
Понятно, что здесь я произнес общие слова и в каждой конкретной игре есть свои особенности. Может, в некой игре X скрипты не нужны совсем и можно обойтись грамотно спроектированными данными.
Сравнивать (может быть) имеет смысл два скриптовых языка, например Lua и Javascript, но и то не по скорости, а скорее по удобству биндинга, управлению памятью, гарантированному объему памяти которую потребляет интерпретатор и всему такому.
Зачем грубить? Что вы понимаете под «ручным управлением памятью»? OP_li* и им подобные? Если да, то назвать это ручным управлением памятью можно с большой натяжкой. В исходниках упоминания о них присутствуют github.com/mozilla/shumway/blob/master/src/avm2/opcodes.js#L98. Используются ли они в работе и если да, то насколько эффективно можно понять только изучая исходники более глубоко.
В любом случае их эффект не будет аналогичен таковому в AVM, которая транслировала вызовы этих опкодов в native код, здесь же их вызов будет заменён неким javascript вызовом, что нивелирует эффект и теряется смысл их использования.
В cocosbuilder ведь тоже на js игровой код писать надо, так что с переносимостью всё ok.
Проблема в builder и cocosino немного в другом — в неудобстве написания native extensions. Надо не только через JNI продираться, например, но и через Spidermonkey.
Как можно помочь плохой статьёй? Как можно помочь кодом, для понимания которого даже хорошему программисту надо затратить заметное время для понимания? Вы выложили код, почти без объяснения и думаете что это кому-то поможет? Тот кто может в нем сейчас разобраться — может наколхозить такого over 9000.
И я даже не говорю ещё про то, что так в lua лучше не делать и про вред велосипедостроения.
> что уж лучше такая статья, чем бесконечный поток малополезных новостей
Это плохая позиция. «Остальные выкладывают трешак, ну и я выложу тоже почему нет».
unsubscribe надо делать вручную. RxJava ничего не знает про жизненный цикл Activity или каких-либо других сущностей Android. Немного подробнее можно прочитать здесь в разделе «Fragment and Activity life-cycle».
Это зависит от того что меряете, относительно чего, как построена архитектура приложения, как используется скриптовый движок, как сделан биндинг, какие технологии используется в игре и как они используются итд итп. Если всё сделать грамотно, то просадки производительности заметно не будет.
Такие вопросы часто возникают при обсуждении скриптования в геймдеве и показывают, к сожалению, что до всеобщего понимания целей и задач скриптования ещё довольно далеко. Начать хотя бы с того, что при использовании скриптов никто не ставит цель рассчитывать в них сложные и тяжелые алгоритмы (понятно что это глупость), соответственно классическое влобное сравнение производительности теряет смысл в виду множества факторов (более важных).
Собственно вопрос уже давно нужно ставить не как «падает производительность или не падает», а «как мне использовать правильно встраиваемые скриптовые языки так, чтобы не падала производительность».
Понятно, что здесь я произнес общие слова и в каждой конкретной игре есть свои особенности. Может, в некой игре X скрипты не нужны совсем и можно обойтись грамотно спроектированными данными.
Сравнивать (может быть) имеет смысл два скриптовых языка, например Lua и Javascript, но и то не по скорости, а скорее по удобству биндинга, управлению памятью, гарантированному объему памяти которую потребляет интерпретатор и всему такому.
В любом случае их эффект не будет аналогичен таковому в AVM, которая транслировала вызовы этих опкодов в native код, здесь же их вызов будет заменён неким javascript вызовом, что нивелирует эффект и теряется смысл их использования.
Проблема в builder и cocosino немного в другом — в неудобстве написания native extensions. Надо не только через JNI продираться, например, но и через Spidermonkey.
Как можно помочь плохой статьёй? Как можно помочь кодом, для понимания которого даже хорошему программисту надо затратить заметное время для понимания? Вы выложили код, почти без объяснения и думаете что это кому-то поможет? Тот кто может в нем сейчас разобраться — может наколхозить такого over 9000.
И я даже не говорю ещё про то, что так в lua лучше не делать и про вред велосипедостроения.
> что уж лучше такая статья, чем бесконечный поток малополезных новостей
Это плохая позиция. «Остальные выкладывают трешак, ну и я выложу тоже почему нет».