Optimizing your content for OTA delivery

Graphics

Especially when using bitmaps, graphics almost always tend to be the biggest contributing factor to overall application size. In order to optimize graphics, you need a graphics authoring tool like Adobe Photoshop or Macromedia Fireworks as well as some understanding about file formats and their good and bad features.

Sometimes it's a good idea to use vectors instead of bitmaps, because vectors are mathematical functions, not concrete pixel-by-pixel graphics like bitmaps. Just remember to check that the vectors don't tax the device too much, and that the application runs smoothly on the device.

For more information on bitmaps vs. vectors, check out this Flash Lite article on LiveDocs: Bitmap versus Vector Graphics.

JPEG, GIF, and PNG

JPEG is a bitmap image format that uses lossy compression (the more you compress, the more image quality and data you lose) and is usually most suitable for photographs or similar pictures with many colors.

GIF is a bitmap image format that uses lossless compression (you don't lose any data) and is usually most suitable for drawings or blueprints with a limited number of colors (256 or fewer).

PNG is a format that uses both bitmap and vector graphics, and is often the best choice with Flash Lite.

It is somewhat dependent on the file format, but when optimizing, you have control over the number of colors (color depth), compression strength, and image resolution (see Figure 1): 72 dpi for mobile devices and computer screens, around 120–150 for newspaper quality, and 300 dpi for print quality, etc.

Figure 1. Fireworks optimization window showing a single JPEG image that has been compressed from 37KB to just over 5KB without a significant loss of quality

Tip: You might encounter a problem with big bitmaps that work with older Nokia mobile devices but cause an error in newer or high-end devices. The problem lies in color depth. Because high-end devies have better screens, they are able to display a larger number of colors, thus consuming more memory. Try reducing the color depth.

Hard-coding

Always code in a portable way. If you draw graphics by using code, hard-coding something is a bad idea because it is always device-specific.

Here is an example. To draw a full-screen rectangle using code, you might use the following:

//This code draws a rectangle that fills the entire screen

// hard-coded
// works on devices that have screen size of 176x208 pixels
this.createEmptyMovieClip("rectangle_mc", 1);
rectangle_mc.beginFill(0x0000FF, 30);
rectangle_mc.lineStyle(3, 0x0000FF, 100);
rectangle_mc.moveTo(0, 0);
rectangle_mc.lineTo(176, 0);
rectangle_mc.lineTo(176, 208);
rectangle_mc.lineTo(0, 208);
rectangle_mc.lineTo(0, 0);
rectangle_mc.endFill();

or this:

// portable
// this example asks for the screen size from the device
screen_width = System.capabilities.screenResolutionX;
screen_height = System.capabilities.screenResolutionY;
this.createEmptyMovieClip("rectangle_mc", 1);
rectangle_mc.beginFill(0x0000FF, 30);
rectangle_mc.lineStyle(3, 0x0000FF, 100);
rectangle_mc.moveTo(0, 0);
rectangle_mc.lineTo(screen_width, 0);
rectangle_mc.lineTo(screen_width, screen_height);
rectangle_mc.lineTo(0, screen_height);
rectangle_mc.lineTo(0, 0);
rectangle_mc.endFill();

Both work on a mobile device that has a screen size of 176 x 208 pixels. However, the first example is not easily portable because the placement is defined in coordinates that are specific to a certain screen size.

Contrast

All mobile devices differ from one other, and screen contrast and brightness vary wildly. Due to these differences, the way colors are perceived by the user differ as well. Use stark contrasting colors, experiment with colors (for example, if the game's mood is supposed to be dark and grim, test suitable colors to find what works best), and always test on the target devices in broad daylight.

And yes, it's a must to test on every target device in order to spot the anomalies. It's no use if your applications look good on your own mobile device with your profile but bad on every other device. What does this have to do with OTA delivery? If the end users don't like what they see, the impact on you and your business will be inevitably bad.

Tip: Avoid using many overlapping transparent PNG layers, as the graphics may start to flicker.

Animation

The basic thing to keep in mind when creating animations is that mobile devices are not desktop computers or consoles. Using many complex animations can easily bring a mobile device to its knees.

When making animations, or making single images called sprites that form the animation, always look for a solution that has the fewest frames possible—meaning fewer kilobytes and/or less taxation on the mobile device's CPU.

We recommend that you use tween animations (motion and shape) to save time and kilobytes. The most efficient way to make animations is coding them using ActionScript. The combination of these two techniques is by far the best solution when applicable.

Figure 2 shows both bitmap and vector sprites (single images from an animation). The top row of sprites from our Half Breed game has 32 colors, and the second row of sprites from Maniac Dancers has nine colors. Because of the use of alpha transparency and gradients in the third- and fourth-row vector examples, the sprites have more kilobytes than the bitmap sprites. For more information on bitmaps vs. vectors, check out this Flash Lite article on LiveDocs: Bitmap versus Vector Graphics.

Figure 2. Effect of gradients and alpha transparency on file size in bitmap and vector sprites

Tip: There is at least one graphics handling bug that can affect optimization possibilities. Flipping transparent PNG images doesn't work correctly on all devices (at least on the Flash Lite 2.0 player's developer version). Flipping transparent PNGs doubles an animation's size because you're not able to use the same image for both orientations (like animation to left and right).

Video

Video editing should be done in a video editing program like Adobe Premiere. The Flash Lite 2.x player can play any video format supported by the target device. Because the device itself decodes and renders (and even streams) the video, we can't provide a general guideline for which video format to use. Check with the manufacturer or use ActionScript in your application to find out which, if any, video formats are supported and then serve the right one accordingly.

Tip: Videos tend to involve large file sizes.

Page 4 of 5

Previous Page

Next Page