渲染游戏动画的三种方法

　  游戏开发对游戏中的动画模型要求很多，游戏里的模型必须做出完整的场景：包括所有的花草树木，所有的房子，移动的景色都要做出来。因为游戏是玩家互动的，玩家什么地方都有可能走到。

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

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

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

　　要求-预备知识

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

　　Stage复制

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

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

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

　　1.为你的动画角色创建一个预渲染的子画面表单或在运行时将你的影片剪辑时线作为位图数据进行高速缓存。

　　2.为将子画面表单划分为个体可访问的动画帧编写代码

　　3.创建一个帧事件或定时器驱动的函数以控制动画的播放。

　　动画模型是在游戏中移动的对象，它们能够表示你的角色、车辆、怪物和任何其它互动对象，它们不是明确地在背景中画出的对象。

　　Stage复制的优点

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

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

　　Stage复制的缺点

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

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

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

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

　　何时使用stage复制

　　Stage复制功能最适合要求频繁重绘整个屏幕区域的游戏，重绘的原因是游戏背景改变(例如2D侧滚动条)或大量物体在屏幕上频繁地移动(例如流星式的电子游戏)。当游戏工艺图是带有简单和短暂的动画序列的像素画(例如任天堂式的马里奥游戏(Nintendo-styleMario)或**人游戏(BomberMan))时Stage复制特别有用，因为这些类型的图形通常要求极少帧来维持流畅的动画画面，因此只需要将较少的帧作为位图进行高速缓存即可。

　　部分复制

　　部分复制是一种将使用Flash显示列表的优点与复制的性能优势结合在一起的渲染方法。部分复制和stage复制的不同之处在于，部分复制不需要将像素复制到一个单一stage画布位图中，而是将它们复制到一个个体模型的位图画布中。利用这一方法，游戏模型位图画布可以添加到Flash显示列表中并且能够来回移动(使用其x和y属性)、旋转和缩放，正如你通常在FlashProfessional中创建动画一样。然而，该模型的动画状态(例如行走和攻击)需要使用上面描述的方法进行复制。

　　图2.将子画面表单的像素复制到模型位图画布中

　　动画模型是在游戏中移动的对象，它们能够表示你的角色、车辆、怪物和任何其它互动对象，它们不是明确地在背景中画出的对象。

　　部分复制的优点

　　部分复制的显著优点是它能够提供高性能的模型动画并且仍然能够管理传统Flash显示列表的模型。如果你能够在模型的位图画布上使得动画流畅，则你可以旋转该模型，而不会产生处理位图时通常出现的可见失真。因此，你不需要像使用stage复制一样，存储每个模型面对的许多方向的位图。在低于一定阈值的情形下，部分复制对系统产生的负荷小于stage复制，因为只有那些移动或变更的物体需要重新绘制，而不是整个stage。

　　注：你可以为stage复制规划重绘区域以便最大限度地提升性能，尽管相应的编码要比部分复制更为复杂，因为FlashPlayer能够自动为你处理重绘区域。

　　部分复制的缺点

　　与stage复制一样，根据使用的子画面表单的数量和用于存储它们的方法，部分复制将增加文件尺寸、内存使用率或CPU开销。与全stage复制相比，部分复制还将消耗更多内存，因为每个模型需要一个独立的位图容器。最后，当你在屏幕上同时添加足够多的模型以确保每帧的全屏重绘时，部分复制的总体性能要劣于stage复制。

　　何时使用部分复制

　　当你不需要频繁重绘整个显示屏幕或旋转你的游戏模型比存储预旋转状态有利时，部分复制是stage复制的很好替选。

　　位图骨骼模型

　　骨骼是由躯干部件组成的图形的一个骨架框架，当随时间重新配置时，骨骼能够用于游戏角色的动画制作。与为每帧的模型动画绘制一个唯一的示意图不同，骨骼模型被绘制为一系列躯干部件，就像你的骨骼一样，它们根据相互之间的关系运动。通过对手臂、大腿、头和躯干进行定位可以实现动画效果，例如，在一个时间线的一帧中，以不同的姿势在后面的一帧中对它们进行重新定位，并且使用两者之间的动作将腿从起始姿势移动到结束姿势。

　　图3.骨骼由躯干部件图像组成，这些图像的运动可以产生动画效果

　　骨骼模型通常在桌面计算机中运行性能良好，不论它们的部件是由矢量组成，还是由位图图形组成。对于移动设备来说，使用位图部件肯定是最佳选择，因为这样移动和横切位图涉及的计算较少。

　　骨骼模型的优点

　　相对于复制来说，骨骼模型能够体现两个明显的优点：较小的文件和定制功能。它们不会导致大型文件，因为你需要在文件中存储的图像仅仅是模型的躯干部件;而所有的动画帧均源自这些部件的运动轨迹。如果所有模型的动画均位于一个单一的时间线上并且帧与帧之间没有间隙，则FlashPlayer将为每个动画重新使用图像而不是重新创建它们，这意味着不用担心产生较多的例示开销和收集较多的内存垃圾。这使得你在无需在你的文档中存储额外的子画面表单以及将附加的位图数据加载到内存的情形下，获得较长时间和更为平顺的动画。此外，你实际上无需增加文件尺寸或内存使用率即可将新的动画添加到模型中(例如交替攻击或运动动画效果)。创建新的动画也非常简便，因为你不需要图解新的帧;你只需要以新的姿势重新定位相应的部件并且对相应的差异进行补间动画即可。

　　由于模型采用组件结构，利用不同标记、装甲和武器定制模型是非常简单的操作。例如，如果你希望在你的模型装甲上指派一个具有特定颜色的肩垫，则你可以对个体的部件直接进行着色。这对战略游戏特别有用，因为你必须在战略游戏中指示每个模型属于哪支队伍。

　　注：复制的图像也可以进行修改以便显示队伍的颜色标记，尽管这一过程更为艰难，因为你在使用过滤器有选择地利用其它颜色替代指派的颜色方面受到限制。

　　骨骼模型的缺点

　　尽管骨骼模型支持较小文件并且通常易于处理，但它们与复制模型相比，在你将越来越多的模型添加到显示列表时性能表现较差。这一性能差异的原因主要是骨骼是由大量个体的部件构成的。复制模型在相应的stage上只需一个单一的位图对象(或它们自己是stage画布位图的部件)，因此它们在进行实际的图形渲染时使用少得多的资源。注意，这一性能降低是明显的，即使stage上的大多数骨骼模型没有移动。真正重要的参数是显示列表中的位图总数，而不是移动位图的数量。因此，应该将模型的空闲姿势(idlepose)(未激活的、不移动的位置)作为一个独立的位图图像进行绘制，并且当你不需要激活它的动画效果时，可以将它放置在stage上以替代骨骼模型。

　　骨骼的复杂性-即移动部件的数量-也能够降低动画性能，尽管复杂的复制帧不会这样(因为它们没有部件架构并且没有叠加问题)，因此必须确保在你的骨骼动画中删除或隐匿未使用的部件。

　　何时使用骨骼模型

　　通常，骨骼模型能够为那些在屏幕上同时具有大量不同模型类型，但这些模型不一定需要在相同时间激活动画效果的游戏提供良好解决方案，例如回合制战术战略游戏或角色扮演游戏。当你需要利用独特的队伍标记或选择性的武器和装甲定制模型时，它们特别有用，因为可以个别地修改它们的组件。

      下一步阅读方向

　　相信存在一个单一的最佳实践方法可以提供最优的动画性能而不论你将创建的什么类型的游戏是一种非常诱人的想法。 然而，正如你已经看到，每种用于渲染你的游戏动画的方法均具有其自己的优势和缺点，这使得它或多或少地适合你正在开发的游戏类型。

　　在你知道一些你可以使用的不同技巧之后，现在该到考虑你将创建什么类型的游戏以及确定哪种方法最适合你希望获得的结果的时候了。 应用程序是为对下载时间(及文件大小)很看重的手机开发的吗？或你正在开发的一个iPad应用程序的速度性能要比下载的文件大小更加重要吗？ 你的游戏是否包含简单像素图像以便stage复制功能可以最大限度地提升游戏的速度？或你是否计划使用具有大量动画的许多模型，对于这些模型来说，骨骼解决方案可能是最佳方案？

      所谓学无止境，如你说见，每种用于渲染你的游戏动画的方法均具有其自己的优势和缺点，你总要自己判断出哪一种适合你的游戏，或者学习更多的方法来克服这种缺点，才能使你制作出来的模型趋于完美。