Flash Animation
Last November I attended the Macromedia MAX Convention in New Orleans, and when I got home, I felt exhausted. I've learned a lot about Macromedia's progress in integrating Flash technology into mobile devices, and this integration can give mobile users a rich and compelling experience that is as impressive and personalized as the browser experience. The first time I saw something really impressive on my mobile phone, it was a lot to the phone itself. At the conference, Macromedia also announced the first Flash Lite content competition.
On the way home, I began to think about how we smashing Ideas to win the big game. When we got back to the office, we decided to find some mobile phones to create content for two games: games and animations. For the animation class, we decided to put our proud "2001" on the phone. "2001" is a two-minute animation of our mascot robot that buys candy from a very high vending machine. To watch the "2001" animation, click on the phone keypad below the Start text on the LCD screen.
At that time, we had some experience with equipment development: we had developed content for the Pocket PC platform and were familiar with Flash 4 ActionScript syntax, which is supported by the Flash Lite. But we do not realize how small the world has become. In this article, I'll share the experience gained by porting "2001" Animations to mobile phones (and winning the best animated content award). The techniques mentioned in this article also apply to creating new games and applications for mobile devices.
Flash Lite CDK (optional)
Flash Lite CDK downloads for Developers
Pre-installed Symbian 60 series phone with Flash Lite 1.1 player
Tutorials and sample files: download "2001" Animation from Macromedia Flash Lite exchange*
Prerequisite Knowledge:
This article is intended for developers with the basics of flash and flash animation. For an introduction to Flash Lite, please read
" development of best practices for Macromedia Flash Lite 1.1 content " or "Macromedia Flash Lite 1.1 Introduction ".
Flash was originally a Jivi (character) animation tool, compared to today's standards, the computer was very slow-14.4K is the standard connection rate. Not surprisingly, this unique content category is also suitable for mobile phones, and today's mobile phones are similar in many respects, such as bandwidth, memory limits, to desktop computers from 10 ago.
Smooth actions in Flash often require a higher frame rate to look smooth. You can see people using the rate of 30, 60, or even 100 frames per second to show the smoothing action. Try it on the phone, you can only see the intermittent display, this is not a pleasant experience.
Manual adjustment
The secret of my successful use of Flash Lite to create animations is called manual adjustment , which is to manually adjust each keyframe. Many movements in real life do not increase in equal increments, nor do they follow a softer curve. Even that is not what we perceive. You need to fool people's eyes so that the animation shows where the human eye expects it to appear, not where it is calculated mathematically. Whether you believe it or not, what we see in our eyes is often not true. Filmmakers, especially cartoon artists, have been using the phenomenon for more than a century. When an object moves at a speed that is not enough to deceive a human perception system into believing that a continuous action is seen, you need to use the so-called visual-resident phenomenon to let the eye see the movement it expects to see.
In the category of motion graphics, this means: As usual, start with each frame, and then manually adjust the animation by frame to get the effect you want the user experience to be. It's a lot of work, but it's worth it.
Similarly, you must adjust your thinking when creating animation gradients for your mobile device. For example, a gradient that shows transparent objects being accelerated on the screen works fine on the desktop display, but the games are slow on the phone, destroying the effect of smoothing the gradient. In this example, you have to focus on the most important part of the effect you really see. What's most likely to happen is that you won't even notice anything transparent moving. Let's say it's transparent, because it's going to be transparent in the end. However, when the object is moved, you see a color block.
The first step to make this gradient smoother is to use softer motion effects-for example, to dilute the object's color or to reduce its brightness, and only one frame of transparency is set when the gradient is complete. For smooth animations, objects may still be overly complex on the graph. Therefore, you may only be able to use a flat color block to complete the actual gradient. What you create here is called obfuscation in the cartoon terminology (see Figure 1). You create the eye's perception of motion, not the object moving at FPS. Do not change transparency or use other graphic effects in gradients; This slows the playback of animations. For more information on tips, read Chris Georgenes's article " Create a real blur effect *".
Figure 1: The head is disconnected from the body, everything is squashed, and everything is restored to its original form.
You may not believe me unless you have tried it before. You might think that the user will notice that the object moving on the screen is not the real object. Rest assured that the user will not notice (if you do it right)!
You need to be aware that what you create here is motion, not a series of static images.
Exaggerated
Another useful technique that can be borrowed from cartoon animations is exaggeration . With this technique, you can create animations that feel more "natural". Exaggeration can be a part of ambiguity, or simplify the gradient from blur to real object. For example, try the following exercise: Ask someone to quickly use their fingers to an object on the other side of the room. Notice where you think his hand is pointing. Once again, you'll notice two things: when the arm moves, you don't see it moving at some speed-it's blurry. When the arm is stretched out, the hand is closer to the object at a given moment than the actual distance and then restored to its real position.
In the above example of moving an object in a Flash animation, you might want to move the object a little farther than the distance should be moved. Then, put it in the right place in the next frame-think of its motion as a rubber band bouncing back in position. Or, when you create a magnifying effect, make the object slightly larger at the end of the gradient, and then set it back to the size you want (see Figure 2).
Figure 2: Bigfoot becomes larger, and then returns to normal size.
You can go further by adding Flash effects: Inserts a frame where the object is completely gray. Or, in a frame, add a white rectangle to the object. This "flicker" attracts the attention of the beholder, but you can only see what's there now, and not see how it got there. In other words, it helps complete the gradient.
If the first attempt is unsuccessful, don't lose heart-it takes a few more tries. Don't forget to test your effect on the target device.
Finally, when all is done, you will get a smooth animation of 10 to FPS on your mobile phone. You can even apply these techniques to your desktop projects.
Before you begin, you must understand how small the target screen is, not just the resolution, but also the physical dimensions. The target screen you designed is probably as big as a half card.
Technically, the screen size of the Symbian 60 series phone is 176 x 208 pixels, which is only slightly larger than other phone screens with Flash Lite features. Of course, if your application is not running in Full-screen mode, you can use less space.
It should be noted that the cell phone also uses a vertical aspect ratio. Desktop content usually uses a TV-like 4:3 or 16:9 aspect ratio of the movie. On a small device screen, you do not want to waste a pixel, so you must carefully consider the design of the animation to maximize the use of limited space.
Don't be fooled by the resolution of the device; This value is actually not low. However, because of the higher dots per inch (DPI), each pixel is smaller than the desktop display. You can easily see this by comparing the same size Flash movies played on mobile phones and desktop monitors. Depending on the display, the cell phone displays only 70% of the size of the screen.
The changing lighting situation complicates the problems you face. Mobile phones are everywhere-indoors, outdoors, at night, during the day. Whether it's for mobile Flash content as a whole or specifically for animations, this means you have to be bold-don't focus on tiny details. Users will not even notice a small color gradient unless they are unable to determine what they are seeing. Use comparisons as much as you can. Even if it makes your color-sensitive eyes uncomfortable, your users will certainly thank you.
For animations, use close-up lenses while avoiding the use of panoramic views (see Figure 3). The small screen will lose a lot of detail, even if your animation looks great on your desktop computer, and if you don't see it on your phone, users won't be able to appreciate it.
Figure 3: A close-up lens allows you to immerse yourself in the content.
The same law is true for the work itself-the simpler the better. Cartoon image is always more lovely than the real image, the image of the transformation process to abandon the details. If you want to cram more into a small screen, you'll lose more. Instead, focus on what really matters, and don't take care of the space filler.
Simply say the test before proceeding. Frequent testing on the actual device is critical. If possible, also test animations on other devices, because the device is different in performance, color depth, and sound effects. You will not experience memory problems on your desktop computer, or even use the emulator in Flash to see the actual device performance. It's important to note that testing can be pretty painful because you can't see how much memory is actually being used. Unfortunately, this means a lot of repeated experimentation. The content cannot be said to work properly on the device unless it has been tested on the target device. Developing for a device sometimes means a lot of tedious work. But, thinking about what you can create on these tiny devices today, you realize that effort is rewarding.
In conclusion, you should focus on testing the animation (or application) on the target device. Don't wait for the end to be caught off guard.
You can create from scratch, and the techniques provided in this article will help you get a good start. However, one of the advantages of Flash is that you can reuse content across platforms-just don't be too arbitrary.
For the "2001" animation, we started by asking ourselves: "Can we make our original animation work on the phone?" "Initially, we thought the length of the animation was a challenge. However, the original animation itself meets the following key conditions, which are important for animations created on the desktop to work on mobile devices:
Role animations change only a small area on the screen
Most of the time is a medium distance lens and close-up, with only a few panoramic views.
Limited Full-screen Motion
Full screen movement can be removed without affecting the content
A simple background
Symbolic reuse, so that animation can be optimized
Our project proves that a two-minute animation can also be ported to the phone. Its file size is still less than 300K. In this way, it can be suitable for distribution in 2G or 2.5G networks, but that is not our goal.
When deciding whether to reuse content, you need to consider whether the content will play on the phone, whether it can accommodate the size limit, and other specifications that you want to meet.
If you can reuse content, it's a good place to start. But even so, you still need to do some work to run on your phone.
While our "2001" animations are thought to be ideal for playing on mobile phones, they are far from perfect. It creates mobile paintings for desktop computers. The size of the file is important when authoring, and the most important measure is to keep the file small enough so that people who use dial-up connections can access it without any problems. It requires very little optimization compared to the memory limits on mobile phones with Flash Lite features.
In fact, we don't have much of a performance problem; we just need to make some adjustments, such as removing the full screen of vending machines and replacing them with static pictures. From this perspective, the original animation is really good for reuse.
The two biggest problems we've encountered are sound and memory.
The device is slower to handle than a desktop computer, which is known to all. For Flash content, this means optimization, optimization, and optimization. For example:
- The project starts with a frame rate of 10 to FPS.
In addition to having the Flash Lite player handle it, a lower frame rate can also get a smaller file size. Remember, each symbolic keyframe will add 12 bytes to the SWF movie. That doesn't sound much, but it's easy to accumulate, especially for animations.
- Place art in symbols, not on the main timeline or in groups.
Select Modify > Shape > Optimize optimization symbols, or manually optimize using subselection tools. Remove unwanted points and any hidden shapes and symbols. This is cumbersome, but it will make your content run better and reduce the size of your SWF file.
- Simplifies animations.
Don't let too many things happen at the same time. Avoid performance killers such as alpha transparency and gradient. Although they can make the animation more beautiful, but also affect performance. And, on the small screen of the phone, a lot of the effects will be lost, and it might even look worse. On a small screen, simple graphics often look better and have better performance.
- Avoid panning and alpha fading.
A short time (5 frames) fade on a static background is no problem. If possible, use only graphics, and remove lines, including outlines around the shape. For Flash, line rendering is more complex and therefore slower. If necessary, create outlines using graphics.
The same points apply to desktop animations, and if you ignore these best practices when creating animations for mobile devices, you will soon experience problems.
For animations like "2001", sound is a very important element. Removing the sound from the file will save us a lot of time, but the experience will be very different.
The first major challenge we have encountered is to have the animation work on the phone-with sound effects. The work is relatively simple when the sound is not used, but when we add the sound effect, as soon as we start playing the animation, we get an out-of-memory error.
The importance of length
To solve this problem, we first divide the animation into pieces, place the sound effects in the appropriate movie clips, and then place them on the main timeline. Then we'll just add a piece of sound to a corresponding movie clip and then test it on the phone-so that we can work!
However, this does not solve all the problems. Sometimes, an audio fragment is across several clips (for example, the title music), and it is not easy to match the time line exactly with each timeline. So we put the whole longer part in the first clip and use a blank frame to lengthen the timeline. Unfortunately, after publishing to the device, the animation has just run half of the mobile phone is out of memory.
We have concluded that the simultaneous use of sound effects in two clips can cause problems. We removed the sound from a clip to avoid overlapping with the first longer sound effect-no problem now. Of course, now we're missing a piece of music, so we stuffed it into the first clip--surprisingly, it's able to play! We don't know the exact reason; The only conclusion is that it's not a good idea to play sound in two clips at the same time.
We haven't been able to figure out why we can't put the entire channel on the main timeline. Our guess is that the Flash Lite player will cache the entire time line sound at a time, and it's too much to handle all the sound effects at once. However, Flash seems to deal with memory separately for each movie clip, which is why the aforementioned segmentation techniques are successful.
Even with this technique, we still occasionally run out of memory when adding sound effects to animations. We solve this problem by optimizing the animation in one scene and one scene. Sound and animation do share memory resources, so only simplifying animations makes it possible to add more sound effects. For more information on optimizing sound effects, see Frank Gelat's "Thekillersound technique:optimizing Digital Audio in Flash Lite".
And then the volume.
To solve these problems, we can begin to solve some other sound-related problems. The first is that the volume on the phone is too loud and we have to lower the volume. You must test yourself to find the right volume, and our experience is to reduce the volume to 50% of the normal volume on the desktop.
The sound effect begins with a bass. On the phone, we can only hear the crackling sound, we have to remove this part. Our conclusion is that the phone's small speakers cannot play the sound of that frequency.
But it's also good-even if the audio quality is much lower, the difference on the phone is small.
Sound playback and screen display share processor resources. So when the sound starts to play, you may notice that the animation has a delay-this is when Flash is starting the sound device.
In the scene where the robot kicked the vending machine, we encountered a special problem. The robot will freeze for a second and the sound of the vending machine will start playing. The way we solve this problem is to play a silent sound from the very beginning of the scene. In this way, Flash starts the sound device before the scene starts, and the user does not notice the delay.
Note: on the desktop, we sometimes loop through a two-frame silent clip to keep the sound device working and avoid this kind of delay. Unfortunately, this approach does not work for Flash Lite. First, it slows down the playback speed. Second, when playing sound effects in two clips, an out-of-memory alarm is generated.
There are also side effects of sharing processor resources with animations: a large number of animations or scene fragments can cause sound effects to be intermittent, like a small split-popping sound. To resolve this problem, you can try to avoid the occurrence of a particular situation, or mitigate the burden of a gradient on the CPU.
On the Nokia 6600 phone, we also noticed a crackling sound after the sound was finished, even if no subsequent playback occurred. We are still looking for a solution to the problem. This seems to be a problem with the device, maybe it's our phone. Note: Not all the devices can play all the sound effects! Flash Lite can embed sound effects into different formats (MP3, ADPCM, MID, or original format) for better cross platform distribution capabilities. It can even embed multiple candidate sounds into the same file, and then choose the right sound playback. For more details, refer to Nader Nejat's article for the use of sound effects in Flash Lite 1.1 .
Bitmap images can improve performance because they have been rendered. It should be noted that they often bring large files. For a complex background, there is no choice but to use a bitmap image, because animations on complex vector backgrounds can be very slow. In fact, on a small screen, a lot of details will eventually be lost.
On the other hand, the vector background can be scaled without losing the image quality. This is useful when you are reducing the size of a file, or when creating Flash Lite content for multiple screen sizes. To make the bitmap display work best, they must be displayed in a scale of 100%, without scaling.
For our "2001" animation, we have optimized the original vector background (see Figure 4).
Figure 4: A simple vector background helps improve the performance of animations.
They are simple enough and can be used in different sizes. However, on the blinking screen, we are using the 2K PNG file (see Figure 5). You cannot create a small enough point in Flash. At the same time, using PNG files does not result in a loss of quality-JPEG either must use the size of a vector graphic or require a large amount of processing.
Figure 5: bitmaps can improve performance and file smaller files.
In the selection of bitmap images and vector graphics, there is no need to select only one and discard the other-two kinds of features, can be selected according to the actual needs.
The biggest enemy in creating Flash Lite content is not the performance, but the lack of memory. In this article, I've mentioned this issue a number of times, and the time you spend on the wrong schedule is likely to be used to deal with the problem. First, you need to realize that the file size is not equal to the amount of memory used. File size is an important metric, but it does not equal the amount of memory required for your movie to run. For example, JPEG images are compressed into a SWF file, but they must be restored to their original size to be displayed. The same is true for sound files-the sound files that are compressed in MP3 or ADPCM format are much smaller than the original sound files, but must be restored in their original format when playing. Other objects, such as movie clips or code, will also require more memory at run time than are stored in a SWF movie.
In addition, you can create more objects when the movie is run, for example, to copy a movie clip. Each new object uses the extra run-time memory, but the file size does not increase.
This does not mean that the size of the file is not important; You may still need to limit the size of the file to meet the specification, while the wireless receive file has limited bandwidth (similar to the bandwidth of a 14.4K modem) unless you are fortunate enough to develop the 3G network. You also need to keep in mind that most handsets have very limited storage capacity.
"2001" in the Memory space
On the file size, we put "2001" animation on the phone no problem. We'll put it on the phone and open it. However, as soon as we press the play key, the memory is not enough. Flash Lite players need more memory to play animations than to load animations.
As discussed in the previous audio section, this is largely about music, and the way we find it is to segment the animation, each segment into a different movie clip, which helps Flash Lite players manage memory better.
In a linear animation, gotoAndPlay
There are no duplicate clips or code except for a few actions, in which case the run-time memory depends entirely on how much memory the current object is using on the stage, how much memory is used for sound effects, and how Flash handles objects that are not currently in use.
Unfortunately, we don't have the tools to see how memory is handled. However, I can make some guesses: for sound effects, as mentioned earlier, Flash loads and extracts all the sound effects of a particular movie clip and places it in memory so that you can start playing it right away, no matter what frame you go to. For each nested clip, Flash completes the work. That's why there's so much difference between splitting music into multiple movie clips.
It's very similar to putting all shapes, outlines, and graphic symbols in one movie clip (the main timeline of the FLA file is also a movie clip): Whenever a movie clip appears in a keyframe, it loads everything into run-time memory. The more types of objects that Flash needs to track, the more memory it needs. Again, this is not directly related to the size of the file, which is associated with the number and complexity of the objects.
This explains why the animation itself works fine, but as more and more audio is added, there will eventually be a lack of memory. However, when we optimize the animation by blending 10 symbols into one, it works again. The player needs to track fewer objects, so although the file size has barely changed, it requires less run-time memory.
This may sound like a bit of a mystery, but unless we have better tools to analyze how the memory works, we can only guess at this moment.
Memory points
Here are some tips for optimizing animations in both memory and file size at run time:
- Place the graphic in a symbol and optimize it by selecting Modify > Shape > Optimize or by using the Subselection tool. Removes all nonessential points.
- Use graphical symbols to represent shapes and lines, and to use movie clips when you nest symbols.
- Graphical symbols render faster because they are not "active objects" at run time. When exported, nested (static and animated) graphical symbols are torn apart, and each nested symbol is exported with 12 bytes reserved for each keyframe of the parent object.
- On the other hand, movie clips are exported only once, and the child content is complete. 12 bytes doesn't seem to be much. However, if you have 12 nested symbols, you need to add about 150 frames for each keyframe that uses nested graphical symbols.
In comparison, movie clips use only 12 bytes on each keyframe after using 150 bytes for the first time. This doesn't sound like much, but if you use more than 10 frames (for example, a tween), you can save 1.2 KB file sizes. This reduction in file size is also reflected in the small number of objects that Flash needs to handle. But when the SWF plays, you see exactly the same object. This is because Flash tracks movie clips (instead of each nested graphic in each frame), and the movie clip is responsible for tracking its own content. If no objects change, there is no need to increase the use of memory.
Don't forget, graphical symbols and movie clips have a significant difference in functionality after export. When I first discovered this, my initial reaction was to use only movie clips. However, because the movie clip is the active object, it has resource occupancy at run time. If you use movie clips for simple graphics (with no nesting, only shapes, outlines, and text), it won't help, but it will consume more run-time memory.
Don't forget, motion tween is exported as a separate keyframe; you don't have to save anything compared to each frame using a keyframe.
Summarize
In this article, you learned a variety of techniques to ensure that Flash animations work correctly on your phone and perform well. I've shared some tips on how to overcome the limitations of your phone's file size and performance, including avoiding audio and memory usage errors. I also introduced you to some details on how to optimize animations in terms of memory usage, file size, and performance. Now you are ready to start your own project.
At this point, you might think, "is all this trouble worth it?" "The answer is yes." When you plug a two-minute animation into your phone, you'll be able to avoid half the problems we're experiencing. For us, this is a challenge that cannot be rejected, and we have succeeded. I hope that the experience we have gained will help you.
If you haven't tried to put your first animation on your phone-what are you waiting for? Find a compatible cell phone, load the Flash Lite player, and start! You can download the "2001" Animation from Flash Lite Exchange to your phone.
When I see your own content on the phone, you must be a Flash Lite expert.