Встраивание активов на основе упаковщика

Question

Ситуация такова. В настоящее время я разрабатываю игру AIR, которая будет содержать много битмап-активов. Я хотел бы настроить табло на несколько планшетов (iPad, Xoom и т. Д.), И, таким образом, я рассматриваю возможность создания активов в разных ppi, чтобы иметь более визуальную согласованность между устройствами. Я не очень беспокоюсь о резолюции, потому что я буду использовать прокрутку для активов, которые не подходят на экране; но единицы, здания, враги должны выглядеть почти одинаково независимо от устройства.

Возникает вопрос:

• это может быть сделано и как
• , что было бы лучшим способом сделать это
• должен я даже заморачиваться (упаковщик основе?)?

Единственная мысль, которая приходит мне в голову до сих пор, состоит в том, чтобы иметь файл приложения для каждого целевого устройства (или ppi, на самом деле), которое вытаскивает большой битмап-реестр, который соответствует ppi устройства. Статический класс реестра по существу одинаковый для всех этих приложений, отличающихся только именем файла, которое [Embed] указывает (и, очевидно, на имя класса).

Answer 1

Я думаю, что вы на правильном пути, если вы хотите иметь определенные наборы активов для каждого типа устройства. То, как я это делал в прошлом, заключается в использовании сценария rake, но любая утилита make -like/ant, которую вы соответствуете, будет делать. По сути, одна из задач, которые выполняются перед компиляцией проекта, состоит в том, чтобы просканировать структуру файла и программно создать эти вспомогательные классы; это помогает избежать монотонности построения этих сопоставлений вручную. Который может быть ошеломляющим, когда вы получаете нетривиальный набор активов.

В моем проекте я бы структуру, как это:

/ProjectRoot 
    /src 

    /imgs 
     /132dpi 
      /unit1.jpg 
      /unit2.jpg 
      . 
     /160dpi 
      /unit1.jpg 
      /unit2.jpg 
      . 
     /264dpi 
      /unit1.jpg 
      /unit2.jpg 
      . 
     /326dpi 
      /unit1.jpg 
      /unit2.jpg 
      . 

я обычно есть интерфейс, все мои активы будут соблюдать, что-то вроде

public interface IAssetSet { 
    function get DPI():uint; 
    function get Unit1():BitmapData; 
    function get Unit2():BitmapData; 
} 

Сценарий будет работать скрип папки/файлы и создавать классы ActionScript в папке, например /src/assets. Такие вещи, как

public class AssetSet132dpi implements IAssetSet { 

    public function get DPI():uint { return 132; } 

    [Embed("img/132dpi/unit1.jpg")] 
    private var _unit1Class:Class; 
    private var _unit1:BitmapData; 
    public function get Unit1():BitmapData { return _unit1; } 

    [Embed("img/132dpi/unit2.jpg")] 
    private var _unit2Class:Class; 
    private var _unit2:BitmapData; 
    public function get Unit2():BitmapData { return _unit2; } 

    ... 

    public function AssetSet132dpi() { 
     _unit1 = BitmapData(new _unit1Class()).bitmapData; 
     _unit2 = BitmapData(new _unit2Class()).bitmapData; 
     .... 
    } 
} 

В коде инициализации, вы определяете, какое устройство вы работаете или прекомпиляцию только для конкретных устройств, а также экземпляра точек на дюйм вы хотите. Всюду в вашем коде вы просто передаете ссылки на IAssetSet и выясняете, что делать на основе IAssetSet.DPI.

Это один подход, но есть и другие.

Еще один подход - это хранить изображения исходного изображения на самом высоком DPI, а затем при загрузке приложения, уменьшать их в памяти до желаемого DPI и dispose() оригиналов.

Другой подход, который в наши дни является более жизнеспособным с Stage3D и фреймворками, такими как Starling и nd2d, вы можете уйти с тем, чтобы позволить графическому процессору, который действительно хорош в этом масштабировании, сделать большую часть тяжелого подъема, который действительно возможно с традиционным составом.

Я думаю, что если вы используете традиционный композитинг, то, вероятно, вы, вероятно, немного повысите производительность, используя активы, специально рассчитанные на то, что вам нужно, вместо того, чтобы постоянно динамически их изменять. Flash может быть немного странным иногда о восстановлении внутренних представлений этих активов в странные времена и производительности танков. Вероятно, наилучшим подходом было бы использовать Stage3D/Starling/nd3d, но если у вас есть нетривиальная кодовая база, вероятно, будет нетривиальная задача переключить механизмы рендеринга на этом этапе игры ...

По крайней мере, это мои два цента. Возможно, у кого-то другого был другой опыт.