Развернутый формат файла Flash CS5 IDE

До CS5-го флеша бинарный формат файла флеша был практически не читаемым. Это приводило ко многим неудобствам. Начиная от хранения этого бинарника в системе контроля версий, до восстановления поломанного файла или внесения массивных однотипных изменений.

И наконец Адоби порадовали — можно сохранять в ИДЕ не бинарный файл FLA а папку с ясными и понятными файлами проекта. Более того, FLA формат CS5 это просто zip такой папки. Ура? Частично да, но в бочке меда оказалась не одна лопата дегтя.

Сначала — какие плюсы мы таки неоспоримо обретаем?

Можно разорхивировать FLA подхачить, поправить все что необходимо, наконец просто посмотреть что-же не так с каким-то конкретным шейпом. Примеры от меня:
— импортировнный векторный рендеринг 3Д модели из Блендера при попытках оптимизировать или превратить линии в заливки превращается в кашу, заливки исчезают. Рассмотрев xml файл этого клипа можем выяснянить в чем кривизна шейпа (двойные точки, например). Можно поравить ручками.
— полученный после рендеринга 3Д модели из Блендера swf с анимацией в векторном виде импортированный во флеш видится в библиотеке с заливками, но при попытке редактирования заливки исчезают. Смотрим что за фигня и правим.
— массированно переименовываем клипы :) — это можно сделать и другим способом, но так тоже удобно
— делаем нетривиальное или массированное изменение на таймлайнах клипов, то что ручками в ИДЕ делать очень муторно и долго. Любые другие массированные действия, в частности просто дублировние клипов фаз юнитов для дальнейшей перекраски и мелкой дорисовки в их бронированные варианты
— написание тулзовины, которая анализирует xml клипа в котором нарисованы кривые безье путей по которым едут юниты и создание соответствующего файла для пропихивания в игру. У меня была тулза встроенная во флеш и это конечно было удобно пользовать — нажал кнопку и увидел анализ путей на ошибки, обводки прямо во флеше, автоматом все уже в игре. Однако это было неудобно и небыстро девелопить — JSFL + swf, ошибки в котором поди догадайся где произошли. swf тулзы перекомпилил — слава богу не надо переоткрывать флеш, но окном тулзы надо открывать-закрывать через меню. Итд. Так что думаю для скорости удобнее будет лезть прямо в xml. Либо использовать его как есть :), правда перед релизом почистить xml, чтобы сэкономить место.

Еще один плюс не плюс — для кого как. Старый FLA все импортированные картинки хранил у себя в своем формате. И конечно помнил пути до оригинала, чтобы можно было нажать update. Новый FLA делает себе копию картинки и работает с ней. Параллельно все равно держит и dat файлы в своем формате, для скорости загрузки. Таким образом можно редактировать прямо в папке эти картинки. При переключении во флеш даже update не надо делать. Однако если вы сделали замену картинки — надо переоткрывать документ. Тут возникает вопрос, что будет если после сделать update — не затрется ли изменение, которое вы делали прямо в папке проекта? Я не стал экпериментировать, поскольку решил жить с бинарным FLA. Почему — ниже.

Сперва вкратце про развернутый формат. Это папка с именем проекта (бывшего имени FLA файла) в которой главное что есть:
— папка bin (здесь лежать dat файлы с картинками/звуками во внутреннем формате флеш + некий кеш)
— папка library (здесь лежат клипы библиотеки — файлы xml, плюс картинки png jpg, звуки/музыка итд)
— DOMDocument.xml — главный файл, здесь в большинстве случаев только список клипов библиотеки плюс возможно два кадра стейджа с прелоадером итд
— PublishSettings.xml

Все эти xml файлы очень понятны, их удобно редактировать — таймлайны, шейпы, клипы итд.

Тем, кто конвертит свои FLA файлы из CS4 формата — картинок в png jpg итд в library папке вы не обнаружите. Сначала надо сохранить в бинарный FLA CS5 формата, потом сделать update всем картинкам/звукам которые вы хотите видеть у себя в library папке. Потом сохранить. Потом сохранить как XFL. Все эти телодвижения нужны потому, что старый FLA вообще не хранит у себя копий картинок итд.

А теперь про лопаты дегтя. Разумные люди ;) пользуются системой контроля версий, даже если работают в одиночку. А для команд и компаний это вообще маст-хэв. Раньше для FLA хорош был SVN, ибо он очень разумно работает с бинарными файлами, репозиторий не разрастается — красота. Однако, имея на руках развернутую структуру папок с тестовыми xml — грешно не поверить что теперь придет суперсчастье. Например, подкорректировал я только шейп одного клипа и коммичу изменения. Раньше перекоммичивался весь FLA, который может занимать мегабайты. Спасибо SVN — по сети едут дифференсы, которые он умудряется выловить в бинарниках. Но в общем случае идет перерасход. Плюс нельзя узнать какие точно изменения произошли. Теперь же, вроде-бы, дифференс это одна строчка шейпа. Он легко весит, любой может сделать дифференс хоть через месяц и увидеть что за изменение было сделано.

Однако! При конкурентной работе, если один художник создаст красный круг слева, а другой зеленый квадрат справа, и первый коммитит свои изменения первым, то второй при коммите получит конфликт, хотя хотелось бы чтобы обе добавки попали в систему вместе, как это работает с кодом. Для того, чтобы этого не происходило Адоби надо было доводить свой xml до ума (либо это вообще невозможно).

Однако! Флеш может писать клипы библиотеки в произвольном порядке. Иногда в одном иногда в другом. На ПС в одном на Маке в другом. В итоге — изменений не было, а контроль версий может зафиксировать глобальные изменения. Недавно вроде это пофиксили, но не без греха. Еще одна засада — флеш ориентируется на даты изменения файлов (для того чтобы быстро загружать проект), а апдейты контроля версий могут даты менять при каждом чекауте. Это вроде можно отключить но муторно. Самое главное не пофиксено — флеш продолжает генерить «случайные» изменения при записи xml. Перемешивает, например. То-есть по сути ничего не поменялось, а контроль версий считает что поменялос вообще все (это не контроль версий такой «плохой», на всякий случай скажу).

Про вышеупомянутые траблы forums.adobe.com/message/2959932

Таким образом, буду хранить в бинарном FLA, при случае разворачивая его и насилуя ручками.

Ссылки по теме:
The XFL File Format Explained — blog.theflashblog.com/?p=1986
XFL: Managing your library assets — blog.mencio.com/?p=121
Flash CS5 and Version Control — www.dz015.com/?p=202
  • +11

Комментарии (5)

0
Пользуюсь описанным расширенным форматом. Удобно.
Трабл с «случайными» изменениями при записи xml решаю путем сравнения файлов перед коммитом.
0
А часто траблы такие случаются при неконкурентной работе?
Еще вопрос — ты SymDepend.cache файл в репозиторий положил?
0
Папку bin вообще не ложил в репозиторий, ибо думал что там только кеш.
Один раз напоролся, так что возможно из нее и стоит что-то ложить в репозиторий.

Часто изменяется поле
<Edge edges="....."/>
на сколько я понимаю, порядок обхода координат может меняться.
То есть если графика спрайта/мувика не перерисовывалась — то смело игнорируем.

Меняются поточные положения на таймлайнах.
<DOMTimeline currentFrame="221" />
Выделения
<DOMLayer current="true" isSelected="true"/>
Время модификации
<DOMSymbolItem lastModified="1282649007"/>

Все это игнорируем.

Пользуюсь TorgoiseSVN
Алгорим работы прост:
1. Схораняем проэкт.
2. Делаем на папке «SVN Commit...»
3. Просматриваем измененные файлы. Выделяем только действительно измененные (мы ж знаем над какой частью проекта работаем ;)), для этого проверяем их «Compare with base».
4. Пишем приметку и ОК.
и все.
0
bin весь точно правильно коммитить (кроме SymDepend.cache как я подозреваю)
Там по ссылке Flash CS5 and Version Control глянь — в bin лежать бинарники (картинки, звуки) в спец формате Флеш и именно их в работе. В определенных случаях, если оригинала картинки нет в library или в другом месте — потеряешь dat файл из bin — потеряешь картинку вообще.

А про просеивание коммитов… ну его. Причины:

1. SVN отлично работает с бинарниками. Комиитится все моментально, размер экономится. Выгоды в отдельном коммите одной xml я не вижу.
2. Я изменения всегда описываю в коммите, если надо будет вспомнить или найти — не проблема.
3. На крайняк — подымаешь предыдущую и нужную ревизию. Распаковываешь и сравниваешь дифф.

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

Часто откатываю.
Откатался, сделал таск из туду листа, закоммитил изменения.
Откатался, сделал таск…

Приблизительно так.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.