Рекомендации по Adobe Air для Mobile

Share Button

UPD: I see that my article can’t be translated using google translate due secure connection. Here is the link without https so you can read it if you want.

Данная статья затевалась как how-to. Пару раз переписав ее — у меня родилась просто обобщающая литература на много листов. Формат «книги» свернул в пользу беглого обзора :) В последствии пришлось сократить до читаемого формата подсказок с пунктами :)

1. Всегда следите за тем, чтоб Вы используете последнюю версию Adobe Air SDK. Многие проблемы возникают из-за использования устаревших версий. На момент написания статьи — последняя версия датирована 17 декабря 2013 года и имеет версию 4.0.0.1390. Скачивать обновления по ссылке http://labs.adobe.com/. Гораздо реже выходят Release сборки и они доступны тут http://www.adobe.com/devnet/air/air-sdk-download.html. Лично я не использую релиз сборки, т.к. в Beta всегда учтено куда больше улучшений и они всегда новее. Все, кто в теме — не переживают за это и публикуют игры на beta версиях и у них все превосходно работает. На картинке ниже отмечены две ссылки на закачку. Не раз сталкивался, что люди не могут найти кнопки.

2013-12-28_190620

2. Для доступа к нативным функциям операционной системы устройства существует поддержка Native Extensions. 2013-12-28_203156Они создаются на «родном» языке программирования для устройства и имеют *.ANE формат файла. Добавляются к проекту как обычный SWC. В старых версиях средств разработки — подключение ANE было не таким простым, как сейчас. «Нативки» (Native Extension) работать будут только на той платформе, для которой они созданы. Нельзя запустить ANE для iOS на Windows для отладки. Необходимо установить приложение на устройство и там уже осуществлять отладку иначе будет выдана ошибка несоответствия целевой и текущей платформы. Но можно разработать сразу несколько вариантов «нативок» под разные платформы и сделать их в одном файле.

3. Используйте Stage3D. Мобильная платформа настолько слабая, что делать привычные приложения «Как на флеш под веб» не получится, если хотите получить максимальную производительность.stage3d Обычный подход (устаревший) — работает на обычном DisplayList и все расчеты происходят в CPU. На моб. устройстве он слабый и нагружать лучше графический процессор, а не центральный. В этом случае можно получить довольно шустрое приложение, т.к. процессор уже будет освобожден от лишних операций. Стоит добавить, что ряд проектов могут вполне хорошо работать и на старом DisplayList. Как говорится — «там просто нечему тормозить». К таким играм относятся такие, где не требуется динамического изменения содержимого с высокой скоростью. Спокойные пазлы превосходно себя ведут даже на CPU рендеринге, ведь им 30 FPS более, чем достаточно.

4. Узнайте технические ограничения целевого устройства. В iPad1 невозможно загрузить больше изображений, чем он позволяет разместить в памяти GPU. Многие разработчики, которые начинают с нуля или переходят на Mobile платформу — упускают эту деталь. В итоге на форумах и блогах начинаются дебаты на счет capabilityограниченных возможностях Adobe Air. Если перевести пример в иную плоскость, то выглядеть будет так. Человек наливает в 250 граммовый стакан 300 грамм жидкости и у него 50 грамм вытекает через край. Вот те, кто не знает объем стакана и приходят жаловаться на изготовителя жидкости. Хотя проблема в стакане.

5. Корень проблем многих игр на мобильной платформе в Adobe Air vector- векторная графика. Не раз мне присылали приложения, которые тормозят. Все просят помочь решит проблему низкой производительности. Почти всегда сталкиваюсь с одним и тем же — люди ставят векторную графику, которая не работает нативно, ввиду архитектуры графического процессора. И весь расчет берет на себя CPU. А он, как писал уже в пункте 3 — слабый.

6. Храните все наборы ресурсов во внешних файлах на устройстве. Не надо пытаться встроить всё в один файл во время компиляции, как это позволительно для web игр. Устройство имеет ограниченный объем RAM и заполнить его на 100% не получится. hynixЖелезяка должна иметь «свободные» области памяти для функционирования операционной системы. Если Ваш планшет имеет 512 мб ОЗУ — не рассчитывайте, что Вы сможете полностью забить её своим приложением, т.к. оно просто «вылетит». Это касается не только Adobe Air, но и других средств разработки. Наверняка многие замечали, что если в Safari на iPad открыть много вкладок, где много картинок — браузер сначала притормаживает и потом вовсе закрывается.

Самый идеальный вариант — загрузка по мере надобности. Игрок нажал «играть» в первый уровень — загружаете все файлы к этому уровню. Прошел уровень — память очистили. Нажал играть в другой уровень — загружаете ресурсы под новый уровень.

7. Старайтесь использовать максимально низкое число Draw Calls*. Что такое *DC (сокращений много в мире. Остановимся на таком) — знают многие. performanceНо как происходит их рост — понимают куда меньше людей. DC — это количество проходов визуализации видеокарты для отображения финальной картинки. Самые популярные ошибки в подходе к разработке игры — отсутствие текстурных атласов, полупрозрачные текстуры на весь экран и большое число мелких объектов с неправильной архитектурой отображения. Давайте рассмотрим эти три ключевых момента.

7.1 Отсутствие текстурных атласов — большая заноза в проекте. Представьте, что у Вас есть персонаж, у которого есть руки, ноги и другие конечности. Очень часто я наблюдаю как таких персонажей сохраняют в виде разных файлов и называют их head.png, left_leg.png, right_left.png и так далее. Что же происходит дальше? Все очень просто. Они собираются кодом в одного персонажа руками программиста.atlas И, соответственно, GPU получает все эти картинки в виде разных текстур. В итоге, видеокарта для вывода на экран всех частей одного персонажа должна обратиться в память в разные ячейки для «взятия» цвета и «нанесение» его на экран.

Сначала она топает в файл «голова» и наносит его на экран. Потом она берет файл «рука» и наносит его на экран. Потом «нога» и так далее. Каждый раз, когда видеокарта «идет за текстурой» — она тратит относительно не мало вычислительных сил. Количество таких «походов» и называется Draw Call. Для сокращения данных неприятностей — необходимо использовать текстурные атласы. Используя их наш GPU обращается к текстуре только 1 раз и выводит её на экран значительно быстрее, чем если обращений было много. А выбор «что отображать» осуществляется за счет смещения текстурных координат в рамках одной текстуры.atlasParts

Теперь мы можем из одного атласа на экран вывести 10 одинаковых персонажей и у нас будет всего 1 Draw Call, против 12 (посчитайте количество частей в атласе). Flash подарил приятную возможность анимировать векторных персонажей во Flash Professional. Но стоит понимать, что это не Flash виноват, когда Вы не можете перенести свои анимации под GPU рендер, а именно Вы лично должны отвечать за данный процесс. Не важно на чем разрабатываете — это остается на плечах разработчика.

Сразу хотел бы небольшую тонкость подсказать. Если над персонажем планируется полоса здоровья — лучше её разместить в тот же атлас, в котором размещены части персонажа. Иной путь отображения health bar лишь добавит новый DC, т.к. это будет использование две разных текстуры.

7.2 Полупрозрачные текстуры на весь экран — одна из популярных проблем. Хотя и встречается не часто — имеет место быть. fillrateЕсть такое понятие, как Fill Rate. Т.е. количество нарисованных пикселей за промежуток времени. Прозрачности изначально несколько усложняют рендер. А большие «заливки» на весь экран такими текстурами снижают общую производительность, хотя и не генерируют дополнительные DC. Самое большое проявление таких неприятных ситуаций я наблюдал в создании интерфейсов, когда громадные панели накладываются поверх большой области цельным блоком и этот весь букет использует прозрачность, наложенную друг на друга.

7.3 Большое число мелких объектов с неправильной архитектурой отображения. Представьте, что у Вас есть 20 деревьев по 250 полигонов каждое. В сумме это 5 000 полигонов. Не много. batchingТак вот, когда эти деревья начнут рисоваться по-отдельности, то каждое дерево будет рисоваться отдельной программой и это будет вызывает замедление рендеринга. Для выхода из такой ситуации необходимо сливать такие объекты в единое целое. Видекарта гораздо быстрее за один проход отобразит 5 000 полигонов, чем 20 раз по 250. Это Вам ничего не напоминает? Правильно — текстурные атласы. Термин для «слияния» геометрии известен под словом Батчинг. Главное условие для его осуществления — единая текстура для всех «забатченых» объектов.

8. Оптимизация кода и принятие правильных решений. Мобильное устройство не имеет всех вычислительных возможностей своего старшего брата. Необходимо экспериментировать и добиваться лучших показателей.

Современные средства разработки представлены в большом ассортименте и порой сложно определиться на чем вести разработку. Одни предлагают кофе и уютное место, личный самолет и чит на бесконечные патроны. Но за это просят плату. Кто-то больше, кто-то меньше. Часто под видом «бесплатно» скрывается печальная картина, когда деньги можно зарабатывать по условиям лицензирования, но есть ограничения в разработке или количестве заработанных денег. sdksТут вспоминается модель игры Free-To-Play — вроде поиграть можешь бесплатно, но кнопка «победить всех» стоит денег. Другие предлагают немного уступающую производительность. Но за это просят меньше финансовой благодарности или же вообще только в случае успеха. Но есть и совершенно бесплатные продукты, ничего не просящие взамен. Именно за это я и выбираю Adobe Air.

8.1 Пул объектов. Представьте, что в обычном Web мы могли позволить себе создавать и удалять объекты постоянно и в большом количестве. Яркий пример — система частиц. Это неправильный подход к разработке в целом, хотя и работает. Он печально сказывается на производительности на мобильной платформе. Для решения данной проблемы — скрывайте и отключайте объект из рендера до тех пор, пока он снова не будет нужен. Почти все фреймворки делают это автоматически (извлечение объектов из рендера, если их не видно на экране). Не заставляйте лишний раз CPU poolingрассчитывать выделение памяти и инициализацию сборщика мусора для удаления результатов «труда». Использование одних и тех же объектов *называется пул объектов. На картинке слева мы видим, что в памяти висят неубитые элементы и один на экране. Как только нам надо будет отобразить персонажа — мы выставим его на сцену. При этом он не будет тратить время процессора на создание себя и удаление. В некоторой мере пул объектов похож на текстурные атласы и DC.

*Знать терминологию необходимо, но не более, чем уметь использовать её на практике. 

8.2 Не создавайте много маленьких методов. Читается такой код замечательно. А вот скорость его выполнения существенно замедляется. Ниже приведу два примера кода. Один выгодный с точки зрения чтения и другой с точки зрения производительности:

2014-01-07_110217

Как видите — код менее причесан. Но у него будет больше скорость выполнения из-за отсутствия постоянных обращений из функции в функцию. Кстати, для подобных целей придуман был inline кода. Добавляя мета-тэг мы продолжаем писать «красивый» код. napeНо компилятор соберет его в ужасно не красивый, но быстрый. Конечно, на простом примере выше разницы в скорости не будет никакой. Но если у нас очень много объектов и они в циклах, как это происходит в физических движках — разница будет колоссальная. Если сравнивать физический движок Nape с инлайном и без, то вариант с *инлайном будет на 30% быстрее. Это я лично замерял, когда пытался его немного ускорить. Инлайн через мета-тэг в as3 доступен в ASC2.0 версии компилятора (не путайте с AS2.0). Кто пишет «по старинке» — «тяжелые» методы с массой мелких вложений можете переписать руками.
*Не кидайтесь в панику — Nape уже идет с инлайном по умолчанию.

8.3 Правильно установите тип сборки. У Adobe Air есть разные варианты публикации готового проекта. speedЭто дебаг версия, режим интерпретатора, adhoc, market и другие. Если хотите протестировать максимальное быстродействие релизной сборки — выставляйте сборку для магазина. На сегодня нет разницы в AdHoc и Market, т.к. компилятор получает одинаковые инструкции сборки. Не раз уже было замечено, что разработчики банально упускали из виду данный параметр и у них производительности едва ли доходила до половины, после чего я неоднократно слышал плохие слова в адрес средства разработки.

8.4 Если делаете приложение в 2D — отключайте MipMaps. Самый популярный фреймворк по созданию 2D приложений на Air с использованием Stage3D — это Starling.  По-умолчанию, на этапе создания текстуры — будет предложено генерировать MipMaps. Это в случае создания графики из BitmapData. Данная рекомендация распространяется и на ATF файлы. Дополнительно читайте пункт 8.5.

mips

Они для 2D совершенно не нужны, т.к. не только засоряют память GPU, но еще и увеличивают время загрузки текстур в память. Смело отключайте их для 2D игр.

Примечательно то, что старлинг практически 1 в 1 повторяет привычный Flash DisplayList API и его разработчики постарались на славу.

Однако, всегда есть место совершенству. Ввиду того, что авторам приходится создавать публичный проект, где присутствует удобная читаемость кода «для каждого» — страдает производительность. Неоспоримый факт — старлинг своеобразный монстр по производительности. Но не гоночный болид, которым является Genome2D. Но и сложность использования соответствующая. Только не кидайтесь сразу за Genome2D — 9 из 10 проектов с головой покроет Starling. А если сделать шуточное сравнение производительности — мы получим такую картину:

benchmark

На чем делать игру — приходит либо с опытом, либо после анализа других игр. Но для этого все равно нужен опыт :) Замкнутый круг.

8.5 Используйте ATF текстуры, если это возможно. Они позволяют занимать меньший объем в памяти RAM и быстрее загружаются в GPU память. К тому же, c ними появляется возможность определения, когда текстура была успешно загружена. ATF конвертер доступен либо из Game Developers tools 1.3 (в 1.2 есть ошибки) либо можно найти на гитхабе более удачные конверторы. И не забывайте для 2D так же отключать генерацию MipMaps. По-умолчанию они генерируются внутри ATF.

8.6 Используйте кеширование данных. Это применимо везде. Простой пример — анимация. Предположим, что у Вас есть персонаж, у которого движения всех частей тела рассчитываются постоянно в реальном времени. Тот же DragonBones — это банальный Tweener, который плавно меняет данные матрицы с одних на другие. Это лишняя и ненужная нагрузка почти во всех 2D играх. Да и в 3D как-то тоже. Если персонаж один — не страшно. Но когда их будет очень много — Вы ощутите проседание FPS. Это связано с тем, что слишком большой поток математических расчетов пока трудноват для Adobe Air. И для снижения плохого последствия — мы просто кешируем значения матриц трансформации для каждого кадра. И потом, каждый раз при обновлении кадра — подставляем значения из кеша. Логически выглядит это так:

2014-01-07_110315

Получить матрицы довольно легко. Либо в реальном времени перед загрузкой уровня пройтись по каждому кадру и собрать преобразования, либо вообще предварительно создать их в классе. Второй вариант мне нравится больше — мы не нагружаем мобильное устройство расчетами, которые можем сделать предварительно до компиляции игры.

8.7 Для большинства игр действует золотое правило — «меньше, да лучше». Его мало кто пытается соблюдать. Я видел множество игр с переизбытком графики и анимаций. monalisaАвторы вкладываются всей душой и тратят силы на создание своих шедевров.
Случается так, что их игры не получают должной отдачи у целевой аудитории. Вроде и красиво, эффектно. Но «не то». Слишком много всего! А со скучным геймплеем — баги и недочеты становятся только виднее.
И тут приходит понимание, что игроки просто не видят сценарий, замысел и труд команды. Для них переполненная игра обилием графики и тормозов становится «очередной скучной игрой с большой кучей кнопок».
Это не относится прямолинейно к оптимизации, но все же имеет косвенную связь. Не пытайтесь в игру втиснуть все то, что позволяет технология для получения лучшей картинки. Лучше уделите внимание скорости загрузки файлов, время на растеризацию, генерацию атласов и т.д., ведь игра, загружающаяся около минуты до первого экрана — скорее всего потеряла своего игрока.

dlps3d8.8. Старайтесь избегать смешивания DisplayList и Stage3D. Такой подход любят для быстрой разработки интерфейсов. В конечном итоге он приводит к тормозам. Многие говорили, что это не влияет на FPS. А потом эти многие, когда проект разросся до больших масштабов — вынуждены избавляться от DisplayList.

8.9. Избегайте методов, которые возвращают новые объекты. Если результатом работы метода будет создание нового объекта с его возвратом через оператор return — подумайте еще раз, как этого можно избежать. Просадить FPS можно банальным циклом, где в каждой итерации будет вызываться какая-либо безобидная функция, генерирующая новые объекты. Если не используете inline от нового компилятора — хотя бы старайтесь «развернуть» этот метод в точке вызова. Тем самым облегчите жизнь CPU устройства.

9. Всегда профилируйте приложение. Для этого есть замечательное ПО — Adobe Scout. Скаут позволяет проводить scoutтонкий анализ хода работы приложений. С его помощью Вы сможете вывести свою игру не просто на новый уровень, а так же узнать в каких местах Ваш код дает осечку и вызывает скачки в производительности. Выделение памяти, затраченное время на работу той или иной функции и прочие данные, помогающие улучшить продукт. Маленькое дополнение: для работы со Скаутом — отключайте firewall. Скаут распространяется бесплатно, однако он работает только под x64 Windows.

На данный момент я поделился всем, чем хотел. Когда появятся новые мысли и рекомендации — создам вторую часть и размещу дополнительно сюда ссылку. Всем спасибо, кто прочитал. Если возникнет желание что-то поправить в статье — прошу сообщить мне это на почту.

Share Button

This Post Has Been Viewed 9,164 Times

Рекомендации по Adobe Air для Mobile: 28 комментариев

  1. TheRabbit Автор записи

    > Полезная статья! Особенно для тех у кого «Замкнутый круг».
    Спасибо, я старался :) Как раз такие статьи и должны разорвать этот замкнутый круг.

  2. Elmigo

    В общих чертах, но познавательно. Пока нет конкретных необходимостей, основная ценность материала сосредоточилась в предложении: «когда я с этим столкнусь — знаю у кого спросить» :)
    Спасибо.

  3. TheRabbit Автор записи

    «В общих чертах» — согласен. Часто вижу страданию людей, у которых что-то не получается. Они выносят себе мозг и уже по безнадеге оставляют «как есть». Хотя, в большинстве случаев, всегда найдется решение. Основные проблемные моменты я и решил обобщить списком. В очередной раз убеждаюсь, что нет надобности прыгать с платформы на платформу (время на пере-разработку и изучение), сокращать количество графики, выкидывать фичи.

    Сначала надо разобраться на сколько правильно выбрана архитектура создаваемого приложения и убедиться, что выбранный framework работает не хуже, чем можно было бы накидать его самом. Ведь сколько раз не скачали ту или иную библиотеку, сколько бы она не стоила — её писали такие же разработчики, как и мы с Вами всеми. А человеческий фактор еще никто не отменял.

    Спасибо, что нашли время для прочтения!

  4. Ritesh

    This is very good and informative post. Thanks
    My Question is about Point 6. «Keep all resource sets in external files on the device.»
    how this is possible? According to my knowledge we have to use SWC for mobile project and build IPA. How we can achieve external file loading mechanism?
    Thanks in Advance

  5. TheRabbit Автор записи

    Ritesh, it’s very easy. Just place your files into the same folder with a project and during compilation let compiler know about that folder. It’s will embed files to project but not to the swf.

    When your Adobe Air app started — it’s load whole SWF (Main) to the memory. But memory limited by device. So you don’t need to load all resources. Just load they using File or URLLoad. Mechanism is simple like you doing this for web when your resources is external.

    Here is simple example:

    var myatf : File = File.applicationDirectory.resolvePath("Images/atlas.atf");
    myatf.addEventListener(Event.COMPLETE, fileLoaded);
    myatf.load();

    var starlingTexture : Texture;

    function fileLoaded(e:Event):void{
    myatf.removeEventListener(Event.COMPLETE, fileLoaded);
    starlingTexture = Texture.fromAtfData( myatf.data, 1, false, textureUploadedToGPU );
    }
    function textureUploadedToGPU (....

    In my article «External» mean not storing out from device. They placed also in IPA. But not embedded to the any SWF/SWC.

    So using code above you can load ATF texture, throw it to the Starling. When you don’t need it anymore — just dispose it. But in this case you will free memory. In case if you embed your images to the SWF directly — you can’t free memory from embedded files.

    Method above just loads file using File API. Also you have options like URLLoader, FileStream. I suggest to use only external storing and not embedding to the SWF. This will save a lot of memory and provide better control over app and provide better performance when your memory usage will grow.

  6. TheRabbit Автор записи

    Danile, I can suggest you only wait… If your desired platform is not supported yet — may be later it will work. Adobe working hard on improvements and they are investigate new abilities. Not everything depends from Adobe skills. For example when PlayStation introduce embedded flash player — they work together with Adobe and develop player from the ground. Not a simple port. As I think there is no simple «compile to x86 tablets» option :)

    BTW, You can vote for Windows Mobile. https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=3648920
    *if you can’t login — just go to forums.adobe.com, login or re-login and than go to bugbase and vote. Once this can help and we all will be happy.

    I’m as the rest will be happy if Air will cover more and more devices. But we all must to know that it’s not so simple. Each device have own limitations and when some feature will work on one device — it will not work on another. So this should be taken into account…

      1. TheRabbit Автор записи

        Драгоны это твиннер по-сути. По-этому там производительность зависит от самого Air. В целом его хватает для большинства вещей. Но я его все равно не использую. Кеширую матрицы и подставляю их в enter_frame. Прирост производительности просто бешенный. Я рекомендую драгон бонс только в случае небольшого количества персонажей. А еще у бонсов есть dswf формат данных. Вот его надо избегать для мобилы, т.к. загадивается память и будет ее чистить GC. Можно ли прокачать драгонбонс? Можно;) Примерно на 15%.

          1. TheRabbit Автор записи

            Вбивание готовой матрицы — это и есть как раз вбивание готовых значений.

            В пункте 8.6 как раз на скрине видно, что у нас подставляются заранее рассчитанные матрицы. Я сторонник всего, что можно рассчитать предварительно — так с этим и поступать.

          2. anonim

            Та знаю я что такое матрица)
            Ну чего, сделал я ещё на выходных.
            Значит, «image.transformationMatrix = matrix[i]» у меня почему-то не работало в энтер_фреме, использовал transformationMatrix.copyFrom.
            Может быть, потому что использовал старую версию старлинга, т.к. хотел сравнить с демкой от драгонбонес, которая как раз на старой версии была.
            Короче, на втором айпаде. При 60 фпс «матричный вариант» показывает в два раза больше объектов(что-то около 75 по 17 частей), а при фпс равном 30 — в 1.5 раза больше объектов — то ли 119, то ли 129 точно не помню.
            Ну, занятно, но пока возился с «матричной версией» вспомнил, что ведь в костяшках-то полно разных фич…
            Да, интересный момент. На компе разница между неанимированными картинками и анимированными почти не заметна. 1-3 фпс на тысячу объектов (22 и 19-21 фпс соответственно). А вот на айпаде разница существеннее. Что символизирует.
            Ещё, разницу между аир 3.4 и 4.0 в плане фпс не заметил. Компилил во flash ide)
            А. В качестве контейнера использовал Sprite, а части — Image.

          3. TheRabbit Автор записи

            Значит, “image.transformationMatrix = matrix[i]” у меня почему-то не работало в энтер_фреме, использовал transformationMatrix.copyFrom
            Ставь нормальный старлинг )

            Ну, занятно, но пока возился с “матричной версией” вспомнил, что ведь в костяшках-то полно разных фич…
            На самом деле не так много этих фич для 2D игр, что за них следует переживать. Максимум — это произвольный FPS. Да, красиво. Но как много игр использует динамический FPS для конкретного персонажа?
            Кстати, в матричном варианте можно тоже динамический FPS сделать. Правда тоже предварительно. Делаешь себе обычных 30 кадров. Когда надо ускорить в 2 раза — просто пропускаешь кадр и все. Замедлить уже не получишься нормально :) Тогда остается изначально больше кадров сделать. Но это все ерунда. Сложные схемы анимаций я наблюдаю лишь в 1 из 20 игр. По-этому можно вообще не париться.
            Что касается разница между 3.4 и 4.0 — надо смотреть не только на твой пример, а на другие тоже. Математика быстрее, аплоад текстур быстрее. Много по мелочам. Невозможно в синтетических тестах это проверить :)

          4. amonim

            Да, скачал старлинг 1.4.1, и там присвоение матрицы работает.
            Но вот занятная вещь, присвоение матрицы работает медленнее, чем copyFrom, причём не слабо медленнее.
            При одинаковых значениях количества объектов,
            присвоение даёт 17 фпс,
            а копиФром — 25 фпс.

          5. TheRabbit Автор записи

            Все может быть ) Я не проверял на счет копиФром. Зато четко могу сказать, что можно сам метод переноса матрицы изменить и будет еще шустрее

  7. Александр

    У меня такой вопрос. Есть полноэкранная «векторная» анимация (1280х720) со звуками на таймлайне. На анимации несколько персонажей + иногда что то происходит на фоне. Каким образом лучше подключить эту анимацию к Starling проекту? Этим роликом нужно будет управлять (stop, play, gotoAndPlay) а так же отслеживать currentFrame, что бы в нужный момент остановить анимацию или перейти в другое место (в зависимости от действий пользователя).
    Делать атлас при таких размерах не реально, набор png файлов займет много место и не удобно будет всем этим управлять. Используя «векторную» анимацию как есть, будет ли она нагружать сильно девайс и нужно ли ее отдавать жанглеру?

    1. TheRabbit Автор записи

      Сложно дать точный ответ, не видя этот вектор. В целом стоит понимать — вектору не место на мобильном устройстве.

      Перевод анимаций из таймлайна — задачу не описать словами, не видя эту анимацию. Тут можно драгонбонс использовать. Можно покадровое кеширование матрицы. Можно greensock tweenmax использовать… А может быть такое, что никак, кроме покадрового атласа и не получится.

      Если можно мне прислать на условиях NDA на почту пример — я смогу дать более дельный совет.

        1. TheRabbit Автор записи

          Анимацию такого рода полностью не получится перевести в Starling. Можно перенести шарнирную анимацию, где части тела у персонажа вращаются по осям. Можно, к примеру, DragonBones использовать (только для персонажа).

          А так, чтоб рука не сгибалась по оси, а прогибалась «по вектору» — не получится. Так в «Фиксики» у девочки локти и колени сгибаются.

          Для этого можно использовать Mesh анимацию. Но тут уже другая схема нужна. Создается модель с костями в том же 3D Max, анимируется. Экспортируется, к примеру, в Away3D и скрещивается со Starling. Но задача на столько сложная, что лучше делать просто «на шарнире».

          Что касается фоновой анимации (да и в целом всего остального) — все, что меняет x, y, width, height, scaleX, scaleY, rotation, skewX, skewY — можно переносить переносить в старлинг. Применять и спрайтовую анимацию.

          Т.е. если получится всю анимацию сначала заменить на прямоугольные растровые картинки и потом анимировать — это сделать будет можно. Только тут уже не DragonBones нужен будет, а собственно написанный анимационный пакет классов на основе кеша матриц.

          Но я сгущаю краски потому, что я не вижу реальную анимацию. В примерах с ютуба совершенно два разных по сложности проекта. Если реальный проект — это вставки между уровнями — можно не мучиться и просто оставить вектор (но без эффектов) с обязательным LOW режимом графики на момент анимации. А если анимация это часть игрового процесса — надо переносить.

          В целом — слишком сложный проект для GPU анимации и без разницы — Air или что-то другое.

          1. Александр

            >Если реальный проект – это вставки между уровнями – можно не мучиться и просто оставить вектор (но без эффектов) с обязательным LOW режимом графики на момент анимации.
            Именно так и есть. Анимация как у фиксиков. Персонажи, иногда на фоне что то происходит. Есть разные режимы наложения (blend mode) и прозрачность у некоторых объектов.
            В общем то я понял. Или стейджВидео использовать (вопрос с управлением), или упрощать анимацию, разбивать все на png файлы и анимировать программно — адский труд.
            Спасибо за помощь.

        2. TheRabbit Автор записи

          управление элементрано можно написать. Не более 10-15 строк кода. Вопрос в реализации внедрения анимации…

  8. Аноним

    Привіт , підскажить будь ласка яка максимальна кількість атласів, якщо їх перегнати в atf формат допустима для ios

    1. TheRabbit Автор записи

      Добраніч :) Немає різниці оскільки Вы завантажуєте не по килькості атласів, а по загальному об’єм у мегабайтах. А скільки там є мегабайт до ліміту — це залежить від моделі девайсу.

      Тобто, якщо девайс може завантажити 200 мегабайт текстур — то й робити можна багато малих, або не дуже багато великих. Головне, щоб сумарна кількість у мегабайтах не перевищувала допустимый об’єм.

      Але не варто думати, что атлас в atf на 2 мегабайти буде так само займати об’єм у GPU. Зазвичай текстура буде розгортатися належно до технічних умов адже є декилька форматів та кожиный має свої обмежання.

      Завдяки Adobe Scout CC можна перевіряти детально зайнятий об’єм GPU пам’яти та робити висновки )

Добавить комментарий

Ваш e-mail не будет опубликован.

Blue Captcha Image Новый проверочный код

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>