Flash在移动游戏中渲染动画模型

    动画模型是在游戏中移动的对象，它们能够表示你的角色、车辆、怪物和任何其它互动对象，它们不是明确地在背景中画出的对象。 它们是不仅能够在屏幕上移动、而且在移动过程中栩栩如生的对象。 例如，一个不仅能够水平方向移动、而且还能够移动其手臂和大腿作为动画的一个部分的行走游戏角色是一个动画模型。 动画模型能够将你的游戏带入栩栩如生的世界。 只有少数例外，它们也是你的游戏应用程序中的性能要求最高的元素。

　　Flash Professional 可以支持两种类型的图形：矢量和位图，它们能够用于渲染你的动画模型。 矢量 图形具有较小的文件尺寸并且在无明显失真的情形下缩放到任意尺寸，但它们需要强大的处理能力支持。 除非你的游戏使用非常简单的矢量图形或在任意给定时刻在显示时仅包含很少的矢量图形，否则存在的风险是使用矢量图形创建的动画游戏模型将在移动设备中显示比期望少一些的内容。 位图 图形具有较大的文件尺寸并且需要更多的内存。 它们也不能像矢量图形那样平顺地缩放，但它们能够通过中央处理器快速地绘制到一个显示画布或通过移动设备的图形处理器在显示列表中来回移动。 通过适当地使用位图驱动的动画，你可以显著地增强动画模型的性能，这样你的游戏将能够平顺地运行，而不论你使用的设备是高端的PC浏览器、移动设备或笔记本电脑。

　　本文讨论使用下列位图图形渲染你的游戏动画的三个方法：stage复制（stage blitting）、局部复制（partial blitting）和 位图装备模型（bitmap armature model）。 它引入了每个方法的基本概念、使用每个方法的优点和缺点以及对何时使用每个方法以便你可以确定哪种技术最适合你的游戏的建议。

要求 - 预备知识

　　利用Adobe Flash 开发游戏和创建动画的经验对充分理解本文非常有帮助。

Stage复制

　　复制（Blitting） 是从一个位图（源位图）复制像素数据到另一个位图（目的位图）的过程。 利用stage复制（stage blitting）功能， 目的位图可以成为你的显示画布（display canvas）, 它是一个单一空白位图，用来表示游戏用户看到的整个可视区域（你的显示stage）。 源位图是一个子画面表单（sprite sheet ）（也称为平铺表单），它是划分为相同大小单元的图像，每个单元表示动画序列的一个单一帧。 如果你把你的子画面表单看作一个绘画者的调色板，那么复制操作就像你的计算机处理器先在你的动画帧上浸蘸其画笔然后在画布上精确地复制该动画帧。

图 1.子画面表单位图的像素被复制到stage 位图画布上

尽管用于实现stage复制功能代码的描述超出了本文范围，但相应的基本步骤如下所示：

1.为你的动画角色创建一个预渲染的子画面表单或在运行时将你的影片剪辑时线作为位图数据进行高速缓存。
2.为将子画面表单划分为个体可访问的动画帧编写代码
3.创建一个帧事件或定时器驱动的函数以控制动画的播放。

Stage复制的优点

　　由于源位图数据使得在内存中能够方便地获得整个动画序列，故与传统的Flash显示列表相比，在屏幕上立即对大量游戏模型进行动画制作时，复制功能可以提供令人惊奇的性能。 此外，如果你对相同模型的多个复制进行动画制作，则stage复制的内存效率也很高，因为每个模型仅在RAM中存储一次。 计算机能够快速地在相应的"调色板" 中进行浸蘸操作以便在屏幕上绘出新的模型，而不会因为例示新对象或在子画面和影片剪辑的互动属性中预留过多的内存产生额外的开销。

　　复制功能的另一个优点是你可以不依赖于你的应用程序的帧速率来控制动画的刷新率，因为复制功能不包括时间线。 这使得你在设备的帧速率低于期望值时能够跳过重新在画布上绘画的操作，这样它能够与游戏事件或与多玩家游戏中的其它用户保持同步。

Stage复制的缺点

　　Stage复制的最大缺点是编程更加困难，特别是在你已经习惯使用Flash 显示列表的情形下。 记住，利用Stage复制功能，没有显示对象能够处于Flash Player 控制的画布位图之外。 如果你需要你的模型能够进行点击操作，或你需要以任何方式对它们进行旋转、缩放或分层，则你需要编写自定义代码以便添加这一功能或使用具有Ginger*、Flixel*或 Push Button*等位图动画功能的第三方框架。

　　复制功能的另一个需要考虑的因素是在每次显示过程中你需要多少种类型的模型。 每种你希望复制的模型必须作为位图数据存储于RAM中，这样在同时制作大量不同模型类型的动画时能够快速地消耗可用内存。 考虑一下，一个在Flash Player 中以位图数据存储的100x100像素的图像大约使用40KB的 RAM，因此一个由400帧组成的动画游戏模型将占用大约16MB空间。 如果有20个模型，则应用程序将需要320MB的 RAM空间，该空间仅仅用于存储动画必需的位图数据，除了这一RAM空间之外，你还需要管理游戏的其余部分。 在如上所述的极端情形下，你必须将你的子画面表单划分为更小的动画单元，以便只有你立即需要的序列存储到RAM中，但这将引起额外的开销以便创建和销毁位图数据实例。

　　根据你创建你的子画面表单的方式，你游戏的初始加载时间性能或文件尺寸将受到损害。 如果你将你的动画预渲染为子画面表单图像，则你的文件尺寸将增大。 如果你在运行时对你的动画进行高速缓存，则你的游戏加载时间将增加。 如果你有大量的动画，则存储预渲染的子画面表单将显著增加你的应用程序的文件尺寸。 例如，我开发的一款游戏具有21角色模型，每个模型具有大约400帧动画。 将模型以子画面表单的形式而不是以影片剪辑矢量的形式进行存储使得文件的尺寸从2MB增加到40MB。 相反地，在一个移动设备上，每个模型在运行时对相同的动画进行高速缓存可能需要15-20 秒的时间，或初始加载游戏的总体时间将超过5分钟。

　　注：通常，必须针对你希望你的动画模型面对的每个方向存储附加的位图数据，因此当给这些平衡成本乘以系数时，必须确保将你的总帧数乘以方向的数量。