Существуют ли объекты, нарисованные классом Flash Graphics, как объекты?

Question

Внутренне Flash, очевидно, хранит список примитивов, нарисованных с использованием Graphics, поэтому я подумал, что если у вас есть много таких примитивов в Sprite, можете ли вы перемещать / удалять / изменять отдельные элементы вместо очистки и повторного рисованиявсе?Или это более глубоко в недрах Flash, чем вам разрешено (или рекомендуется) пройти?

Answer 1

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

Sprite -> DisplayObjectContainer - > InteractiveObject -> DisplayObject
Shape -> DisplayObject

Answer 2

К сожалению, это невозможно: как только элементы нарисованы, вы можете изменить только полную форму, но не сам рисунок.

Чтобы дать вам больше объяснений, я погуглил о том, как Flash на самом деле вычисляет экранные объекты.К сожалению, я не смог найти ничего конкретного.

Но я нашел достаточно, чтобы сделать обоснованное предположение: [РЕДАКТИРОВАТЬ]: Я нашел очень интересный PDF-документ по Анатомия Flash .Это объясняет дерево рендеринга и то, как графические объекты обрабатываются внутри.

Я точно знаю, что все анимации формы, созданные в IDE, скомпилированы в последовательности форм (каждый кадр сохраняется как отдельное изображение),И это имеет смысл сделать так: каждый новый кадр фильма должен быть рассчитан, все векторные изображения добавляются в дерево, каждое из которых отображается в виде растровых изображений, объединяется и рисуется как одна конечная битовая плоскость для отображения.Поэтому логично делать все возможные расчеты во время компиляции, а не во время выполнения.

С другой стороны, растровое изображение будет хранить 32 бита информации о цвете для каждого отдельного пикселя, в то время как векторы сохраняются в простых значениях, сохраняя координаты x и y, стиль линии, стиль заливки и т. Д. Некоторые векторы можно сгруппировать., так что для более сложных форм стили линий и заливки должны быть сохранены только один раз, а для остальных необходимы только координаты.Кроме того, примитивные формы, такие как круги и прямоугольники, требуют меньше информации, чем объекты, объединенные из множества отдельных точек и линий.

[РЕДАКТИРОВАТЬ]: вышеупомянутый PDF говорит это:

И DisplayObjects AS3 и AS3 преобразованы в SObjects внутренне.Объекты SO имеют связанный символ.Основанный на типе символов, он имеет различные методы рисования, но все это возобновляется для рисования заливок с разными источниками цветов.

Потребуется очень, очень сложная векторная форма, чтобы требовать больше отдельных частей информации.чем его растровое представление, при условии, что он больше, чем несколько пикселей по ширине и высоте.Следовательно, для сохранения простых форм в виде векторных представлений требуется значительно меньше памяти, чем для хранения полных растровых изображений - и поэтому логично не выполнять фигуру рендеринг также во время компиляции (за исключением сложных фигур - затем «cacheAsBitmap»)собственность вступает в игру).

Подумайте, что я сказал о векторах, стиле линий, стиле заливки и т. Д. - это очень похоже на последовательность команд, которые мы должны написать при рисовании в ActionScript, верно?Я бы предположил, что эти команды просто конвертируются 1: 1 в тот тип векторных представлений, о которых я говорил.Это сделает компилятор быстрее, двоичные файлы будут меньше, а обработка форм IDE и AS будет абсолютно одинаковой.

[РЕДАКТИРОВАТЬ]: Оказывается, я был не совсем прав:

Edge & Colors

• LSObjects tree isпройден и создается список ребер
  • Края имеют связанные цвета
  • Штрихи преобразуются в ребра
  • Цвета являются источниками данных отображения, например.Растровые изображения, видео, сплошные заливки, градиенты
• Растрирование
  • Края сортируются, и цвет рассчитывается для каждого пикселя - пиксели касаются только один раз
• Презентация
  • После того, как основной растеризатор завершил рисование, буфер памяти копируется на экран

Теперь представьте всеиз этих векторов были свободно редактируемыми: Последовательность команд больше не будет окончательной! Что если вы добавите, переместите или удалите одну во время выполнения?Например: наличие прямоугольника внутри заполненного прямоугольника вычитает внутреннюю форму из внешней формы.Что если вы переместили одну из угловых точек наружу?Результат будет совершенно другой формы!Или если вы добавили одно очко?Вы не можете больше хранить фигуру в виде прямоугольника, требуя, чтобы 5-ти точечные элементы рисовали то же, что когда-то было одним прямоугольным элементом.Вкратце: все группировки и оптимизация памяти больше не будут работать.И это также значительно замедлит графику во время выполнения.Вот почему разрешено добавлять новые элементы в фигуру, но не изменять их после их отрисовки.И почему вы должны очистить и перерисовать графику, если вы хотите, чтобы существующие фигуры изменились.

[РЕДАКТИРОВАТЬ]: Вы всегда можете делать сложные вещи, выполняя вычисления самостоятельно.Я по-прежнему считаю, что было правильным решением не интегрировать их в базовые графические функции.

Answer 3

В Flash CS5 и формате файла XFL эти данные теперь доступны в виде XML.

Для моего примера, вы можете создать карту тайлов, состоящую из элементов «Графика» из мувиклипа, где различные кадры являются разными тайлами. Мгновенно вы сталкиваетесь с необходимостью доступа к этим недоступным индексам фреймов из объектов Shape.

Если вы поместите их в символ (даже тот, который не экспортирован), вы можете найти его в файле в вашей папке LIBRARY (после сохранения как 'xfl'). Он отражает содержимое библиотеки.

   <DOMSymbolItem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ns.adobe.com/xfl/2008/" name="Tileset_Level_Test" itemID="4e00fe7f-00000450" linkageExportForAS="true" linkageClassName="Tileset_Level_Test" sourceLibraryItemHRef="Symbol 1" lastModified="1308719656" lastUniqueIdentifier="3">
  <timeline>
    <DOMTimeline name="Tileset_Level_Test">
      <layers>
        <DOMLayer name="Layer 1" color="#4FFF4F" current="true" isSelected="true" autoNamed="false">
          <frames>
            <DOMFrame index="0" keyMode="9728">
              <elements>
                <DOMSymbolInstance libraryItemName="Tileset_Test" name="" symbolType="graphic" firstFrame="8" loop="play once">
                  <transformationPoint>
                    <Point/>
                  </transformationPoint>
                </DOMSymbolInstance>
                <DOMSymbolInstance libraryItemName="Tileset_Test" name="" symbolType="graphic" firstFrame="4" loop="play once">
                  <matrix>
                    <Matrix tx="48"/>
                  </matrix>
                  <transformationPoint>
                    <Point/>
                  </transformationPoint>
                </DOMSymbolInstance>
... lots more...
              </elements>
            </DOMFrame>
          </frames>
        </DOMLayer>
      </layers>
    </DOMTimeline>
  </timeline>
</DOMSymbolItem>

XML выглядит довольно сложным, но вы можете обработать его до чего-то гораздо более простого с классом XML и (например) создать маску столкновения из мувиклипа, отражающего эти индексы кадров, и определить точки появления и другие специальные классы вещи. Или вы можете обработать данные и нарисовать карту целиком, для этого вам нужен только визуальный способ. Все, что вас действительно может волновать, это tx, атрибуты ty в матрице (для того, где размещен тайл) и атрибут 'firstFrame' в 'DOMSymbolInstance' (для какого тайла).

В любом случае, вы можете предварительно обработать его с помощью апплета AIR, чтобы получить только те данные, которые вам нужны, а затем либо получить файл .as для включения в проект, либо упрощенный XML, либо что угодно. Или используйте любые другие инструменты / языки, которые вы предпочитаете, и добавьте этот шаг обработки в свой сценарий сборки.

Формат файла xfl также удобен для отслеживания и исправления всевозможных вещей, которые Flash слишком сломал / глючил / AFU, чтобы исправить, например, оставшиеся ссылки на шрифты в неясных частях частей частей .... Вы можете исправить их в библиотеке, или буквально удалить файл нарушающей части, или отредактировать XML вручную. Grep, sed, find и xargs - все ваши друзья для этих задач. Особенно для таких вещей, как привязка всех координат к целочисленным значениям или надлежащих границ ячеек, поскольку все «привязки» Flash также ужасно нарушаются. Передача XML-файлов через sed может быть довольно опасной для файлов, для которых вы не сделали резервную копию, но весьма полезна для злых людей, которые знают, что они делают, и используют контроль версий.

Answer 4

Ну, каждый DisplayObject имеет только одну графическую ссылку.Поэтому, если вы хотите переместить (или масштабировать и т. Д.) Несколько графических объектов в одном Sprite, я предлагаю вам использовать дерево отображения так, как оно было задумано.Просто добавьте несколько детей (Sprites или MovieClips или ...) в один Sprite, каждый из которых будет перерисован при необходимости.