原文作者：Jake Simpson
译者： 向海
Email：GameWorldChina@myway.com
第3部份: 内存使用，特效和API
关于内存使用的思考
让我们想一想，在今天实际上是如何使用3D 显卡内存的以及在将来又会如何使用。 如今绝大多数3D显卡处理32位像素颜色，8位红色， 8位蓝色，8 位绿色，和 8 位透明度。这些组合的红，蓝和绿256个色度，可以组成 16。7 百万种颜色-- 那是你我可以在一个监视器上看见的所有颜色。
那么，游戏设计大师John Carmack 为什么要求 64 位颜色分辨率呢? 假如我们看不出区别，又有什么意义呢? 意义是: 比如说， 有十几个灯光照射模型上的点，颜色颜色各不相同。 我们取模型的最初颜色，然后计算一个灯光的照射，模型颜色值将改变。 然后我们计算另外的一个灯光， 模型颜色值进一步改变。 这里的问题是，因为颜色值只有8位，在计算了4个灯光之后，8位的颜色值将不足以给我们最后的颜色较好的分辨率和表现。分辨率的不足是由量化误差导致的，本质原因是由于位数不足引起的舍入误差。
你能很快地用尽位数，而且同样地，所有的颜色被清掉。每颜色16 或 32 位，你有一个更高分辨率，因此你能够反复着色以适当地表现最后的颜色。这样的颜色深度很快就能消耗大量的存储空间。我们也应提到整个显卡内存与纹理内存。这里所要说的是，每个3D 显卡实际只有有限的内存，而这些内存要存储前端和后端缓冲区，Z 缓冲区，还有所有的令人惊异的纹理。最初的 Voodoo1 显卡只有2MB显存，后来 Riva TNT提高到16MB显存。然后 GeForce 和 ATI Rage有32MB显存， 现在一些 GeForce 2 到 4的显卡和 Radeons 带有 64MB 到128MB 的显存。 这为什么重要? 好吧，让我们看一些数字…
比如你想让你的游戏看起来最好，所以你想要让它以32位屏幕， 1280x1024分辨率和32位 Z- 缓冲跑起来。 好，屏幕上每个像素4个字节，外加每个像素4字节的Z-缓冲，因为都是每像素32位。我们有1280x1024 个像素 – 也就是 1，310，720个像素。基于前端缓冲区和Z-缓冲区的字节数，这个数字乘以8，是 10，485，760字节。包括一个后端缓冲区，这样是 1280x1024x12， 也就是 15，728，640 字节， 或 15MB。 在一个 16MB 显存的显卡上，就只给我们剩下1MB 来存储所有的纹理。 现在假如最初的纹理是真32 位或 4字节宽，那么我们每幀能在显卡上存储 1MB/4字节每像素 = 262，144个像素。这大约是4 个 256x256 的纹理页面。
很清楚，上述例子表明，旧的16MB 显卡没有现代游戏表现其绚丽画面所需要的足够内存。很明显，在它绘制画面的时候，我们每幀都必须重新把纹理装载到显卡。实际上，设计AGP总线的目的就是完成这个任务，不过， AGP 还是要比 3D 掀卡的幀缓冲区慢，所以你会受到性能上的一些损失。很明显，假如纹理由32位降低到16位，你就能够通过AGP以较低的分辨率传送两倍数量的纹理。假如你的游戏以每个像素比较低的色彩分辨率跑， 那么就可以有更多的显示内存用来保存常用的纹理 (称为高速缓存纹理) 。 但实际上你永远不可能预知使用者将如何设置他们的系统。假如他们有一个在高分辨率和颜色深度跑的显卡，那么他们将会更可能那样设定他们的显卡。
雾
我们现在开始讲雾,它是某种视觉上的效果。如今绝大多数的引擎都能处理雾， 因为雾非常方便地让远处的世界淡出视野，所以当模型和场景地理越过观察体后平面进入视觉范围内时，你就不会看见它们忽然从远处跳出来了。 也有一种称为体雾的技术。这种雾不是随物体离照相机的距离而定,它实际上是一个你能看见的真实对象，并且可以穿越它，从另外一侧出去 -- 当你在穿越对象的时候，视觉上雾的可见程度随着变化。想象一下穿过云团 -- 这是体雾的一个完美例子。体雾的一些好的实现例子是Quake III一些关卡中的红色雾，或新的Rogue Squadron II 之 LUCas Arts的 GameCube 版本。其中有一些是我曾经见过的最好的云--大约与你能看见的一样真实。
在我们讨论雾化的时候,可能是简短介绍一下 Alpha 测试和纹理Alpha混合的好时机。当渲染器往屏幕上画一个特定像素时，假定它已经通过 Z- 缓冲测试 (在下面定义)，我们可能最后做一些Alpha测试。我们可能发现为了显示像素后面的某些东西，像素需要透明绘制。这意味着我们必须取得像素的已有值，和我们新的像素值进行混和，并把混合结果的像素值放回原处。这称为读-修改-写操作,远比正常的像素写操作费时。
你可以用不同类型的混合，这些不同的效果被称为混合模式。直接Alpha混合只是把背景像素的一些百分比值加到新像素的相反百分比值上面。还有加法混合，将旧像素的一些百分比,和特定数量(而不是百分比)的新像素相加。 这样效果会更加鲜明。 (Kyle's Lightsaber在 Jedi Knight II 中的效果)。
每当厂商提供新的显卡时，我们可以得到硬件支持的更新更复杂的混合模式，从而制作出更多更眩目的效果。GF3+4和最近的Radeon显卡提供的像素操作，已经到了极限。
模板阴影与深度测试
用模板产生阴影效果，事情就变得复杂而昂贵了。这里不讨论太多细节（可以写成一篇单独的文章了），其思想是，从光源视角绘制模型视图，然后用这个把多边形纹理外形产生或投射到受影响的物体表面。
实际上你是在视野中投射将会“落”在其他多边形上面的光体。最后你得到看似真实的光照，甚至带有视角在里面。因为要动态创建纹理，并对同一场景进行多遍绘制，所以这很昂贵。
你能用众多不同方法产生阴影，情形时常是这样一来，渲染质量与产生效果所需要的渲染工作成比例。有所谓的硬阴影或软阴影之分，而后者较好，因为它们更加准确地模拟阴影通常在真实世界的行为。 通常有一些被游戏开发者偏爱的“足够好”的方法。如要更多的了解阴影，请参考 Dave Salvator的 3D 流水线一文。
深度测试
现在我们开始讨论深度测试， 深度测试丢弃隐藏的像素，过度绘制开始起作用。过度绘制非常简单 – 在一幀中，你数次绘制一个像素位置。它以3D场景中Z（深度）方向上存在的元素数量为基础，也被称为深度复杂度。假如你经常太多的过度绘制， -- 举例来说, 符咒的眩目视觉特效，就象Heretic II，能让你的幀速率变得很糟糕。当屏幕上的一些人们彼此施放符咒时，Heretic II设计的一些最初效果造成的情形是，他们在一幀中对屏幕上每个相同的像素画了40次! 不用说，这必须调整，尤其是软件渲染器，除了将游戏降低到象是滑雪表演外，它根本不能处理这样的负荷。深度测试是一种用来决定在相同的像素位置上哪些对象在其它对象前面的技术，这样我们就能够避免绘制那些隐藏的对象。
看着场景并想想你所看不见的。 换句话说，是什么在其他场景对象前面,或者隐藏了其他场景对象? 是深度测试作出的这个决定。
我将进一步解释深度深度如何帮助提高幀速率。想像一个很琐细的场景，大量的多边形 (或像素)位于彼此的后面，在渲染器获得他们之间没有一个快速的方法丢弃他们。对非Alpha混合的多边形分类排序( 在Z- 方向上)，首先渲染离你最近的那些多边形，优先使用距离最近的像素填充屏幕。所以当你要渲染它们后面的像素（由Z或者深度测试决定）时，这些像素很快被丢弃，从而避免了混合步骤并节省了时间。假如你从后到前绘制，所有隐藏的对象将被完全绘制，然后又被其他对象完全重写覆盖。场景越复杂，这种情况就越糟糕，所以深度测试是个好东西。
抗锯齿
让我们快速的看一下抗锯齿。当渲染单个多边形时，3D 显卡仔细检查已经渲染的，并对新的多边形的边缘进行柔化，这样你就不会得到明显可见的锯齿形的像素边缘。两种技术方法之一通常被用来处理。 第一种方法是单个多边形层次，需要你从视野后面到前面渲染多边形，这样每个多边形都能和它后面的进行适当的混合。假如不按序进行渲染，最后你会看见各种希奇的效果。在第二种方法中，使用比实际显示更大的分辩率来渲染整幅幀画面，然后在你缩小图像时，尖锐的锯齿形边缘就混合消失了。这第二种方法的结果不错，但因为显卡需要渲染比实际结果幀更多的像素，所以需要大量的内存资源和很高的内存带宽。
多数新的显卡能很好地处理这些，但仍然有多种抗锯齿模式可以供你选择，因此你可以在性能和质量之间作出折衷。对於当今流行的各种不同抗锯齿技术的更具体讨论请参见Dave Salvator 的3D 流水线一文。
顶点与像素着色
在结束讨论渲染技术之前，我们快速的说一下顶点和像素着色，最近它们正引起很多关注。顶点着色是一种直接使用显卡硬件特征的方式，不使用API。举例来说，假如显卡支持硬件 T & L ，你可以用DirectX或OpenGL编程，并希望你的顶点通过 T & L 单元 (因为这完全由驱动程序处理，所以没有办法确信)，或者你直接利用显卡硬件使用顶点着色。它们答应你根据显卡自身特征进行非凡编码，你自己非凡的编码使用T & L 引擎，以及为了发挥你的最大优势，显卡必须提供的其他别的特征。 事实上，现在nVidia 和ATI 在他们大量的显卡上都提供了这个特征。
不幸的是，显卡之间表示顶点着色的方法并不一致。你不能象使用DirectX或者OpenGL 那样，为顶点着色编写一次代码就可以在任何显卡上运行，这可是个坏消息。然而，因为你直接和显卡硬件交流，它为快速渲染顶点着色可能生成的效果提供最大的承诺。( 如同创造很不错的特效 -- 你能够使用顶点着色以API没有提供的方式影响事物)。事实上，顶点着色正在真的将3D 图形显示卡带回到游戏机的编码方式，直接存取硬件，最大限度利用系统的必须知识，而不是依靠API来为你做一切。对一些程序员来说，会对这种编码方式感到吃惊，但这是进步代价。
进一步阐述，顶点着色是一些在顶点被送到显卡渲染之前计算和运行顶点效果程序或者例程。你可以在主CPU上面用软件来做这些事情，或者使用显卡上的顶点着色。 为动画模型变换网格是顶点程序的主选。
像素着色是那些你写的例程，当绘制纹理时，这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常情况做的混合模式运算。这答应你做一些很不错的像素效果， 比如，使远处的纹理模糊，添加炮火烟雾, 产生水中的反射效果等。一旦 ATI 和 nVidia 能实际上就像素着色版本达成一致( DX9's 新的高级阴影语言将会帮助促进这一目标), 我一点不惊奇DirectX 和OpenGL采用Glide的方式-- 有帮助开始, 但最终不是把任何显卡发挥到极限的最好方法。我认为我会有爱好观望将来。
最后（In Closing...）
最终，渲染器是游戏程序员最受评判的地方。在这个行业，视觉上的华丽非常重要，因此它为知道你正在做的买单。对于渲染器程序员，最坏的因素之一就是3D 显卡工业界变化的速度。一天，你正在尝试使透明图像正确地工作；第二天 nVidia 正在做顶点着色编程的展示。而且发展非常快，大致上，四年以前为那个时代的 3D 显卡写的代码现在已经过时了，需要全部重写。 甚至John Carmack 这样描述过，他知道四年以前为充分发挥那个时期显卡的性能所写的不错的代码，如今很平凡 -- 因此他产生了为每个新的id项目完全重写渲染器的欲望。Epic 的Tim Sweeney赞同 -- 这里是去年他给我的评论:
我们已经足足花费了9个月时间来更换所有的渲染代码。最初的 Unreal 被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为 GeForce 及更好的图形显示卡，且多边形吞吐量是Unreal Tournament的100倍。
这需要全部替换渲染器。很幸运，该引擎模块化程度足够好，我们可以保持引擎的其余部分—编辑器，物理学，人工智能，网络--不改动，尽管我们一直在以许多方式改进这些部分。
搭配长篇文章的短篇报导（Sidebar）：API -- 祝福和诅咒
那么什么是API? 它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来说，很大程度上每种3D显示卡的3D实现方式都有所差别。然而，他们全部都呈现一个一致的前端给最终使用者或者程序员，所以他们知道他们为X 3D显示卡写的代码将会在Y 3D显示卡上面有相同的结果。好吧，不管怎样理论上是那样。 大约在三年以前这可能是相当真实的陈述，但自那以后，在nVidia 公司的引领下，3D显卡行业的事情发生了变化。
如今在PC领域，除非你正计划建造自己的软件光栅引擎，使用CPU来绘制你所有的精灵，多边形和粒子 -- 而且人们仍然在这样做。跟Unreal一样，Age of Empires II: Age of Kings有一个优秀的软件渲染器 – 否则你将使用两种可能的图形API，OpenGL或者 DirectX 之一。OpenGL是一种真正的跨平台API (使用这种API写的软件可以在Linux，Windows和MacOS上运行。)， 而且有多年的历史了，为人所熟知，但也开始慢慢地显示出它的古老。 大约在四年以前，定义OpenGL驱动特征集一直是所有显示卡厂商工作的方向。
然而，一旦在目标达成以后，没有预先制定特征工作方向的路线图，这时候，所有的显卡开发商开始在特征集上分道扬镳，使用OpenGL扩展。
3dfx 创造了T- 缓冲。 nVidia 努力寻求硬件变换和光照计算。Matrox努力获取凹凸贴图。等等。 我以前说过的一句话，"过去几年以来，3D显示卡领域的事情发生了变化。"委婉地说明了这一切。
无论如何，另一个可以选择的API是 DirectX。这受Microsoft公司控制，且在PC 和 Xbox 上被完美地支持。由于明显的原因，DirectX 没有Apple或者 Linux 版本。因为Microsoft控制着 DirectX，大体上它轻易更好地集成在Windows里面。
OpenGL和DirectX之间的基本差别是前者由‘社区’拥有，而后者由Microsoft拥有。假如你想要 DirectX 为你的 3D 显示卡支持一个新的特征，那么你需要游说微软，希望采纳你的愿望，并等待新的 DirectX发行版本。对于OpenGL，由于显示卡制造商为3D显示卡提供驱动程序，你能够通过OpenGL扩展立即获得显示卡的新特征。这是好，但作为游戏开发者，当你为游戏编码的时候，你不能指望它们很普遍。它们可能让你的游戏速度提升50%，但你不能要求别人有一块GeForce 3 来跑你的游戏。好吧，你可以这么做，但假如你想来年还在这个行业的话，这是个相当愚蠢的主意。
这是对这个问题极大的简单化，对我所有描述的也有各种例外情况，但这里一般的思想是很确实的。对于DirectX ，在任何既定时间你轻易确切地知道你能从显示卡获得的特征，假如一个特征不能获得，DirectX 将会用软件模拟它(也不总是一件好事情，因为这样有时侯非常的慢，但那是另外一回事)。对于OpenGL，你可以更加贴近显示卡的特征,但代价是不能确定将会获得的准确特征。
