Question

The situation is as follows. Currently i’m developing an AIR game that will contain plenty of bitmap assets. I’d like to target several tablets (iPad, Xoom, others) and, thus, am considering having the assets done in different ppi, so as to have more visual consistency across the devices. I’m not concerned much about the resolution, because i’ll be using scrolling for assets that don’t fit on the screen; but units, buildings, enemies should look pretty much the same regardless of the device.

The question is:

• can this be done and how (packager-based?)
• what would be the best way of doing this
• should i even bother?

The only thought that comes to my mind so far is to have an application file for each device being targeted (or ppi, actually), that pulls a big bitmap-registry that corresponds to the ppi of the device. The static registry class is essentially the same for all of these applications differing only in the filename that [Embed] points to (and the classname obviously).

Answer 1

I think you are on the right track, if you wanted to have specific sets of assets for each device type. The way that I’ve done this in the past is to use a rake script, but any make-like/ant-like utility that you are conformable with will do. Essentially, one of the tasks that runs before the project compilation is to dig through the file structure and programmatically build up these helper classes; it helps avoid the monotony of constructing these mappings by hand. Which can be mind-numbing once you get a non-trivial set of assets.

In my project I would have a structure like this:

/ProjectRoot
    /src

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

I would usually have some interface which all my assets would abide by, something like

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

The script would run scrape the folders/files and generate actionscript classes in folder like /src/assets. Stuff like

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;
        ....
    } 
}

In your initialization code, you determine what device you are running on or you precompile only for specific devices, and instantiate the dpi you want. Everywhere else in your code you just pass around references to IAssetSet, and figure out what to do based on IAssetSet.DPI.

That is one approach, but there are others.

Another approach, would be store embed your source images at the highest DPI and then on application load, downscale them in memory to the desired DPI and dispose() the originals.

Another approach, which is more viable these days with Stage3D and frameworks like Starling and nd2d, you can get away with letting the GPU — which is really good at doing this scaling — do most of the heavy lifting that really feasible with traditional compositing.

I think, if you are using traditional compositing, then you will probably seem some performance boosts using assets specifically sized to what you need, rather than trying to dynamically size them all the time. Flash can be a little weird sometimes about regenerating internal representations of those assets at strange times and tanking performance. Probably the best approach would be to leverage Stage3D/Starling/nd3d, but if you have a non-trivial codebase built up, it will probably be a non-trivial task to switch rendering engines at this point in the game…

At least, those are my two cents. Maybe somebody else has had a different experience.