« DropShadowFilter и GlowFilter в Starling | Главная страница | Нужны ошибки компиляции при создании экземпляра синглетона извне? Запросто! »

ARP - новый формат упаковки ресурсов

Запись от Котяра размещена 07.02.2013 в 00:52
Обновил(-а) Котяра 07.02.2013 в 02:37

Вечерело. Кончалось пиво. За окном снежило. В чате молчало..
Тут я и решился рассказать о своём проекте.

Предыстория
Возникла задача портировать онлайн игру под мобильные платформы.
Android и iOS.

Под андроид первый тестовый apk был готов очень скоро, но для iOS возникли проблемы.

Эппловцы запрещают грузить внешние swf с кодом, а под кодом понимаются даже просто залинкованные в библиотеке битмапки, спрайты и мувиклипы.

Цитата:

Dynamically loading a ‘remote‘ SWF, that contains ActionScript code will continue to NOT work.
http://blogs.adobe.com/airodynamics/...r-apps-on-ios/

Слава богу, логика приложения довольно отделена от представления (хотя это слишком оптимистично, я пока сильно глубоко не заглядывал)
Но в логике контроллеров гуи, описаниях карт, описаниях миссий и т.п. уже прописано: бандл#имя ресурса.
Т.е. грузится бандл.swf и в нем берётся инстанс от "имя ресурса".
Перелопачивать всю эту груду кода и конфигов совершенно лень.

Я решил оставить существующую иерархию и придумал свой формат
ARP - Atf-based Resource Pack

Сделал для этого специальную тулзу, которая перегоняет swf в arp.
По сути это растеризованные мувики, спрайты, битмапы, битмапдаты сохраннённые в png а затем переконвертируемые в ATF и все опять собрано в один бандл и сериализовано в AMF3.

В тулзе есть различные опции по конвертированию png2atf + немножко ещё.

Я пока кратенько описал, так как проект, хотя уже и рабочий, но далёк от совершенства.
Если это кому-нибудь интересно напишу подробнее.
Собственно сам проект:
https://bitbucket.org/k0t0vich/arp
Подписывайтесь, ставьте лайки..

PS: отдельное спасибо Дикобразу за алгоритм упаковки и СлаваРа за поддержку.
PPS: пока версия arp - нулевая, т.е. альфа. Сам формат может поменяться (и, скорей всего, - поменяется)

Комментарии 21

Всего комментариев 21

png2atf - так мне и не дал внятного качества текстур.

Я использую:
PNG --> PVR (RGBA8888) --> ATF. Текстуры получаются мульти-платформенные, весят в разы меньше, работают быстрее. При этом обычный ANT делает все это меньше чем за минуту (20 атласов 2048х2048).

PVR делается этой тулзой: PVRTexToolCL.exe

09.02.2013 20:10 C4Grey вне форума

C4Grey

2toFL
ATF вроде быстрее загружается в видеопамять, это основное преимущество? И да, может ты в курсе, есть какие-то устройства из распостраненных, которые не поддерживают 2048х2048 текстуры? В каком-то треде на форуме Adobe читал, что вроде iPhone до 3GS только 1024х1024 прддерживают, это верно?

По теме:
Исходя из, увы, небольшого опыта разработки игрушек под мобильные устройства, решил отказатся от подгрузки swf и Embed-директив, как бы оно не было удобно в пользу обычных, разбросанных по ФС файлов.
Есть один плюс: можно динамически подгружать только нужные ресурсы перед началом игровой сессии и не держать их все время в памяти(по тому же принципу работают более-менее крпуные игрушки). Кстати, проблему совместимости разных типов подключения ресурсов решил через отделение загрузки ресурсов от логики игры. Игровые объекты работают не с экземплярами классов текстур/звуков, а с классами Data(Image/Sound)Asset, содержащими ссылку на ресурс. Asset может быть составным(например, грузить сначала XML, потом атласы), при этом его части тоже являются экземплярами классов Asset, что позволяет корректно определять общий прогресс загрузки, отслеживая события. Ну и если нужно будет работать уже с Embed ресурсами - просто меняется класс-загрузчик. Сложнее будет в случае разбросанных по разным swf ресурсов, нужно будет строить систему пакетов по типу используемой в UDK.

09.02.2013 23:46
Jewelz	> ATF вроде быстрее загружается в видеопамять быстрее загружается, меньше ее жрет > В каком-то треде на форуме Adobe читал, что вроде iPhone до 3GS только 1024х1024 прддерживают, это верно? на таких устройствах вы Starling не запустите

10.02.2013 17:29
alatar	Я так понял асинхронной загрузки нет? Т.е. нельзя просто получить ссылку на ByteArray (точнее на FileStream в асинхронном режиме) и смещение, для предачи, например, в текстуру?

12.02.2013 22:18
Котяра	Асинхрона нет, не вижу надобности, кроме того, в старлинге тоже нет асинхронного декодирования ATF, а формат, в первую очередь, заточен под него.

12.02.2013 23:30
alatar	В старлинге нет (пока нет?). Но не одним же старлингом живет Stage3D. Можно было бы запилить универсальную либу для упаковки ресурсов.

13.02.2013 12:56 alatar вне форума

alatar

Даже если не использовать асинхронность, в старлинге есть частичная поддержка смещений (Texture.uploadAtfData()). Довольно легко модифицировать создание текстуры добавив offset в Texture.fromAtfData() и можно будет избавиться от лишнего создания ByteArray.

13.02.2013 13:36 Котяра вне форума

Котяра

Т.е. ты предлагаешь отказаться от сериализации в AMF3 и использовать собственный протокол, не создавая из входного файла массив atfBytesArray, а читать его сразу из arp файла?

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

Всё равно, спасибо за предложение, подумаю.
Вопрос, насколько часто используется асинхронная загрузка atf текстур вообще?

13.02.2013 13:56 alatar вне форума

alatar

Мысль об отказе от AMF3 у меня сразу возникла, можно придумать что-нибудь и более оптимальное для бандлов. На эту тему интересно почитать статьи о реверсе форматов ресурсов для игр.

Цитата:

Вопрос, насколько часто используется асинхронная загрузка atf текстур вообще?

Не обязательно при этом использовать асинхронность. Бандл, по-сути будет представлять собой FileStream и можно не париться, что не хватит памяти на промежуточный ByteArray или какой-то ByteArray забудут удалить.

13.02.2013 14:12
alatar	Кстати, при асинхронной загрузке больших текстур можно будет показать анимированный индикатор загрузки. Хотя я не пробовал, на предмет возникновения тормозов.

13.02.2013 16:42 toFL вне форума

toFL

Цитата:

Кстати, при асинхронной загрузке больших текстур можно будет показать анимированный индикатор загрузки. Хотя я не пробовал, на предмет возникновения тормозов.

Это все конечно хорошо применять, и я скорее всего тоже к этому приду, но на моей практике, при создании двух-трех максимальных атласов, проходит времени 1-3 секунды (iPad >= 2). Что, как мне кажется, вообще не критично, тем более такой объем графики создаешь не часто (Кто-то это делает вообще на старте приложения).

13.02.2013 16:59
alatar	Я про старт приложения и писал.

14.02.2013 00:56 Nooob вне форума

Nooob

я бы в Packer добавил проверку на дубликаты картинок простым BitmapData.compare (бывает такое что кадры совпадают), ещё добавил бы упаковку с повёрнутыми изображениями на 90 гр. и сортировкой по площади от большей к меньшей. тесты показали что это очень хорошо помогает. ну а поворачивать обратно с помощью uv и вершин в шейдере или в буфере.

Ну такое решение (MovieClip->BtimapData->Atlas->Atf) хорошо подходит только для векторных изображений.
Если к примеру взять MovieClip с кадрами из растровых изображений, где применёна трансформация scaleX = -1, то дополнительная растризация создаст лишние дублированные трансформированные изображения, для таких случаев рекомендовал бы разбирать из fla DOMDocument.xml и остальные ресурсы, и только потом засовывать в атлас.

И ещё, так как размеры атласа жестко ограничены, то остаётся много пространства. Лучше использовать это и объединять несколько ресурсов, заполняя это пространство. Но всё это зависит от специфичности проекта.

14.02.2013 12:21
Котяра	Цитата: я бы в Packer добавил проверку на дубликаты картинок простым BitmapData.compare (бывает такое что кадры совпадают)... - Есть в планах, я даже хотел сравнивать не просто на 0, а анализировать спектр разницы задавая опционально эмпирическую "степень похожести". - Разборка до шейпов, битмап и/или анализ fla, тоже есть в планах (пробовал использовать flump и grapefrukt, но на моих ассетах почему-то ничего хорошего не вышло) - По поводу упаковки : сейчас несколько ресурсов упаковываются в одну текстуру и наоборот, один ресурс может быть упакован в несколько текстур, сама упаковка может и не оптимальна, работаю над этим. Если ты имеешь в виду упаковывать несколько swf в 1 arp, то это тоже возможно сделать, но для моего конкретного проекта это не нужно. Сам смысл был в соответствии bundle.sfw#ResClass -> bundle.arp#ResClass. В общем, сейчас я уже вижу, что сделать "универсальное" решение на все случаи жизни можно, но требует неоправданных усилий) Пока меня уже устраивает то, что есть. По мере поступления реальных задач, буду допиливать. Но вдруг кому-то пригодится моё решение..
	Обновил(-а) Котяра 14.02.2013 в 12:41

15.02.2013 21:50
dimarik	Шагаем по стопам становления формата swf. Все новое-- это хорошо забытое старое. Вы не забывайте о фильтрах и bitmapfill в authority mode. Объем растра зависит лишь сложности этой swf. А с authority mask придется вовсе по тегам бегать

16.02.2013 02:07
Котяра	Дим, да - приходится идти по стопам. Но этот формат не для ВСЕХ swf ресурсов, а с некоторыми разумными ограничениями.
	Обновил(-а) Котяра 22.02.2013 в 00:52

19.02.2013 16:21
BlooDHounD	Котяра, а не проще было написать парсер свф?

19.02.2013 17:55
zuxul	Так он же уже написан: https://github.com/claus/as3swf

19.02.2013 21:17 dimarik вне форума

dimarik

А! Блуд, привет! Решил на минутку заскочить в наш уютный? А Костя вот твой проект пытается в мобилку загнать ) Уже парсеров-конвертеров понаписал.
По теме. Эти вектора и растры как мякгое и теплое. Невозможно без оверхеда конвертировать одно в другое. Придется чем-то жертвовать.

21.02.2013 12:09
Котяра	Цитата: png2atf - так мне и не дал внятного качества текстур. у меня вполне нормальные получились. использую такие параметры: Цитата: png2atf.exe -i input_file -o output_file -e -s -q 40 т.е. RGBA без мипмаппинга, сжатие в jpgxr c квантернизацией 40

22.02.2013 00:58 Котяра вне форума

Котяра

Цитата:

Котяра, а не проще было написать парсер свф?

Я вот не пойму, это ирония или реальное предложение)
Если 2-е, то нет - не проще. Даже предварительная разборка до шейпов с сохранением состояний потребовала кучу ресурсов, а если ещё добавить парсинг swf, вытаскивание объектов, потом сборку в текстуры для stage3d - это оверхед. Проще на земле переконвертить.

Последние записи от Котяра

Архив
< > Январь 2025
Вс	Пн	Вт	Ср	Чт	Пт	Сб
22	23	24	25	26	27	28
29	30	31	1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31	1