http://blog.csdn.net/xieyuquan/archive/2006/10/05/1321801.aspx
但从文中的一些内容来看，可能是在
dx3.0 - dx5.0
之间
不知道卡马克者，质疑卡马克实力者，请不要发言。否则可能会被全世界的程序员用口水淹死
ZT 至 http://bbs.chinagamedev.net/showthread.php?t=8517
不知道卡马克者，质疑卡马克实力者，请不要发言。否则可能会被全世界的程序员用口水淹死
ZT 至 http://bbs.chinagamedev.net/showthread.php?t=8517
black
2004-10-23
, 14:56
John Carmack
谈论
OpenGL
和
D3D
我将通过我的这个 .plan 文件来阐述一下我对于一个非常重要的问题 ——3D API—— 的看法。 经常有人询问我对于这个问题的观点，所以我觉得应该找一个机会来加以公开说明。下面我将介绍我到目前为止的最新想法。。。
尽管 Id 还有一些游戏的扫尾工作要做，但是我的大部分精力现在都集中于开发下一代游戏技术。这种新一代的技术将被 Id 和其他公司在近期所使用，因而需要制定很多非常重要的长期决策。
在基于 Win 32 的较低层 3D 编程方面，目前有两种可供选择的技术： Direct-3D 立即模式，这是一种新的、专门针对游戏 API 设计的技术； OpenGL ，原来由 SGI 开发的工作站图形 API 。它们都获得了微软的支持，而 D3D 被宣传为唯一真正面向游戏的解决方案。
在过去的日子里，我一直在使用 OpenGL 。我对这种 API 的出色设计留下了深刻的印象，尤其是它的易用性。一个月以前，我将 Quake 导入了 OpenGL 。这是一次非常愉快的体验。导入时间很短，代码非常简洁，而且它为我提供了一个重要的测试平台，让我可以迅速地尝试新的研究想法。
为了学习微软 Direct-3D IM 和对这两种技术进行公平的比较，我开始将 glquake 导入到这种 API 中。
现在，我已经对了有了足够的了解。我并不打算把导入过程进行到底。我完全可以用庑 ┦ 奔淅醋龈 又匾 氖虑椤 ?br>
我希望我的经验可以促使在未来一年中制造第二代显卡的厂商们为 OpenGL 提供支持。如果这种情况没有及时发生，就可能会出现一些无法为 glquake 提供支持的显卡。我对此深表遗憾，但是我的确希望借助我的微薄之力，对一些可能在今后的很多年中都会我们产生影响的事情发挥一定的影响力。
微软 Direct-3D IM 是一个非常糟糕的 API 。它会给使用它的程序员带来极大的痛苦和烦恼，而不会带来任何重要的好处。我认为 D3D 并不适用于任何一个市场，而 OpenGL 看来可以满足从 quake 到 softimage 的所有需要。 D3D 的存在并没有一个合理的技术理由。
我想 D3D 肯定会随着后续版本的不断升级而得到一定的改进，但目前是一个促使整个开发人员群体放弃一个设计错误的、发展混乱的 API 的重要机会。
最佳情况是：微软将 OpenGL 与 direct-x ( 很可能称之为 Direct-GL 或者别的 ) 集成，在 GL 的基础上导入 D3D 保留模式，并让所有人忘记他们听说过的、任何关于 D3D 立即模式的信息。程序员拥有一个出色的 API ，厂商只需要编写一个驱动程序，这样整个世界就会变得更加美好。
下面我将更加详细地介绍这两种技术：
“D3D” 是指 Direct-3D 立即模式。 D3D 保留模式则是另外一个问题。保留模式的存在有很多非常有力的理由。这种 API 让您只需加载模型文件和四处活动，而不需要绘制大量的多边形细节，因而可以节约很多工作量。使用保留模式的程序员将会被使用立即模式的程序员多十倍以上。真正进入新层次的世界类应用将通过一个立即模式图形 API 完成。 D3D-RM 甚至不一定需要与 D3D-IM 一同使用。它可以被用于引出 OpenGL 代码。
我并不是特别在意 D3D 或者 OpenGL 的纯软件应用。我对此并没有进行深入的研究，但是我认为 D3D 拥有实际的优势，因为它最初就是针对软件渲染而设计的，因而在这方面进行了一些集中的优化。 COSMO GL 也试图在这方面与之竞争，但是我认为这种努力并没有什么意义。虽然为了支持软件光栅化和硬件光栅化的 “ 最小公分母 ” ，软件光栅化还将继续存在，但是很快所有游戏开发项目都将以硬件光栅化为目标，这才是真正应当加以关注的领域。
对于游戏开发人员而言， 3D API 最重要的作用是充当与不断涌现的各种 3D 硬件的接口。如果某种兼容的硬件产品系列可以符合我们的要求，而且覆盖了目标市场的 90% 以上，我甚至就不会希望为工作用途使用一个 3D API ，而是会直接为硬件编写程序，就像我一直以来对纯软件机制所采用的方法一样。我可能还会需要一个 3D API 来进行研究和工具开发，但是我不会在意它是否是一个主流解决方案。
因为我预计 3D 加速器市场在可以预见的将来仍然会保持相当分散的局面，所以我需要利用针对不同品牌的硬件的驱动程序，借助一个 API 来编写程序。 OpenGL 目前在工作站市场已经非常成熟。它一直都非常关注与硬件的交互。我们拥有的证据表明，它可以在一个价值 300 美元的 Permedia 卡和价值 25 万美元的 Infinite Reality 系统之间保持出色的伸缩性。
所有面向游戏的 PC 3D 硬件基本上都在去年出现。因为 PC 世界的复杂性，我们可能会遇到并不是很理想的 API 和驱动程序模型。
对于一个 API 而言，最关键的是：功能、性能、驱动程序覆盖范围和易用性。
这两种 API 都具有一些重要的功能。这一点勿庸置疑。 GL 支持一些我不大可能用到 ( 或者不大可能获得硬件支持 —— 结果相同 ) 的、额外的、极为深奥的功能。 D3D 实际上具有一些相当出色、我希望能将其转移到 GL 上的功能 ( 例如在每个顶点进行镜面混合、色键透明处理和没有切割提示 ) ，这同时也带来了扩展问题。 GL 可以通过驱动程序扩展，但是因为 D3D 在驱动程序和 API 之间添加了一个层，所以微软是唯一可以扩展 D3D 的厂商。
我对于性能的结论是在未来几年内，正确编写的 OpenGL 和 D3D 驱动程序的性能不会存在显著的区别 ( 小于 10%) 。有些人认为 GL 可以更好地扩展到非常高端的硬件，因为它不需要构建任何中间结构，但是你可以在 D3D 中利用小型从属缓存式的执行缓冲实现类似的效果 ( 或者专门针对 D3D 开发复杂的硬件 —— 没错！ ) 。还有人认为， D3D 中的顶点池将可以节约轮廓分界应用的工作量，但是您可以通过 GL 中的顶点阵列达到相同的目的。
目前，在消费级的显卡中，支持 D3D 的驱动程序多于支持 OpenGL 的驱动程序。我希望我们可以改变这种局面。一个非常严重的问题是目前没有 D3D 兼容性测试，而且相关的文档也很少，因此现有的驱动程序的功能并不能达到真正的一致。 OpenGL 已经建立起了一套完整的兼容性测试，因而对各种功能的工作方式都有了非常明确的规定。 OpenGL 提供了两种可供编写的驱动程序等级：小型客户端驱动程序和可安装客户端驱动程序。 MCD 是硬件光栅化功能的一个简单的、健壮的导出。 ICD 基本上是对该 API 的完全替代，它可以加快硬件速度或者在不增加开销的情况下拓展 GL 的任何组成部分。
GL 比 D3D 好得多的最重要的原因是易用性。 GL 非常便于使用，而且使用的过程很有趣。而 D3D 并非如此 ( 咳嗽 ^_^) 。你可以只用一页代码编写简单的 GL 程序。而我认为 D3D 选择了目前最糟糕的接口 ——COM 接口，发送到函数的可扩展 struct 执行缓冲。其中一选择的目的是让些该 API 将来可以方便地进行扩展，但是如果这个 API 很难使用，而且以后一直都会这样，谁还会考虑它将来能否升级？很多任务只需要一行 GL 代码即可完成，但是可能需要半页的 D3D 代码，例如分配一个结构、设置一个大小、填充、调用一个 COM 子程序，以及获取运行结果。
易用性非常重要。如果你能够用一半的时间完成编程，你就可以尽早交付工作或者考虑更多的方法。一个简洁的、便于阅读的编程界面也会让程序员可以更加轻松地发现 / 防止程序漏洞。
GL 的接口是通过程序体现出来的：你通过调用 GL 函数执行操作，进而发送顶点数据和指定对象。
glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();
D3D 的接口是通过执行缓冲体现的：你建立一个包含顶点数据和命令的结构，再通过一次调用发送整个结构。在表面上，这似乎可以提高 D3D 的效率，因为它消除了程序调用开销。但是事实上，这种做法非常繁琐。
( 下面是不完整的伪代码 )
v = &buffer.vertexes;[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);
如果我在这里加入实际用于锁定、构建和释放一个执行缓冲的全部代码，你可能会认为我在用某个故意歪曲事实的、不合理的例子来让 D3D 看起来很糟糕。
在实际使用时，你不会在一个执行缓冲中只放一个三角形，否则你的性能将会非常低。我的想法是编写一个庞大的批处理命令，从而让你只需要调用一个程序就可以将大量的工作发送到 D3D 。
这里存在的问题是 “ 庞大 ” 和 “ 大量 ” 的定义取决于你所使用的硬件。但是应用软件程序员并不能将这个判断交给驱动程序处理，而是必须知道最适合每个硬件的具体配置的定义。
你可以用宏来包含一些繁琐的工作，但是这也会带来一些问题。我所发现的、让 D3D 具有通用性的唯一方法是开发你自己的程序接口，从而将命令放置在一个或者多个执行缓存中，在需要时放出。但是既然已经有了一个非常出色的程序 API ，何必还要多此一举呢？
利用 OpenGL ，你可以利用简洁的、直接的代码完成任务。如果代码正确，你可以将其转换成显示列表或者顶点阵列，从而获得最高的性能 ( 尽管差别通常没有那么大 ) 。这是解决问题的正确方法 —— 就像在完成所有的 C 语言开发工作之后，将关键的函数转换为汇编语言。
如果使用 D3D ，你必须自始至终用一种非常痛苦的方式执行各项任务。就像用汇编语言编写整个程序一样，需要花费更多的时间，而且会失去进一步改进算法的机会。最后还会发现，它甚至不能提高速度。
在未来的很多年中，我可能每天都要用一个 3D API 编写程序。我希望找到一个可以助我一臂之力的 API ，而不是一个会影响我的工作效率的 API 。
John Carmack
Id Software
我将通过我的这个 .plan 文件来阐述一下我对于一个非常重要的问题 ——3D API—— 的看法。 经常有人询问我对于这个问题的观点，所以我觉得应该找一个机会来加以公开说明。下面我将介绍我到目前为止的最新想法。。。
尽管 Id 还有一些游戏的扫尾工作要做，但是我的大部分精力现在都集中于开发下一代游戏技术。这种新一代的技术将被 Id 和其他公司在近期所使用，因而需要制定很多非常重要的长期决策。
在基于 Win 32 的较低层 3D 编程方面，目前有两种可供选择的技术： Direct-3D 立即模式，这是一种新的、专门针对游戏 API 设计的技术； OpenGL ，原来由 SGI 开发的工作站图形 API 。它们都获得了微软的支持，而 D3D 被宣传为唯一真正面向游戏的解决方案。
在过去的日子里，我一直在使用 OpenGL 。我对这种 API 的出色设计留下了深刻的印象，尤其是它的易用性。一个月以前，我将 Quake 导入了 OpenGL 。这是一次非常愉快的体验。导入时间很短，代码非常简洁，而且它为我提供了一个重要的测试平台，让我可以迅速地尝试新的研究想法。
为了学习微软 Direct-3D IM 和对这两种技术进行公平的比较，我开始将 glquake 导入到这种 API 中。
现在，我已经对了有了足够的了解。我并不打算把导入过程进行到底。我完全可以用庑 ┦ 奔淅醋龈 又匾 氖虑椤 ?br>
我希望我的经验可以促使在未来一年中制造第二代显卡的厂商们为 OpenGL 提供支持。如果这种情况没有及时发生，就可能会出现一些无法为 glquake 提供支持的显卡。我对此深表遗憾，但是我的确希望借助我的微薄之力，对一些可能在今后的很多年中都会我们产生影响的事情发挥一定的影响力。
微软 Direct-3D IM 是一个非常糟糕的 API 。它会给使用它的程序员带来极大的痛苦和烦恼，而不会带来任何重要的好处。我认为 D3D 并不适用于任何一个市场，而 OpenGL 看来可以满足从 quake 到 softimage 的所有需要。 D3D 的存在并没有一个合理的技术理由。
我想 D3D 肯定会随着后续版本的不断升级而得到一定的改进，但目前是一个促使整个开发人员群体放弃一个设计错误的、发展混乱的 API 的重要机会。
最佳情况是：微软将 OpenGL 与 direct-x ( 很可能称之为 Direct-GL 或者别的 ) 集成，在 GL 的基础上导入 D3D 保留模式，并让所有人忘记他们听说过的、任何关于 D3D 立即模式的信息。程序员拥有一个出色的 API ，厂商只需要编写一个驱动程序，这样整个世界就会变得更加美好。
下面我将更加详细地介绍这两种技术：
“D3D” 是指 Direct-3D 立即模式。 D3D 保留模式则是另外一个问题。保留模式的存在有很多非常有力的理由。这种 API 让您只需加载模型文件和四处活动，而不需要绘制大量的多边形细节，因而可以节约很多工作量。使用保留模式的程序员将会被使用立即模式的程序员多十倍以上。真正进入新层次的世界类应用将通过一个立即模式图形 API 完成。 D3D-RM 甚至不一定需要与 D3D-IM 一同使用。它可以被用于引出 OpenGL 代码。
我并不是特别在意 D3D 或者 OpenGL 的纯软件应用。我对此并没有进行深入的研究，但是我认为 D3D 拥有实际的优势，因为它最初就是针对软件渲染而设计的，因而在这方面进行了一些集中的优化。 COSMO GL 也试图在这方面与之竞争，但是我认为这种努力并没有什么意义。虽然为了支持软件光栅化和硬件光栅化的 “ 最小公分母 ” ，软件光栅化还将继续存在，但是很快所有游戏开发项目都将以硬件光栅化为目标，这才是真正应当加以关注的领域。
对于游戏开发人员而言， 3D API 最重要的作用是充当与不断涌现的各种 3D 硬件的接口。如果某种兼容的硬件产品系列可以符合我们的要求，而且覆盖了目标市场的 90% 以上，我甚至就不会希望为工作用途使用一个 3D API ，而是会直接为硬件编写程序，就像我一直以来对纯软件机制所采用的方法一样。我可能还会需要一个 3D API 来进行研究和工具开发，但是我不会在意它是否是一个主流解决方案。
因为我预计 3D 加速器市场在可以预见的将来仍然会保持相当分散的局面，所以我需要利用针对不同品牌的硬件的驱动程序，借助一个 API 来编写程序。 OpenGL 目前在工作站市场已经非常成熟。它一直都非常关注与硬件的交互。我们拥有的证据表明，它可以在一个价值 300 美元的 Permedia 卡和价值 25 万美元的 Infinite Reality 系统之间保持出色的伸缩性。
所有面向游戏的 PC 3D 硬件基本上都在去年出现。因为 PC 世界的复杂性，我们可能会遇到并不是很理想的 API 和驱动程序模型。
对于一个 API 而言，最关键的是：功能、性能、驱动程序覆盖范围和易用性。
这两种 API 都具有一些重要的功能。这一点勿庸置疑。 GL 支持一些我不大可能用到 ( 或者不大可能获得硬件支持 —— 结果相同 ) 的、额外的、极为深奥的功能。 D3D 实际上具有一些相当出色、我希望能将其转移到 GL 上的功能 ( 例如在每个顶点进行镜面混合、色键透明处理和没有切割提示 ) ，这同时也带来了扩展问题。 GL 可以通过驱动程序扩展，但是因为 D3D 在驱动程序和 API 之间添加了一个层，所以微软是唯一可以扩展 D3D 的厂商。
我对于性能的结论是在未来几年内，正确编写的 OpenGL 和 D3D 驱动程序的性能不会存在显著的区别 ( 小于 10%) 。有些人认为 GL 可以更好地扩展到非常高端的硬件，因为它不需要构建任何中间结构，但是你可以在 D3D 中利用小型从属缓存式的执行缓冲实现类似的效果 ( 或者专门针对 D3D 开发复杂的硬件 —— 没错！ ) 。还有人认为， D3D 中的顶点池将可以节约轮廓分界应用的工作量，但是您可以通过 GL 中的顶点阵列达到相同的目的。
目前，在消费级的显卡中，支持 D3D 的驱动程序多于支持 OpenGL 的驱动程序。我希望我们可以改变这种局面。一个非常严重的问题是目前没有 D3D 兼容性测试，而且相关的文档也很少，因此现有的驱动程序的功能并不能达到真正的一致。 OpenGL 已经建立起了一套完整的兼容性测试，因而对各种功能的工作方式都有了非常明确的规定。 OpenGL 提供了两种可供编写的驱动程序等级：小型客户端驱动程序和可安装客户端驱动程序。 MCD 是硬件光栅化功能的一个简单的、健壮的导出。 ICD 基本上是对该 API 的完全替代，它可以加快硬件速度或者在不增加开销的情况下拓展 GL 的任何组成部分。
GL 比 D3D 好得多的最重要的原因是易用性。 GL 非常便于使用，而且使用的过程很有趣。而 D3D 并非如此 ( 咳嗽 ^_^) 。你可以只用一页代码编写简单的 GL 程序。而我认为 D3D 选择了目前最糟糕的接口 ——COM 接口，发送到函数的可扩展 struct 执行缓冲。其中一选择的目的是让些该 API 将来可以方便地进行扩展，但是如果这个 API 很难使用，而且以后一直都会这样，谁还会考虑它将来能否升级？很多任务只需要一行 GL 代码即可完成，但是可能需要半页的 D3D 代码，例如分配一个结构、设置一个大小、填充、调用一个 COM 子程序，以及获取运行结果。
易用性非常重要。如果你能够用一半的时间完成编程，你就可以尽早交付工作或者考虑更多的方法。一个简洁的、便于阅读的编程界面也会让程序员可以更加轻松地发现 / 防止程序漏洞。
GL 的接口是通过程序体现出来的：你通过调用 GL 函数执行操作，进而发送顶点数据和指定对象。
glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();
D3D 的接口是通过执行缓冲体现的：你建立一个包含顶点数据和命令的结构，再通过一次调用发送整个结构。在表面上，这似乎可以提高 D3D 的效率，因为它消除了程序调用开销。但是事实上，这种做法非常繁琐。
( 下面是不完整的伪代码 )
v = &buffer.vertexes;[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);
如果我在这里加入实际用于锁定、构建和释放一个执行缓冲的全部代码，你可能会认为我在用某个故意歪曲事实的、不合理的例子来让 D3D 看起来很糟糕。
在实际使用时，你不会在一个执行缓冲中只放一个三角形，否则你的性能将会非常低。我的想法是编写一个庞大的批处理命令，从而让你只需要调用一个程序就可以将大量的工作发送到 D3D 。
这里存在的问题是 “ 庞大 ” 和 “ 大量 ” 的定义取决于你所使用的硬件。但是应用软件程序员并不能将这个判断交给驱动程序处理，而是必须知道最适合每个硬件的具体配置的定义。
你可以用宏来包含一些繁琐的工作，但是这也会带来一些问题。我所发现的、让 D3D 具有通用性的唯一方法是开发你自己的程序接口，从而将命令放置在一个或者多个执行缓存中，在需要时放出。但是既然已经有了一个非常出色的程序 API ，何必还要多此一举呢？
利用 OpenGL ，你可以利用简洁的、直接的代码完成任务。如果代码正确，你可以将其转换成显示列表或者顶点阵列，从而获得最高的性能 ( 尽管差别通常没有那么大 ) 。这是解决问题的正确方法 —— 就像在完成所有的 C 语言开发工作之后，将关键的函数转换为汇编语言。
如果使用 D3D ，你必须自始至终用一种非常痛苦的方式执行各项任务。就像用汇编语言编写整个程序一样，需要花费更多的时间，而且会失去进一步改进算法的机会。最后还会发现，它甚至不能提高速度。
在未来的很多年中，我可能每天都要用一个 3D API 编写程序。我希望找到一个可以助我一臂之力的 API ，而不是一个会影响我的工作效率的 API 。
John Carmack
Id Software
goldegg
2004-10-23
, 17:22
偶也来厚道的转贴。
恩，我想说，你用什么顺手就用什么。
恩，我想说，你用什么顺手就用什么。
goldegg
2004-10-23
, 17:24
不论是哪一种类型的图形芯片，总会支持某个版本的
DirectX
或
OpenGL API
，而支持哪一个
API
版本几乎成为图形产品分代的标志。我们有必要先明确
API
的概念，
API
的全称是
“Application Programming Interface”
，意为应用程序接口，它是连接应用程序、操作系统和底层硬件的纽带。通俗点说，
API
就是软件函数的集合，这些预先编写好的函数可以对硬件进行直接控制，它最大的优点就是通用性。
3D
显卡刚刚诞生时，并不存在支持何种
API
的概念，如果某款游戏要运行在不同的显卡平台上，开发商就必须为每个类别的显卡编写一套程序，显然这意味着巨大的精力损耗，同时也无法获得令人满意的效果。因此早期显卡通常都有
“
游戏兼容性
”
的说法，游戏产品同样也有
“
显卡兼容性
”
的概念，这有点类似于上世纪
80
年代之前的专用计算机时代：每个硬件平台都必须使用专用的软件、不同厂商之间软硬件不具通用性。
人们很早就意识到这个问题，对应的解决方案也被提出：制定一套操控硬件的图形函数库，图形芯片制造商和游戏开发商都严格遵循这套标准，这样，图形芯片制造商无需考虑什么游戏兼容的问题，它只要根据函数库提供的功能来开发产品就可以了；而游戏开发商也不必为每款显卡都编程、只要直接调用这些标准化的函数库即可实现广泛的兼容性。这套函数库也就是所谓的图形 API 。
目前，我们可接触到的图形 API 可分为 OpenGL 和 DirectX 两大体系，前者是一项开放性的标准、主攻专业图形应用和 3D 游戏，由 “OpenGL 架构委员会 ” 掌控，其成员包括业内各大厂商，目前主要推动标准发展的实际领导者是 3Dlabs 。 DirectX 则是微软制定的 API 标准，除了图形 API 功能外，它还包含音频 API 等功能，只不过其图形部分升级最快、也最为人所知。 DirectX 针对的主要是娱乐应用，目前最新的 DirectX 9 API 功能极为强劲，大部分新 3D 游戏都基于 DirectX 9 ，而图形芯片制造商更是将它作为标准、竞相提供对 DirectX 9 的支持，是否支持 DirectX 9 也成为两代显卡的分水岭。
对显卡来说， API 的重要性毋庸置疑，而未来每一次图形技术的重大进步都将与 API 紧密相关，关注 OpenGL 和 DirectX 这两种 API 无疑是非常必要的，从中我们可以了解它们的历史、现状和未来的发展，借机了解整个图形技术的发展状况。
人们很早就意识到这个问题，对应的解决方案也被提出：制定一套操控硬件的图形函数库，图形芯片制造商和游戏开发商都严格遵循这套标准，这样，图形芯片制造商无需考虑什么游戏兼容的问题，它只要根据函数库提供的功能来开发产品就可以了；而游戏开发商也不必为每款显卡都编程、只要直接调用这些标准化的函数库即可实现广泛的兼容性。这套函数库也就是所谓的图形 API 。
目前，我们可接触到的图形 API 可分为 OpenGL 和 DirectX 两大体系，前者是一项开放性的标准、主攻专业图形应用和 3D 游戏，由 “OpenGL 架构委员会 ” 掌控，其成员包括业内各大厂商，目前主要推动标准发展的实际领导者是 3Dlabs 。 DirectX 则是微软制定的 API 标准，除了图形 API 功能外，它还包含音频 API 等功能，只不过其图形部分升级最快、也最为人所知。 DirectX 针对的主要是娱乐应用，目前最新的 DirectX 9 API 功能极为强劲，大部分新 3D 游戏都基于 DirectX 9 ，而图形芯片制造商更是将它作为标准、竞相提供对 DirectX 9 的支持，是否支持 DirectX 9 也成为两代显卡的分水岭。
对显卡来说， API 的重要性毋庸置疑，而未来每一次图形技术的重大进步都将与 API 紧密相关，关注 OpenGL 和 DirectX 这两种 API 无疑是非常必要的，从中我们可以了解它们的历史、现状和未来的发展，借机了解整个图形技术的发展状况。
goldegg
2004-10-23
, 17:25
定位专业应用的
OpenGL
OpenGL 的英文全称是 “Open Graphics Library” ，意为 “ 开放的图形程序接口 ” 。 OpenGL 的历史可以追溯到上个世纪 90 年代初，标准诞生之后它一直占据主导地位。而微软的 DirectX 出现的时间比 OpenGL 晚得多、功能也不及 OpenGL ，只不过最近几年 OpenGL 因发展迟缓才被 DirectX 追上而已。尽管如此， OpenGL 仍然是高端图形 API 的代名词，制定中的 OpenGL 2.0 以强劲的功能特性为业界瞩目，而显卡制造商对 OpenGL API 的重视程度并未缩减，在可预见的将来， OpenGL 还将引领专业图形和 3D 游戏的风潮。
OpenGL 发展历程
上个世纪 90 年代初， SGI 公司出于制造图形工作站产品的需要、开发出名为 “IRISGL” 的图形 API 并成为工业标准。在当时， IRISGL 的功能可谓十分强大，但它的可移植性却相当之差。有鉴于此， SGI 决定在 IRISGL 基础上开发出一种功能类似、但可移植性更好的图形 API— 这就是 OpenGL 。 OpenGL 被打造为开放性标准，任何软硬件厂商均可自由使用，这让它受到广泛的欢迎。
1992 年 7 月， SGI 正式发布 OpenGL 1.0 标准。 OpenGL 1.0 完全实现了 SGI 的预期设计目标：功能强大、移植性良好并能自由使用。随后， SGI 发起成立了 “OpenGL 架构委员会 ” （ OpenGL Architecture Review Board ，简称 ARB ）来共同管理和推广这项先进的标准， OpenGL 后继标准的制定权也逐渐转移给 ARB 组织。在 ARB 内部，产生新标准的过程非常民主化：各成员以投票的方式来决定新版 OpenGL 标准应具有的功能特性，并据投票结果制作正式标准文档，各软硬件厂商再根据这份标准文档的内容在自己的系统上实现；而所有的 OpenGL 版本都必须通过文档规定的全部测试项目方能生效。 ARB 组织的成员都非泛泛之辈，目前其核心成员包括 SGI 、 3Dlabs 、 Intel 、 IBM 、 nVIDIA 、 ATi 、 Microsoft 、 Apple 等业界领袖。
OpenGL 1.0 获得意料之中的巨大成功，专业图形领域唯它马首是瞻。看到这一点，微软甚为心动，当时它正在开发的 Windows NT 系统如果获得 OpenGL 的支持无疑会如虎添翼；而 SGI 也希望能够让 OpenGL 广为流传。于是 SGI 和微软进行首次合作、联手将 OpenGL 1.0 移植到 Windows NT 平台。这项工作自然没有什么悬念，适用于 NT 的 OpenGL 1.0 顺利推出，这使得 Windows NT 系统成为图形工作站的又一个可选操作平台，很多运行于 UNIX 之下的专业图形软件也逐渐被移植，微软和 SGI 都如愿以偿。
1995 年， SGI 推出了更为完善的 OpenGL 1.1 版本。 OpenGL 1.1 的性能比 1.0 版提高甚多，同时还加入了诸如顶点数组、顶点位置、新纹理等新特性，并增强了元文件对 OpenGL 的调用等等。 OpenGL 1.1 同样获得了成功，而它也有对应的 Windows NT 版本。
1997 年，受 3D 显卡的刺激， Windows 95 平台下开始涌现出大量的 3D 游戏，可微软自己的 Direct 3D 3.0 图形接口极为糟糕， idSoftware 公司的顶尖程序员 John Carmack （ Quake 之父）嘲讽它简直就是 “ 支离破碎的 API” 。很自然，强大的 OpenGL 成为取代 DirectX 的最佳选择。但问题是微软虽然在 NT 系统中引入了 OpenGL ，但其同时代的 Windows 95 却无法支持 OpenGL ，面对这种局面， idSoftware 公司联合其它游戏开发商强烈要求微软在 Windows 95 中也引入 OpenGL API ，微软也很了解自己的 “Direct 3D 3.0” 是什么货色、它很快就接受了这项建议。而后， id 公司开发出基于 OpenGL 的 Quake2 ，想必有过 3 年以上游戏玩龄的读者都会记得 Quake2 那无以伦比的 3D 场景和激烈刺激的竞技画面。而 OpenGL API 因此立下大功，几乎所有游戏开发商都转向 OpenGL ，微软后来也不得不顺应潮流、在 Windows95 OSR2 版及 Windows 98 中正式支持 OpenGL ，相关游戏开始大量涌现，而 AutoCAD 、 3DS MAX 、 Maya 等许多专业 3D 设计软件也被移植到普通 PC 平台。今天，预算有限的设计者可以在 PC 中运行这些软件，莫不拜 OpenGL 所赐。
1999 年， OpenGL 再度发生变革，但这次它遇到的是发展史上的重大危机： SGI 决定与微软联手开发下一代图形接口 ——Ferihant 。 Ferihant 应用于 Windows 系统中，作为 OpenGL 和 DirectX 的取代者。为此， Ferihant 将包含 DirectX 与 OpenGL 各自的优点，并加入场景贴图之类的高级功能。由于有了 Ferihant ， SGI 停止了原先的 Windows 版 OpenGL 开发计划，外界对此表示赞赏。然而 Ferihant 计划没进行多久，双方的合作就出现裂痕，微软不积极合作，光想把 SGI 的图形技术并入 DirectX 的做法令 SGI 非常不满， SGI 随后宣布中止合作并撤回所有的开发人员， Ferihant 遂告夭折。在这之后， OpenGL 和 DirectX 似乎互不相干，继续在 PC 平台上发展，但状况对比鲜明： DirectX 从此突飞猛进，而 OpenGL 却长期原地徘徊。
2001 年 8 月， ARB 发布 OpenGL 1.3 规范，它增加了立方纹理贴图、纹理环境、多重采样、纹理框架压缩等扩展指令，但是改进程度非常有限； 2002 年 7 月， ARB 正式发布 OpenGL 1.4 ，它也只加入了深度纹理／阴影纹理、顶点设计框架、自动纹理贴图等简单的功能，越来越落后于图形硬件技术的飞速发展。而此期间 DirectX 突飞猛进， DirectX 8 API 更是正式成为娱乐显卡的标准， id 公司所形容的 “ 支离破碎的 DirectX” 早已非吴下阿蒙，大量的 3D 游戏转向了 DirectX 体系。
OpenGL 落后于时代并非 ARB 组织技术不佳，根本症结在于确定 OpenGL 标准的民主机制：各成员通过投票表决。在实际操作中，这些成员往往基于自身利益而产生意见分歧，为了照顾多数人的利益 OpenGL 不得不变得复杂臃肿、开发进度缓慢。我们可以看到，在 OpenGL 1.0 之后的各个版本只是进行一些扩展指令集的升级，而它对显卡硬件中不断涌现出的先进特性熟视无睹，同为 ARB 成员之一的微软对此抱怨不已，后来它干脆彻底抛开 OpenGL 、将全部精力投到自家的 DirectX 。大获成功的 DirectX 7 、 DirectX 8 就是在此种背景下出现的。
2003 年的 7 月， ARB 公布 OpenGL 1.5 规范 —— 这也是迄今为止最新的 OpenGL 版本。 OpenGL 1.5 内包含 ARB 制定的 “ 正式扩展规格绘制语言 ” （ OpenGL Shading Language v1.0 ），该语言用于着色对象、顶点着色、片断着色等扩展功能，同时也将作为下一代 OpenGL 2.0 版本的内核。 OpenGL 1.5 的变化还增加了顶点缓冲对象（可提高透视性能）、非乘方纹理 ( 可提高纹理内存的使用效率 ) 以及阴影功能、隐蔽查询功能等等。
OpenGL 2.0 ：超强 API 现身
从 ARB 的惯例来看，划时代的 OpenGL 2.0 很有可能在今年 7 到 8 月份现身。需要提及一点， OpenGL 2.0 的主导者不再是 SGI （ SGI 忙于公司内部调整无暇他顾）、而是著名的专业显卡提供商的 3Dlabs 。为了一举改变 OpenGL 落后的状况， 3Dlabs 协同其他 ARB 成员制定了雄心勃勃的 OpenGL 2.0 开发计划。据悉， OpenGL 2.0 将在 OpenGL 1.3 基础上进行修改扩充、但它将有下面五个方面的重大改进： ① 复杂的核心被彻底精简； ② 完全的硬件可编程能力； ③ 改进的内存管理机制、支持高级像素处理； ④ 扩展至数字媒体领域，使之跨越高端图形和多媒体范畴； ⑤ 支持嵌入式图形应用。
为了在获得强大功能的同时保持理想的兼容性， OpenGL 2.0 将经历以下两个发展阶段：第一个阶段注重兼容能力和平滑过渡，为此， OpenGL 2.0 核心将在精简后的 OpenGL 1.3 功能模块的基础上加上可完全兼容的新功能共同组成（图 1 ），这种做法在满足兼容性的同时，还可将原有 OpenGL 中数量众多、且相互纠缠不清的扩展指令进行彻底精简。
第一阶段的任务只是为了过渡，而第二阶段才是 OpenGL 2.0 的真正成熟期。此时， ARB 将合成出一个 “ 纯 OpenGL 2.0” 内核，纯内核将包含更多新增加的 “ 精简型 API 函数 ” ，这些函数具有完全的可编程特性、结构简单高效、功能强大且应用灵活。除了完成这项任务外， ARB 组织还得指导开发商抛弃繁琐的 OpenGL 1.X 、转用更具弹性的 “ 纯 OpenGL 2.0” 。
到这里，非常有必要介绍所谓的 “ 纯 OpenGL 2.0” 有何不同之处，简单点说，这个 “ 纯 OpenGL 2.0” 主要由新加入的功能和 OpenGL 1.3 的部分功能共同构成，它主要包含了完全可编程能力、改进的内存管理机制和 OpenML 数字媒体功能等至关重要的新特性。
DirectX 9 API 中具有完备的可编程能力，这项特性最大的好处就是灵活性，游戏开发商可根据自身需要灵活地制作出自己想要的图形效果：更高精度、更快速度还是在两者间进行折衷。显卡厂商对 DirectX 9 的积极支持很大程度上就是因为这项可编程特性。现在， OpenGL 2.0 也将具有完整的可编程能力，而它提供的功能超过了 DirectX 9 。 OpenGL 2.0 的可编程功能包括可编程顶点处理、可编程片段处理和可编程图像格式三种：
● 可编程顶点处理：取代坐标转换、材质应用程序及光照运算，允许对个别顶点作随机运算；
● 可编程片段处理：取代材质存取、材质应用及雾化功能，允许个别片段的随机运算；
● 可编程图像格式：取代固定格式封装和解封装运算，并允许 OpenGL 在传送或接收像素数据时、将类型与格式进行任意组合。
OpenGL 2.0 对 OpenGL 1.X 僵化的内存管理机制进行了改进： OpenGL 1.X 的内存管理方式相当于黑箱作业，内存中的数据可被自动处理，应用程序无需了解运算结果和运算要花的时间，也无需控制存储空间分配及对象的存放，这种设计在当初是非常成功的，它将程序员从繁琐的内存控制工作中解放出来。但它的确无法有效控制对象的复制、搬移、删除或封装过程，内存的利用效率变得颇为低下，成为显卡性能的一大制约瓶颈。而 OpenGL 2.0 直接为这些数据对象建立了定位和连接的接口，同时充分利用顶点数组、图像、材质、着色、显示清单及像素缓冲区来对其作精确控制，此外 OpenGL 2.0 还采用了压缩技术来减少数据的移动量。这些措施使 OpenGL 2.0 获得了高效管理内存的能力，同时也保留了简单易用的优点。
OpenML 是一个针对数字视频、音频、动画等多媒体功能的应用程序接口，它原本由名为 “Khronos Group” 的机构掌管 —— 有趣的是，这个机构的核心成员包含 SGI 、 3Dlabs 、 Sun 、 Intel 、 Discreet 、 Evans 、 Sutherland 、 Pinnacle 和 RealViz 。 两相对比，不难发现 Khronos Group 组织和 ARB 组织的成员有许多重合，将 OpenML 整合入 OpenGL 2.0 自然是顺理成章。而这也使得 OpenGL 2.0 成为集高端图形、数字媒体于一身的超级应用程序接口。这还不是全部，嵌入式设备对图形应用的需求逐渐越来越为人关注，未来的掌上电脑、 PDA 甚至是手机都有可能使用 3D 图形，而这些领域尚是一片空白，显然极具发展潜力。 OpenGL 2.0 将增加嵌入式图形功能，而 ATI 近日推出的面向下一代手机、 PDA 和掌上电脑的 “IMAGEON 2300” 图像处理器就是采用该项 API 技术，相信 OpenGL 2.0 很有机会成为该领域的主宰。
OpenGL 的英文全称是 “Open Graphics Library” ，意为 “ 开放的图形程序接口 ” 。 OpenGL 的历史可以追溯到上个世纪 90 年代初，标准诞生之后它一直占据主导地位。而微软的 DirectX 出现的时间比 OpenGL 晚得多、功能也不及 OpenGL ，只不过最近几年 OpenGL 因发展迟缓才被 DirectX 追上而已。尽管如此， OpenGL 仍然是高端图形 API 的代名词，制定中的 OpenGL 2.0 以强劲的功能特性为业界瞩目，而显卡制造商对 OpenGL API 的重视程度并未缩减，在可预见的将来， OpenGL 还将引领专业图形和 3D 游戏的风潮。
OpenGL 发展历程
上个世纪 90 年代初， SGI 公司出于制造图形工作站产品的需要、开发出名为 “IRISGL” 的图形 API 并成为工业标准。在当时， IRISGL 的功能可谓十分强大，但它的可移植性却相当之差。有鉴于此， SGI 决定在 IRISGL 基础上开发出一种功能类似、但可移植性更好的图形 API— 这就是 OpenGL 。 OpenGL 被打造为开放性标准，任何软硬件厂商均可自由使用，这让它受到广泛的欢迎。
1992 年 7 月， SGI 正式发布 OpenGL 1.0 标准。 OpenGL 1.0 完全实现了 SGI 的预期设计目标：功能强大、移植性良好并能自由使用。随后， SGI 发起成立了 “OpenGL 架构委员会 ” （ OpenGL Architecture Review Board ，简称 ARB ）来共同管理和推广这项先进的标准， OpenGL 后继标准的制定权也逐渐转移给 ARB 组织。在 ARB 内部，产生新标准的过程非常民主化：各成员以投票的方式来决定新版 OpenGL 标准应具有的功能特性，并据投票结果制作正式标准文档，各软硬件厂商再根据这份标准文档的内容在自己的系统上实现；而所有的 OpenGL 版本都必须通过文档规定的全部测试项目方能生效。 ARB 组织的成员都非泛泛之辈，目前其核心成员包括 SGI 、 3Dlabs 、 Intel 、 IBM 、 nVIDIA 、 ATi 、 Microsoft 、 Apple 等业界领袖。
OpenGL 1.0 获得意料之中的巨大成功，专业图形领域唯它马首是瞻。看到这一点，微软甚为心动，当时它正在开发的 Windows NT 系统如果获得 OpenGL 的支持无疑会如虎添翼；而 SGI 也希望能够让 OpenGL 广为流传。于是 SGI 和微软进行首次合作、联手将 OpenGL 1.0 移植到 Windows NT 平台。这项工作自然没有什么悬念，适用于 NT 的 OpenGL 1.0 顺利推出，这使得 Windows NT 系统成为图形工作站的又一个可选操作平台，很多运行于 UNIX 之下的专业图形软件也逐渐被移植，微软和 SGI 都如愿以偿。
1995 年， SGI 推出了更为完善的 OpenGL 1.1 版本。 OpenGL 1.1 的性能比 1.0 版提高甚多，同时还加入了诸如顶点数组、顶点位置、新纹理等新特性，并增强了元文件对 OpenGL 的调用等等。 OpenGL 1.1 同样获得了成功，而它也有对应的 Windows NT 版本。
1997 年，受 3D 显卡的刺激， Windows 95 平台下开始涌现出大量的 3D 游戏，可微软自己的 Direct 3D 3.0 图形接口极为糟糕， idSoftware 公司的顶尖程序员 John Carmack （ Quake 之父）嘲讽它简直就是 “ 支离破碎的 API” 。很自然，强大的 OpenGL 成为取代 DirectX 的最佳选择。但问题是微软虽然在 NT 系统中引入了 OpenGL ，但其同时代的 Windows 95 却无法支持 OpenGL ，面对这种局面， idSoftware 公司联合其它游戏开发商强烈要求微软在 Windows 95 中也引入 OpenGL API ，微软也很了解自己的 “Direct 3D 3.0” 是什么货色、它很快就接受了这项建议。而后， id 公司开发出基于 OpenGL 的 Quake2 ，想必有过 3 年以上游戏玩龄的读者都会记得 Quake2 那无以伦比的 3D 场景和激烈刺激的竞技画面。而 OpenGL API 因此立下大功，几乎所有游戏开发商都转向 OpenGL ，微软后来也不得不顺应潮流、在 Windows95 OSR2 版及 Windows 98 中正式支持 OpenGL ，相关游戏开始大量涌现，而 AutoCAD 、 3DS MAX 、 Maya 等许多专业 3D 设计软件也被移植到普通 PC 平台。今天，预算有限的设计者可以在 PC 中运行这些软件，莫不拜 OpenGL 所赐。
1999 年， OpenGL 再度发生变革，但这次它遇到的是发展史上的重大危机： SGI 决定与微软联手开发下一代图形接口 ——Ferihant 。 Ferihant 应用于 Windows 系统中，作为 OpenGL 和 DirectX 的取代者。为此， Ferihant 将包含 DirectX 与 OpenGL 各自的优点，并加入场景贴图之类的高级功能。由于有了 Ferihant ， SGI 停止了原先的 Windows 版 OpenGL 开发计划，外界对此表示赞赏。然而 Ferihant 计划没进行多久，双方的合作就出现裂痕，微软不积极合作，光想把 SGI 的图形技术并入 DirectX 的做法令 SGI 非常不满， SGI 随后宣布中止合作并撤回所有的开发人员， Ferihant 遂告夭折。在这之后， OpenGL 和 DirectX 似乎互不相干，继续在 PC 平台上发展，但状况对比鲜明： DirectX 从此突飞猛进，而 OpenGL 却长期原地徘徊。
2001 年 8 月， ARB 发布 OpenGL 1.3 规范，它增加了立方纹理贴图、纹理环境、多重采样、纹理框架压缩等扩展指令，但是改进程度非常有限； 2002 年 7 月， ARB 正式发布 OpenGL 1.4 ，它也只加入了深度纹理／阴影纹理、顶点设计框架、自动纹理贴图等简单的功能，越来越落后于图形硬件技术的飞速发展。而此期间 DirectX 突飞猛进， DirectX 8 API 更是正式成为娱乐显卡的标准， id 公司所形容的 “ 支离破碎的 DirectX” 早已非吴下阿蒙，大量的 3D 游戏转向了 DirectX 体系。
OpenGL 落后于时代并非 ARB 组织技术不佳，根本症结在于确定 OpenGL 标准的民主机制：各成员通过投票表决。在实际操作中，这些成员往往基于自身利益而产生意见分歧，为了照顾多数人的利益 OpenGL 不得不变得复杂臃肿、开发进度缓慢。我们可以看到，在 OpenGL 1.0 之后的各个版本只是进行一些扩展指令集的升级，而它对显卡硬件中不断涌现出的先进特性熟视无睹，同为 ARB 成员之一的微软对此抱怨不已，后来它干脆彻底抛开 OpenGL 、将全部精力投到自家的 DirectX 。大获成功的 DirectX 7 、 DirectX 8 就是在此种背景下出现的。
2003 年的 7 月， ARB 公布 OpenGL 1.5 规范 —— 这也是迄今为止最新的 OpenGL 版本。 OpenGL 1.5 内包含 ARB 制定的 “ 正式扩展规格绘制语言 ” （ OpenGL Shading Language v1.0 ），该语言用于着色对象、顶点着色、片断着色等扩展功能，同时也将作为下一代 OpenGL 2.0 版本的内核。 OpenGL 1.5 的变化还增加了顶点缓冲对象（可提高透视性能）、非乘方纹理 ( 可提高纹理内存的使用效率 ) 以及阴影功能、隐蔽查询功能等等。
OpenGL 2.0 ：超强 API 现身
从 ARB 的惯例来看，划时代的 OpenGL 2.0 很有可能在今年 7 到 8 月份现身。需要提及一点， OpenGL 2.0 的主导者不再是 SGI （ SGI 忙于公司内部调整无暇他顾）、而是著名的专业显卡提供商的 3Dlabs 。为了一举改变 OpenGL 落后的状况， 3Dlabs 协同其他 ARB 成员制定了雄心勃勃的 OpenGL 2.0 开发计划。据悉， OpenGL 2.0 将在 OpenGL 1.3 基础上进行修改扩充、但它将有下面五个方面的重大改进： ① 复杂的核心被彻底精简； ② 完全的硬件可编程能力； ③ 改进的内存管理机制、支持高级像素处理； ④ 扩展至数字媒体领域，使之跨越高端图形和多媒体范畴； ⑤ 支持嵌入式图形应用。
为了在获得强大功能的同时保持理想的兼容性， OpenGL 2.0 将经历以下两个发展阶段：第一个阶段注重兼容能力和平滑过渡，为此， OpenGL 2.0 核心将在精简后的 OpenGL 1.3 功能模块的基础上加上可完全兼容的新功能共同组成（图 1 ），这种做法在满足兼容性的同时，还可将原有 OpenGL 中数量众多、且相互纠缠不清的扩展指令进行彻底精简。
第一阶段的任务只是为了过渡，而第二阶段才是 OpenGL 2.0 的真正成熟期。此时， ARB 将合成出一个 “ 纯 OpenGL 2.0” 内核，纯内核将包含更多新增加的 “ 精简型 API 函数 ” ，这些函数具有完全的可编程特性、结构简单高效、功能强大且应用灵活。除了完成这项任务外， ARB 组织还得指导开发商抛弃繁琐的 OpenGL 1.X 、转用更具弹性的 “ 纯 OpenGL 2.0” 。
到这里，非常有必要介绍所谓的 “ 纯 OpenGL 2.0” 有何不同之处，简单点说，这个 “ 纯 OpenGL 2.0” 主要由新加入的功能和 OpenGL 1.3 的部分功能共同构成，它主要包含了完全可编程能力、改进的内存管理机制和 OpenML 数字媒体功能等至关重要的新特性。
DirectX 9 API 中具有完备的可编程能力，这项特性最大的好处就是灵活性，游戏开发商可根据自身需要灵活地制作出自己想要的图形效果：更高精度、更快速度还是在两者间进行折衷。显卡厂商对 DirectX 9 的积极支持很大程度上就是因为这项可编程特性。现在， OpenGL 2.0 也将具有完整的可编程能力，而它提供的功能超过了 DirectX 9 。 OpenGL 2.0 的可编程功能包括可编程顶点处理、可编程片段处理和可编程图像格式三种：
● 可编程顶点处理：取代坐标转换、材质应用程序及光照运算，允许对个别顶点作随机运算；
● 可编程片段处理：取代材质存取、材质应用及雾化功能，允许个别片段的随机运算；
● 可编程图像格式：取代固定格式封装和解封装运算，并允许 OpenGL 在传送或接收像素数据时、将类型与格式进行任意组合。
OpenGL 2.0 对 OpenGL 1.X 僵化的内存管理机制进行了改进： OpenGL 1.X 的内存管理方式相当于黑箱作业，内存中的数据可被自动处理，应用程序无需了解运算结果和运算要花的时间，也无需控制存储空间分配及对象的存放，这种设计在当初是非常成功的，它将程序员从繁琐的内存控制工作中解放出来。但它的确无法有效控制对象的复制、搬移、删除或封装过程，内存的利用效率变得颇为低下，成为显卡性能的一大制约瓶颈。而 OpenGL 2.0 直接为这些数据对象建立了定位和连接的接口，同时充分利用顶点数组、图像、材质、着色、显示清单及像素缓冲区来对其作精确控制，此外 OpenGL 2.0 还采用了压缩技术来减少数据的移动量。这些措施使 OpenGL 2.0 获得了高效管理内存的能力，同时也保留了简单易用的优点。
OpenML 是一个针对数字视频、音频、动画等多媒体功能的应用程序接口，它原本由名为 “Khronos Group” 的机构掌管 —— 有趣的是，这个机构的核心成员包含 SGI 、 3Dlabs 、 Sun 、 Intel 、 Discreet 、 Evans 、 Sutherland 、 Pinnacle 和 RealViz 。 两相对比，不难发现 Khronos Group 组织和 ARB 组织的成员有许多重合，将 OpenML 整合入 OpenGL 2.0 自然是顺理成章。而这也使得 OpenGL 2.0 成为集高端图形、数字媒体于一身的超级应用程序接口。这还不是全部，嵌入式设备对图形应用的需求逐渐越来越为人关注，未来的掌上电脑、 PDA 甚至是手机都有可能使用 3D 图形，而这些领域尚是一片空白，显然极具发展潜力。 OpenGL 2.0 将增加嵌入式图形功能，而 ATI 近日推出的面向下一代手机、 PDA 和掌上电脑的 “IMAGEON 2300” 图像处理器就是采用该项 API 技术，相信 OpenGL 2.0 很有机会成为该领域的主宰。
goldegg
2004-10-23
, 17:27
专注娱乐应用的
DirectX
DirectX 是微软独自开发的 API ，很多人认为它只是一个专门针对显卡的图形 API ，其实不然。 DirectX 的服务范围涵盖图形、输入 / 输出、音频、显示、多媒体等等许多领域，组件包括 Direct Graphics(Direct 3D+Direct Draw) 、 Direct Input 、 Direct Play 、 Direct Sound 、 Direct Show 、 Direct Setup 、 Direct Media Objects 等等，只是因图形方面的应用最为重要而为人熟知，微软近些年对 DirectX 作版本升级也主要着眼于图形领域。
DirectX 的发展之路并不顺利，在相当长的时间内都为软硬件厂商所排斥，但在 DirectX 7.0 之后，它在人们心目中的形象逐渐被扭转，而 DirectX 8.0 的优异表现令它具备了超越 OpenGL 的实力，目前的 DirectX 9 更一举成为 PC 领域 3D 图形 API 的主宰者。在介绍 DirectX 9 之前，我们有必要回顾一下 DirectX 的发展历史。
DirectX 发展历程
1995 年，微软的第一个 API——DirectX 1 发布。这个 API 极其简单，它仅提供了对 2D 图形和基本音频功能的支持，主要是为了弥补 Windows 95 对图形管理的不足。这完全可以理解，当时的在 PC 中还不存在 3D 游戏，也没有什么 3D 显卡，对于面向商业用户和家庭的 PC 而言 3D 功能也不是必要的。可想而知， DirectX 1 几乎毫无声息，采不采用根本无关紧要。
1996 年， DirectX 的第二个版本 DirectX 2 推出。它引入了 Direct3D 技术、需要执行缓冲区，看起来与 DirectX 1 有了巨大的变化。 DirectX 2 采用平滑模拟和 RGB 模拟两种方式来加速 3D 图像生成；同时，原有的 2D 部分得到了有效增强、加入了 2D 动态效果，并更正了原有的一些 bug 。此外， DirectX 2 的用户设置程序也变得更加友好。整个 DirectX 的设计架构基本确定，它也是如今的 DirectX 的雏形。 Trident 、 S3 公司开始支持 DirectX 2 ，代表游戏是《红色警报》和《命令与征服》。
同年， DirectX 3 发布，不过它只是 DirectX 2 的简单改进而已，对 DirectSound 和 DirectPlay 等功能作了些变动，总体来说还属于功能简单的 DirectX 2 技术体系。 微软还发布过 DirectX 3.0a 版本，它则是继续修正错误的升级版。 DirectX 3 还是有一定的拥戴者， nVIDIA Riva128 和 Intel 的 i740 都支持它，代表游戏包括《摩托英豪》和《极品飞车 3 》。
1997 年，微软发布 DirectX 5——DirectX 4 被直接跳过。 DirectX 5 在技术上有了明显提高，微软对 Direct 3D 作了彻底修改：加入雾化效果、 Alpha 混合等特效，大大增强 3D 游戏的真实感；加入 S3 的纹理压缩技术，有效提高了显存带宽的利用率。此外， DirectX 5 在音频、游戏控制方面均做了大量的改进，游戏开放商的移植工作也变得更简单， DirectX 5 可以说是 DirectX API 技术成熟的标志。 nVIDIA RivaTNT 支持 DirectX 5 ，虽然 nVIDIA 当时尚未成为图形业的霸主，但 RivaTNT 已展现出强劲的实力， DirectX 5 规格应该说立下了一定功劳，而它的代表游戏就是《古墓丽影 3 》。 这个时候， OpenGL 已经在《 Quake2 》之类的 3D 游戏中发挥威力，许多 3D 游戏都选择了 Quake2 引擎，至少在纯 3D 领域， OpenGL 的影响力远甚于 DirectX 5 。
1998 年， DirectX 6 推出。这个时候， DirectX 已被许多厂商认可并成为 2D 游戏和部分 3D 游戏的标准 API 。 DirectX 6 的进步同样显而易见：可优化 3D 图像质量的双线性过滤、三线性过滤技术被引入，实现了多纹理、顶点缓冲和凸凹映射等功能。 nVIDIA 的 TNT2 继续对它提供支持，代表游戏则是《极品飞车 5 》和《 CS 》。但 OpenGL 的影响力仍大过 DirectX 6 ，这很大程度上是受 idSoftware 的 Quake Ⅲ 游戏影响，该款游戏只能运行于 OpenGL 模式下。此外，基于 Quake Ⅱ 引擎的 Counter Strike 游戏火爆一时并延续至今，这些游戏在 OpenGL 模式下具有更理想的性能表现。这个时候， OpenGL 还被广泛认为优于 DirectX 。
1999 年， DirectX 7 发布 —— 它也是 DirectX API 发展史上的转折点。这个时候， nVIDIA 已经取代 3dfx 成为图形领域新霸主，它开创的 GPU 概念更是将对手远远抛到了后头。 GPU 意即 “ 图形处理器 ” ，专门负责 3D 游戏中物体的几何转换和光源处理，此前这类任务是由 CPU 来完成的， GPU 的概念堪称图形技术的里程碑：一方面，显卡摆脱了 CPU 的限制、可以自主决定系统的图形性能；另一方面， CPU 也从繁重的劳动中获得解放、可将更多的运算力用于其他任务的处理。第一枚 GPU 图形芯片是 nVIDIA 的 GeForce ，微软及时在 DirectX 7 中对其提供了支持：加入硬件几何转换与光源处理技术（即所谓的 “ 硬件 T&L” ）以及贴图的矩阵混合，自然，它获得更广的支持度。包括后来 ATI 的 Radeon 显卡也支持 DirectX 7 。
真正的质变发生在 DirectX 8 身上。 DirectX 8 于 2000 年推出，同 DirectX 7 相比， DirectX 8 没有硬件 T&L 的概念，取而代之的是具有可编程能力的 Vertex Shader （顶点着色引擎）和 Pixel Shader （像素着色引擎）。相比机械式的硬件 T&L ， Vertex Shader 和 Pixel Shader 可提供更优异的效能，例如创建出水波纹的动态效果、衣物的褶皱及光线变化效果，这在以往根本不可能实现。此外， DirectX 8 在视频、音频等方面也有许多重要的改进，综合实力全盘超越 OpenGL ， nVIDIA 和 ATI 都将它作为标准的图形 API 加以支持， OpenGL 则退缩为它们的第二选择，对游戏开发商而言也是如此。 2001 年，微软发布 DirectX 8 的升级版： DirectX 8.1 ，它将 Pixel Shader 的版本提高到 1.4 ，同样支持者趋之若鹜，直到今天 DirectX 8.1 还是中低端游戏显卡的标准 API ，当前大量的 3D 游戏和几乎所有的 2D 游戏都对它提供支持，当然，今后它的地位会慢慢被 DirectX 9 所接替。
DirectX 9 介绍
DirectX 9 是当前无可争议的新一代图形 API 标准， nVIDIA 、 ATI 、 XGI 等图形厂商都以它作为产品开发的指导方向，新一代游戏也积极提供支持。 DirectX 9 构建于 DirectX 8.0/8.1 ，但它并不是功能上的小修小补，而是带来了许多革命性的新特性。这些新特性主要包括以下几个方面：将顶点着色引擎、像素着色引擎升级至 2.0 版本；浮点色彩处理的精度提高到 128 位（ DirectX 8.0/8.1 为 32 位）；引入硬件位移贴图的概念；支持 40 位真彩色；增加 Z 伽玛修正和提供对剪裁平面技术的支持等等，下面我们将详细向大家介绍这些新特性。
可编程的顶点着色引擎（ Vertex Shader ）和像素着色引擎（ Pixel Shader ）是 DirectX 8 引入的特性，它给游戏开发商提供了更高的自由度和更容易实现的编程机制。 对显卡而言，这是一个极富意义的重大进步。不过，作为一项新功能，初期版本的顶点着色引擎和像素着色引擎都显得不够成熟，所以微软在 1.0 版之后迅速推出 1.1 、 1.3 、 1.4 等多个版本，后续版本在功能上有所增强并修正了一些 bug 。而 DirectX 9 将二者同时提升至 2.0 版本，顶点着色引擎 2.0 的主要改进是引入流程控制、增加条件跳转、 循环和子程序等运行规则，最大指令数提高到 1024 条 (DirectX 8.0/8.1 为 128 条指令 ) ；而像素着色引擎 2.0 虽未能支持流程控制功能，但它的最大指令数也提升至 160 条。这些措施都使得显卡的可编程功能变得更加强壮。
128 位浮点色彩处理也是 DirectX 9 最重要的改进之一，该项特性能有效减小 3D 画面生成过程中难以避免的误差，使得最终生成的 3D 画面保持极高的色彩逼真度。那么， DirectX 9 如何实现这一点呢？要回答这个问题，我们就应该从 PC 的色彩精度谈起。
众所周知，目前 PC 的色彩精度为 32 位，其中有 8 位 Alpha 值用于控制透明效果，而剩下的 24 位才真正用于物理色彩的显示。因 PC 基于 RGB （红绿蓝）三原色体系， 24 位由红、绿、蓝三个色彩通道分享、每通道 8 位色，因此 PC 实际上可以显示出 16.7 M 种物理色彩。如果单单用于静态画面显示，这个数字应该是足够用的，但在 3D 画面生成的动态环境中就不同了。每个色彩通道为 8 位精度、色彩的强度只有 256 种变化；而 3D 画面生成往往需要几十个光照计算和纹理计算，期间涉及到大量色彩值的转换处理，如果这些中间值只能使用 256 种色彩状态来保存，误差将不可避免；经过几十步计算之后，原本可忽略的色彩误差会被明显放大，导致屏幕上生成的 3D 画面出现严重的色彩失真。
DirectX 9 引入的 128 位浮点色彩处理机制可以很好地解决这个问题：每个色彩通道可获得 32 位精度，颜色总数达到 232 种（超过 4 亿种），误差值可被降低到很低的水平。从这个意义上说，所有符合 DirectX 9 规格的显卡在配合支持 DirectX 9 的 3D 游戏时可获得更真实的色彩表现，而 DirectX 8.0/8.1 平台就无法实现这一点。不过， 128 位色彩精度意味着要处理的数据量剧增，这就对图形芯片的能力提出了更高的要求，幸亏显卡硬件的超快发展速度提供了足够的保障。
DirectX 9 的静态色彩显示机制同样发生了改变： 32 位色、每色彩通道 8 位精度是业界基准，对普通办公娱乐而言足够应付，但在专业图形处理场合，每通道区区 8 位精度是绝对不够的，微软一直期望 DirectX 向专业应用进军，提高色彩精度势在必行。根据这一要求， DirectX 9 引入 40 位真彩色机制：每个色彩通道和 Alpha 通道的精度都提高到 10 位，可显示的物理色彩总数达到 30 位、也就是超过 10 亿种色彩！我们可以从图 5 中清楚看到 40 位色与 32 位色的区别： 40 位色显示的灰度过渡非常平滑、近乎是无缝进行的；而 32 位色的灰度过渡存在明显的间隔。
要真正在实用中实现 40 位色显示，除了需要支持 DirectX 9 的显卡外，还需要操作系统和显示器的支持。操作系统方面估计得等到微软的 Longhorn 发布；至于显示器就更成问题： CRT 对色彩数没有限制，但它目前已逐步被淘汰，现有的 LCD 显示器只能显示出 18 位色。幸好，微软和夏普联合进行新一代 LCD 显示器的研发，估计 2005 年我们就可看到支持 40 位色的高质量 LCD 显示器出现。
环境凹凸贴图是 Matrox 当年在 G400 引入的技术，它通过单纯的模型贴图使 3D 场景变得更加真实。现在 DirectX 9 引入了更先进的位移贴图（ Displacement Mapping ）功能，它的开发者仍然是 Matrox ，在 Parhelia-512( 幻日 ) 显卡中得以实现。和凹凸贴图相比，位移贴图实现起来更复杂：它使用一张基本纹理、一张光照纹理以及一张最为重要的高程纹理来完成模型外观的修饰。即便所使用的模型只是普通的平面，在经过位移贴图的精细处理之后，这个模型就可以演变生成一个逼真复杂的地貌环境，对需要渲染复杂场景的 3D 游戏而言，这项功能无疑是如虎添翼。微软为 DirectX 9 定制了两个版本的位移贴图功能：一个是为多数厂商选用、名为 “ 预计算 / 预描绘 ” 的标准版本，其特点是处理速度快、但无法进行自适应纹理镶嵌和细节处理技术 (Levels-of-Detail ， LoD) ，在苛求精美画面的场合难以发挥效用；另一个则是供 Matrox 显卡独家使用的采样位移贴图（这估计是微软对 Matrox 在位移贴图中所作贡献的一点回馈），它可支持自适应纹理镶嵌和细节处理技术，在地形生成中表现最为出色，而且使用的方法比较简单，但其缺陷是速度比较慢。因 Matrox 的 Parhelia 显卡基本上在娱乐市场完全失败，采样位移贴图也形同虚设，或许微软会将它取代精度不佳的标准版本也说不定。
在 3D 物体的表面处理方面，硬件位移贴图的效果要比环境凹凸贴图更为精美，我们不妨用下面这个例子来说明它与凹凸贴图的差别：在图 6 的三个球体中，第一个是没有经过处理的原始图像；第二个是经过凹凸贴图处理的球体，它的表面能表现出一定的立体感，不过还不是太明显；而第三幅则是经过 DirectX 9 的硬件位移贴图生成的图形，其表面贴图的立体感相当强烈、极具真实感。
DirectX 9 引入的伽马修正功能着眼于 2D ／ 3D 场景的色彩调节，以获得良好的视觉感受。虽然我们在 Photoshop 等专业作图软件中就可获得伽马修正功能，但这只涉及对 2D 图像的色彩调节，只有那些昂贵的专业级图形工作站才可能拥有针对 3D 程序的 “Z 伽马修正 ” 功能。而 DirectX 9 改变了这一切：未来的 2D ／ 3D 程序均可支持伽马修正，从而提供更完美的视觉效果。
DirectX 9 的平面剪裁技术则是通过切除不必要的图形运算来提高性能，其实这一点都不新鲜，在 STM Kyro 显卡家族中我们就可以看到类似的隐面去除（ HSR ）技术，二者都是将屏幕不可见的部分 “ 剪掉 ” ，让显卡不用处理这部分的内容，以此减轻显卡计算量并提高性能。不过，与隐面去除有所差别： DirectX 9 的平面剪裁不仅可用于 3D 处理，还适用于多窗口开启或视频内容剪辑，不过这看起来没什么太大作用，毕竟 2D 环境基本不耗费多少硬件资源。
DirectX 是微软独自开发的 API ，很多人认为它只是一个专门针对显卡的图形 API ，其实不然。 DirectX 的服务范围涵盖图形、输入 / 输出、音频、显示、多媒体等等许多领域，组件包括 Direct Graphics(Direct 3D+Direct Draw) 、 Direct Input 、 Direct Play 、 Direct Sound 、 Direct Show 、 Direct Setup 、 Direct Media Objects 等等，只是因图形方面的应用最为重要而为人熟知，微软近些年对 DirectX 作版本升级也主要着眼于图形领域。
DirectX 的发展之路并不顺利，在相当长的时间内都为软硬件厂商所排斥，但在 DirectX 7.0 之后，它在人们心目中的形象逐渐被扭转，而 DirectX 8.0 的优异表现令它具备了超越 OpenGL 的实力，目前的 DirectX 9 更一举成为 PC 领域 3D 图形 API 的主宰者。在介绍 DirectX 9 之前，我们有必要回顾一下 DirectX 的发展历史。
DirectX 发展历程
1995 年，微软的第一个 API——DirectX 1 发布。这个 API 极其简单，它仅提供了对 2D 图形和基本音频功能的支持，主要是为了弥补 Windows 95 对图形管理的不足。这完全可以理解，当时的在 PC 中还不存在 3D 游戏，也没有什么 3D 显卡，对于面向商业用户和家庭的 PC 而言 3D 功能也不是必要的。可想而知， DirectX 1 几乎毫无声息，采不采用根本无关紧要。
1996 年， DirectX 的第二个版本 DirectX 2 推出。它引入了 Direct3D 技术、需要执行缓冲区，看起来与 DirectX 1 有了巨大的变化。 DirectX 2 采用平滑模拟和 RGB 模拟两种方式来加速 3D 图像生成；同时，原有的 2D 部分得到了有效增强、加入了 2D 动态效果，并更正了原有的一些 bug 。此外， DirectX 2 的用户设置程序也变得更加友好。整个 DirectX 的设计架构基本确定，它也是如今的 DirectX 的雏形。 Trident 、 S3 公司开始支持 DirectX 2 ，代表游戏是《红色警报》和《命令与征服》。
同年， DirectX 3 发布，不过它只是 DirectX 2 的简单改进而已，对 DirectSound 和 DirectPlay 等功能作了些变动，总体来说还属于功能简单的 DirectX 2 技术体系。 微软还发布过 DirectX 3.0a 版本，它则是继续修正错误的升级版。 DirectX 3 还是有一定的拥戴者， nVIDIA Riva128 和 Intel 的 i740 都支持它，代表游戏包括《摩托英豪》和《极品飞车 3 》。
1997 年，微软发布 DirectX 5——DirectX 4 被直接跳过。 DirectX 5 在技术上有了明显提高，微软对 Direct 3D 作了彻底修改：加入雾化效果、 Alpha 混合等特效，大大增强 3D 游戏的真实感；加入 S3 的纹理压缩技术，有效提高了显存带宽的利用率。此外， DirectX 5 在音频、游戏控制方面均做了大量的改进，游戏开放商的移植工作也变得更简单， DirectX 5 可以说是 DirectX API 技术成熟的标志。 nVIDIA RivaTNT 支持 DirectX 5 ，虽然 nVIDIA 当时尚未成为图形业的霸主，但 RivaTNT 已展现出强劲的实力， DirectX 5 规格应该说立下了一定功劳，而它的代表游戏就是《古墓丽影 3 》。 这个时候， OpenGL 已经在《 Quake2 》之类的 3D 游戏中发挥威力，许多 3D 游戏都选择了 Quake2 引擎，至少在纯 3D 领域， OpenGL 的影响力远甚于 DirectX 5 。
1998 年， DirectX 6 推出。这个时候， DirectX 已被许多厂商认可并成为 2D 游戏和部分 3D 游戏的标准 API 。 DirectX 6 的进步同样显而易见：可优化 3D 图像质量的双线性过滤、三线性过滤技术被引入，实现了多纹理、顶点缓冲和凸凹映射等功能。 nVIDIA 的 TNT2 继续对它提供支持，代表游戏则是《极品飞车 5 》和《 CS 》。但 OpenGL 的影响力仍大过 DirectX 6 ，这很大程度上是受 idSoftware 的 Quake Ⅲ 游戏影响，该款游戏只能运行于 OpenGL 模式下。此外，基于 Quake Ⅱ 引擎的 Counter Strike 游戏火爆一时并延续至今，这些游戏在 OpenGL 模式下具有更理想的性能表现。这个时候， OpenGL 还被广泛认为优于 DirectX 。
1999 年， DirectX 7 发布 —— 它也是 DirectX API 发展史上的转折点。这个时候， nVIDIA 已经取代 3dfx 成为图形领域新霸主，它开创的 GPU 概念更是将对手远远抛到了后头。 GPU 意即 “ 图形处理器 ” ，专门负责 3D 游戏中物体的几何转换和光源处理，此前这类任务是由 CPU 来完成的， GPU 的概念堪称图形技术的里程碑：一方面，显卡摆脱了 CPU 的限制、可以自主决定系统的图形性能；另一方面， CPU 也从繁重的劳动中获得解放、可将更多的运算力用于其他任务的处理。第一枚 GPU 图形芯片是 nVIDIA 的 GeForce ，微软及时在 DirectX 7 中对其提供了支持：加入硬件几何转换与光源处理技术（即所谓的 “ 硬件 T&L” ）以及贴图的矩阵混合，自然，它获得更广的支持度。包括后来 ATI 的 Radeon 显卡也支持 DirectX 7 。
真正的质变发生在 DirectX 8 身上。 DirectX 8 于 2000 年推出，同 DirectX 7 相比， DirectX 8 没有硬件 T&L 的概念，取而代之的是具有可编程能力的 Vertex Shader （顶点着色引擎）和 Pixel Shader （像素着色引擎）。相比机械式的硬件 T&L ， Vertex Shader 和 Pixel Shader 可提供更优异的效能，例如创建出水波纹的动态效果、衣物的褶皱及光线变化效果，这在以往根本不可能实现。此外， DirectX 8 在视频、音频等方面也有许多重要的改进，综合实力全盘超越 OpenGL ， nVIDIA 和 ATI 都将它作为标准的图形 API 加以支持， OpenGL 则退缩为它们的第二选择，对游戏开发商而言也是如此。 2001 年，微软发布 DirectX 8 的升级版： DirectX 8.1 ，它将 Pixel Shader 的版本提高到 1.4 ，同样支持者趋之若鹜，直到今天 DirectX 8.1 还是中低端游戏显卡的标准 API ，当前大量的 3D 游戏和几乎所有的 2D 游戏都对它提供支持，当然，今后它的地位会慢慢被 DirectX 9 所接替。
DirectX 9 介绍
DirectX 9 是当前无可争议的新一代图形 API 标准， nVIDIA 、 ATI 、 XGI 等图形厂商都以它作为产品开发的指导方向，新一代游戏也积极提供支持。 DirectX 9 构建于 DirectX 8.0/8.1 ，但它并不是功能上的小修小补，而是带来了许多革命性的新特性。这些新特性主要包括以下几个方面：将顶点着色引擎、像素着色引擎升级至 2.0 版本；浮点色彩处理的精度提高到 128 位（ DirectX 8.0/8.1 为 32 位）；引入硬件位移贴图的概念；支持 40 位真彩色；增加 Z 伽玛修正和提供对剪裁平面技术的支持等等，下面我们将详细向大家介绍这些新特性。
可编程的顶点着色引擎（ Vertex Shader ）和像素着色引擎（ Pixel Shader ）是 DirectX 8 引入的特性，它给游戏开发商提供了更高的自由度和更容易实现的编程机制。 对显卡而言，这是一个极富意义的重大进步。不过，作为一项新功能，初期版本的顶点着色引擎和像素着色引擎都显得不够成熟，所以微软在 1.0 版之后迅速推出 1.1 、 1.3 、 1.4 等多个版本，后续版本在功能上有所增强并修正了一些 bug 。而 DirectX 9 将二者同时提升至 2.0 版本，顶点着色引擎 2.0 的主要改进是引入流程控制、增加条件跳转、 循环和子程序等运行规则，最大指令数提高到 1024 条 (DirectX 8.0/8.1 为 128 条指令 ) ；而像素着色引擎 2.0 虽未能支持流程控制功能，但它的最大指令数也提升至 160 条。这些措施都使得显卡的可编程功能变得更加强壮。
128 位浮点色彩处理也是 DirectX 9 最重要的改进之一，该项特性能有效减小 3D 画面生成过程中难以避免的误差，使得最终生成的 3D 画面保持极高的色彩逼真度。那么， DirectX 9 如何实现这一点呢？要回答这个问题，我们就应该从 PC 的色彩精度谈起。
众所周知，目前 PC 的色彩精度为 32 位，其中有 8 位 Alpha 值用于控制透明效果，而剩下的 24 位才真正用于物理色彩的显示。因 PC 基于 RGB （红绿蓝）三原色体系， 24 位由红、绿、蓝三个色彩通道分享、每通道 8 位色，因此 PC 实际上可以显示出 16.7 M 种物理色彩。如果单单用于静态画面显示，这个数字应该是足够用的，但在 3D 画面生成的动态环境中就不同了。每个色彩通道为 8 位精度、色彩的强度只有 256 种变化；而 3D 画面生成往往需要几十个光照计算和纹理计算，期间涉及到大量色彩值的转换处理，如果这些中间值只能使用 256 种色彩状态来保存，误差将不可避免；经过几十步计算之后，原本可忽略的色彩误差会被明显放大，导致屏幕上生成的 3D 画面出现严重的色彩失真。
DirectX 9 引入的 128 位浮点色彩处理机制可以很好地解决这个问题：每个色彩通道可获得 32 位精度，颜色总数达到 232 种（超过 4 亿种），误差值可被降低到很低的水平。从这个意义上说，所有符合 DirectX 9 规格的显卡在配合支持 DirectX 9 的 3D 游戏时可获得更真实的色彩表现，而 DirectX 8.0/8.1 平台就无法实现这一点。不过， 128 位色彩精度意味着要处理的数据量剧增，这就对图形芯片的能力提出了更高的要求，幸亏显卡硬件的超快发展速度提供了足够的保障。
DirectX 9 的静态色彩显示机制同样发生了改变： 32 位色、每色彩通道 8 位精度是业界基准，对普通办公娱乐而言足够应付，但在专业图形处理场合，每通道区区 8 位精度是绝对不够的，微软一直期望 DirectX 向专业应用进军，提高色彩精度势在必行。根据这一要求， DirectX 9 引入 40 位真彩色机制：每个色彩通道和 Alpha 通道的精度都提高到 10 位，可显示的物理色彩总数达到 30 位、也就是超过 10 亿种色彩！我们可以从图 5 中清楚看到 40 位色与 32 位色的区别： 40 位色显示的灰度过渡非常平滑、近乎是无缝进行的；而 32 位色的灰度过渡存在明显的间隔。
要真正在实用中实现 40 位色显示，除了需要支持 DirectX 9 的显卡外，还需要操作系统和显示器的支持。操作系统方面估计得等到微软的 Longhorn 发布；至于显示器就更成问题： CRT 对色彩数没有限制，但它目前已逐步被淘汰，现有的 LCD 显示器只能显示出 18 位色。幸好，微软和夏普联合进行新一代 LCD 显示器的研发，估计 2005 年我们就可看到支持 40 位色的高质量 LCD 显示器出现。
环境凹凸贴图是 Matrox 当年在 G400 引入的技术，它通过单纯的模型贴图使 3D 场景变得更加真实。现在 DirectX 9 引入了更先进的位移贴图（ Displacement Mapping ）功能，它的开发者仍然是 Matrox ，在 Parhelia-512( 幻日 ) 显卡中得以实现。和凹凸贴图相比，位移贴图实现起来更复杂：它使用一张基本纹理、一张光照纹理以及一张最为重要的高程纹理来完成模型外观的修饰。即便所使用的模型只是普通的平面，在经过位移贴图的精细处理之后，这个模型就可以演变生成一个逼真复杂的地貌环境，对需要渲染复杂场景的 3D 游戏而言，这项功能无疑是如虎添翼。微软为 DirectX 9 定制了两个版本的位移贴图功能：一个是为多数厂商选用、名为 “ 预计算 / 预描绘 ” 的标准版本，其特点是处理速度快、但无法进行自适应纹理镶嵌和细节处理技术 (Levels-of-Detail ， LoD) ，在苛求精美画面的场合难以发挥效用；另一个则是供 Matrox 显卡独家使用的采样位移贴图（这估计是微软对 Matrox 在位移贴图中所作贡献的一点回馈），它可支持自适应纹理镶嵌和细节处理技术，在地形生成中表现最为出色，而且使用的方法比较简单，但其缺陷是速度比较慢。因 Matrox 的 Parhelia 显卡基本上在娱乐市场完全失败，采样位移贴图也形同虚设，或许微软会将它取代精度不佳的标准版本也说不定。
在 3D 物体的表面处理方面，硬件位移贴图的效果要比环境凹凸贴图更为精美，我们不妨用下面这个例子来说明它与凹凸贴图的差别：在图 6 的三个球体中，第一个是没有经过处理的原始图像；第二个是经过凹凸贴图处理的球体，它的表面能表现出一定的立体感，不过还不是太明显；而第三幅则是经过 DirectX 9 的硬件位移贴图生成的图形，其表面贴图的立体感相当强烈、极具真实感。
DirectX 9 引入的伽马修正功能着眼于 2D ／ 3D 场景的色彩调节，以获得良好的视觉感受。虽然我们在 Photoshop 等专业作图软件中就可获得伽马修正功能，但这只涉及对 2D 图像的色彩调节，只有那些昂贵的专业级图形工作站才可能拥有针对 3D 程序的 “Z 伽马修正 ” 功能。而 DirectX 9 改变了这一切：未来的 2D ／ 3D 程序均可支持伽马修正，从而提供更完美的视觉效果。
DirectX 9 的平面剪裁技术则是通过切除不必要的图形运算来提高性能，其实这一点都不新鲜，在 STM Kyro 显卡家族中我们就可以看到类似的隐面去除（ HSR ）技术，二者都是将屏幕不可见的部分 “ 剪掉 ” ，让显卡不用处理这部分的内容，以此减轻显卡计算量并提高性能。不过，与隐面去除有所差别： DirectX 9 的平面剪裁不仅可用于 3D 处理，还适用于多窗口开启或视频内容剪辑，不过这看起来没什么太大作用，毕竟 2D 环境基本不耗费多少硬件资源。
goldegg
2004-10-23
, 17:28
未来：
OpenGL
、
DirectX
并行发展
作为两大图形 API 阵营， OpenGL 和 DirectX 在各自的发展中形成鲜明的特点：即便处于目前的低潮状态， OpenGL 仍然牢牢把持着专业绘图领域，而 DirectX 在此毫无竞争力，功能更强大的 OpenGL 2.0 无疑将继续保持垄断性地位。但在 3D 游戏领域， OpenGL 的确是处于弱势地位，但它也没有丢光所有的市场，若 OpenGL 2.0 表现理想，重新赢得广泛支持也并不困难。而 DirectX 9 已经牢牢在游戏中站稳了脚跟，凭借领先的功能特性和微软在操作系统方面的先天优势， DirectX 9 及未来的 DirectX 10 理所当然会成为多数游戏开发商的首选，它的应用范围除了 3D 游戏还涵盖 2D 游戏领域，这正是 OpenGL 所欠缺的。
其实， OpenGL 和 DirectX 并不是完全对立的，二者存在一定的竞争又需要进行相互协作， ARB 公布 OpenGL 2.0 的改进和开发计划后，微软表现出异乎寻常的兴趣，而 ARB 的各个成员也在 3Dlabs 的带领下抛开分歧进行紧密的合作；各成员表示未来将专注于实现 OpenGL 2.0 的开发目标，而不再会为了自身利益让 OpenGL 变得一团糟，就连一向针锋相对的 nVIDIA 与 ATI 也致力于彼此技术的整合。 ARB 集体宣誓： “ 所有送至 OpenGL 的创意想法，一经采用，便免费公开给所有人使用。 ” 相信这种开放性的做法有助于 OpenGL 在技术上继续保持领先。至于 DirectX 体系，微软一直没有放弃进入高端的想法，但它注重的还是 PC 娱乐平台，在下一代 DirectX 版本中，我们可以看到更多更先进的功能特性，相信这也将继续成为图形业发展的指导方向 —— 当然这只是针对 PC 而言。
作为两大图形 API 阵营， OpenGL 和 DirectX 在各自的发展中形成鲜明的特点：即便处于目前的低潮状态， OpenGL 仍然牢牢把持着专业绘图领域，而 DirectX 在此毫无竞争力，功能更强大的 OpenGL 2.0 无疑将继续保持垄断性地位。但在 3D 游戏领域， OpenGL 的确是处于弱势地位，但它也没有丢光所有的市场，若 OpenGL 2.0 表现理想，重新赢得广泛支持也并不困难。而 DirectX 9 已经牢牢在游戏中站稳了脚跟，凭借领先的功能特性和微软在操作系统方面的先天优势， DirectX 9 及未来的 DirectX 10 理所当然会成为多数游戏开发商的首选，它的应用范围除了 3D 游戏还涵盖 2D 游戏领域，这正是 OpenGL 所欠缺的。
其实， OpenGL 和 DirectX 并不是完全对立的，二者存在一定的竞争又需要进行相互协作， ARB 公布 OpenGL 2.0 的改进和开发计划后，微软表现出异乎寻常的兴趣，而 ARB 的各个成员也在 3Dlabs 的带领下抛开分歧进行紧密的合作；各成员表示未来将专注于实现 OpenGL 2.0 的开发目标，而不再会为了自身利益让 OpenGL 变得一团糟，就连一向针锋相对的 nVIDIA 与 ATI 也致力于彼此技术的整合。 ARB 集体宣誓： “ 所有送至 OpenGL 的创意想法，一经采用，便免费公开给所有人使用。 ” 相信这种开放性的做法有助于 OpenGL 在技术上继续保持领先。至于 DirectX 体系，微软一直没有放弃进入高端的想法，但它注重的还是 PC 娱乐平台，在下一代 DirectX 版本中，我们可以看到更多更先进的功能特性，相信这也将继续成为图形业发展的指导方向 —— 当然这只是针对 PC 而言。
API
规格与显卡的性能
支持何种 API 是显卡分代的标志，这在 DirectX 规格上体现得极为明显。许多用户往往认为支持 DirectX 高版本的显卡可以提供更理想的性能，其实这是一个误区。我们知道， API 只是函数的集合，它自身不决定任何东西，只是充当游戏和显卡硬件之间的媒介、让游戏和显卡都不需要为兼容性问题而烦恼。而不同版本 API 的区别在于函数库的差异，高版本的 API 总是提供数量更多、功能更强的函数，游戏开发商利用这些函数可以创造出各种各样的特效。如果图形芯片可对此 API 提供支持，那也就意味着基于该图形芯片的显卡可以将这些游戏特效完美展现出来，无法支持该 API 的图形芯片将无法识别游戏特效调用的函数库，自然就无法正常运行。
但 API 自身与图形芯片的硬件性能没有任何关系，图形芯片的性能取决于其核心设计和运行频率， API 只是提供功能方面的支持而已，所以认为具备高版本 API 支持的显卡一定比采纳低版本 API 的显卡速度快是没有道理的，举个例子，支持 DirectX 8 的 GeForce4 Ti4600 肯定比支持 DirectX 9 API 的 GeForce FX5200 速度更快，当然，我们可以说高版本 API 支持总是比较 “ 好 ” 的，因为它可以支持更多的新游戏。
3dfx Glide 的崛起与衰落
3dfx 是计算机 3D 时代的开创者， 1995 年 11 月， 3dfx 推出 Voodoo 加速卡。 凭借令人惊叹的 3D 效果， Voodoo 得以风靡市场、最终成为不朽的神话。 3dfx 迅速发展壮大并在 1997 年达到最巅峰。为了配合自己的硬件技术， 3dfx 推出专门针对 Voodoo 系列的 API ： Glide 。 Glide 提供了完整的三维图形开发环境，开发者可以使用其最高层的 API 创建和操作各种复杂的三维对象。 Glide 支持立即模式和驻留模式，前者与 OpenGL 类似、需要向图形芯片提供画图命令，优点是可提供精细的控制；后者则采纳面向对象的编程结构，场景几何数据被存储到一个对象数据库中，程序员无需掌握三维对象内部结构的知识就可以通过对象调用来进行各种各样复杂的操作、具有优良的易用性。此外， Glide 支持 Voodoo 提供的一系列先进硬件特性，例如镜面高光、阿尔法透明处理、动画贴图、反锯齿等等。由于功能强大、稳定性和易用性都相当出众， Glide 被认为是当时最理想的 3D 图形 API ，加上 3dfx 在图形行业的霸主地位，各游戏开发商顺利成章地选择 Glide 来开发产品，所以在当时，几乎所有的 3D 游戏都是以 Glide 作为基准，而它也确实不负众望。
不过， Glide 有一个致命的缺陷：它是 3dfx 专属性的图形接口，其他图形芯片制造商无法对其提供支持，导致 nVIDIA 、 Matrox 、 S3 等竞争对手选择了微软的 DirectX API 。虽然一开始 DirectX 功能简单、设计糟糕，但在 3.0 版之后， DirectX 逐渐变得成熟，越来越多游戏开始对其提供支持。由于人所共知的原因， 3dfx 在 1997 年之后迅速没落，专用的 Glide API 已经对游戏开发商毫无吸引力，这个时候， Glide 逐渐被抛弃、慢慢消失在人们的视野中。 1999 年 12 月，困境中的 3dfx 终于决定将 Glide 完全公开，但这个时候已经没有多少人对它感兴趣了，强大的 OpenGL 和成熟中的 DirectX 成为游戏开发商的新宠。
支持何种 API 是显卡分代的标志，这在 DirectX 规格上体现得极为明显。许多用户往往认为支持 DirectX 高版本的显卡可以提供更理想的性能，其实这是一个误区。我们知道， API 只是函数的集合，它自身不决定任何东西，只是充当游戏和显卡硬件之间的媒介、让游戏和显卡都不需要为兼容性问题而烦恼。而不同版本 API 的区别在于函数库的差异，高版本的 API 总是提供数量更多、功能更强的函数，游戏开发商利用这些函数可以创造出各种各样的特效。如果图形芯片可对此 API 提供支持，那也就意味着基于该图形芯片的显卡可以将这些游戏特效完美展现出来，无法支持该 API 的图形芯片将无法识别游戏特效调用的函数库，自然就无法正常运行。
但 API 自身与图形芯片的硬件性能没有任何关系，图形芯片的性能取决于其核心设计和运行频率， API 只是提供功能方面的支持而已，所以认为具备高版本 API 支持的显卡一定比采纳低版本 API 的显卡速度快是没有道理的，举个例子，支持 DirectX 8 的 GeForce4 Ti4600 肯定比支持 DirectX 9 API 的 GeForce FX5200 速度更快，当然，我们可以说高版本 API 支持总是比较 “ 好 ” 的，因为它可以支持更多的新游戏。
3dfx Glide 的崛起与衰落
3dfx 是计算机 3D 时代的开创者， 1995 年 11 月， 3dfx 推出 Voodoo 加速卡。 凭借令人惊叹的 3D 效果， Voodoo 得以风靡市场、最终成为不朽的神话。 3dfx 迅速发展壮大并在 1997 年达到最巅峰。为了配合自己的硬件技术， 3dfx 推出专门针对 Voodoo 系列的 API ： Glide 。 Glide 提供了完整的三维图形开发环境，开发者可以使用其最高层的 API 创建和操作各种复杂的三维对象。 Glide 支持立即模式和驻留模式，前者与 OpenGL 类似、需要向图形芯片提供画图命令，优点是可提供精细的控制；后者则采纳面向对象的编程结构，场景几何数据被存储到一个对象数据库中，程序员无需掌握三维对象内部结构的知识就可以通过对象调用来进行各种各样复杂的操作、具有优良的易用性。此外， Glide 支持 Voodoo 提供的一系列先进硬件特性，例如镜面高光、阿尔法透明处理、动画贴图、反锯齿等等。由于功能强大、稳定性和易用性都相当出众， Glide 被认为是当时最理想的 3D 图形 API ，加上 3dfx 在图形行业的霸主地位，各游戏开发商顺利成章地选择 Glide 来开发产品，所以在当时，几乎所有的 3D 游戏都是以 Glide 作为基准，而它也确实不负众望。
不过， Glide 有一个致命的缺陷：它是 3dfx 专属性的图形接口，其他图形芯片制造商无法对其提供支持，导致 nVIDIA 、 Matrox 、 S3 等竞争对手选择了微软的 DirectX API 。虽然一开始 DirectX 功能简单、设计糟糕，但在 3.0 版之后， DirectX 逐渐变得成熟，越来越多游戏开始对其提供支持。由于人所共知的原因， 3dfx 在 1997 年之后迅速没落，专用的 Glide API 已经对游戏开发商毫无吸引力，这个时候， Glide 逐渐被抛弃、慢慢消失在人们的视野中。 1999 年 12 月，困境中的 3dfx 终于决定将 Glide 完全公开，但这个时候已经没有多少人对它感兴趣了，强大的 OpenGL 和成熟中的 DirectX 成为游戏开发商的新宠。
black
2004-10-23
, 18:50
今天原来是厚道的
ZT day
http://bbs.chinagamedev.net/showthread.php?t=8239
DirectX 简史
两点声明
首先 , 这不是一篇 DX 教程，仅提供一些饭后的谈资，所以别指望从这学到些什么编程技术。
其次，这是一篇野史，本人与 Microsoft 以及 DirectX 开发者也毫无干系。
简介
DirectX （简称 DX ）是 Microsoft 在 Windows 平台上提供的一组开发多媒体程序的 API 。 其中包括了 2D/3D 图像，声音，输入设备，网络设备等几个部分。本文主要讨论的其图像方面内容的演化。
DX 的 2D 部分称为 DirectDraw ，简称 DDraw 。 DDraw 所提供的主要功能是画平面图形 , 这个功能适合于制作 2D 游戏。 DX 的 3D 部分称为 Direct3D, 简称 D3D, 主要用于 3D 游戏的开发。早期的 D3D 是很依赖于 DDraw 的， D3D 负责将 3D 的模型通过坐标变换投影到 2D 的平面，然后内部调用 DDraw 的功能把他画出来。但后来 3D 游戏成为了主流，几乎所有的显卡都提供了一定的 3D 加速功能。所以 D3D 得到了更多的重视，也逐渐和 DDraw 划清了界限。而 DDraw 则逐渐衰败，到了 DX8 以后， DDraw 甚至被取消了。这也是很合理的，你既然能画 3D 东西，自然能画 2D 的东西。加之 DDraw 的复杂性根本不能与现在的 D3D 相提并论，所以被取消是必然的。
DX 从出现至今已将近十年，经过了 9 个版本的改进，现在已成为 PC 上游戏开发的最重要的工业标准。但这并不是与生俱来的，而是经历了无数的挫折，改进。让我们来回顾一下这段历史吧。
DX1.0
我第一次听说有 DirectX 这个名词的时候 DX 已经发展到了 3.0 。那时 DX1.0 早已是传说中的东西了，时至今日，传说更是变成了神话。即使在互联网上也极难找到关于 1.0 的资料。我唯一找得到的传闻是， 1.0 开发于 1994 年底到 1995 年 9 月。主要开发人员为： Craig Eisler , Alex St.John, Eric Engstrom. 运行在 Windows95 之上。
让我们回想一下当时的情况： Window95 还在开发和最后测试中。绝大多数 PC 运行的操作系统是 DOS6.22 和 Windows3.1 。 CPU 基本上是 386/486 ，显卡多是 EISA/VESA 。显卡厂商出于战国时代，品牌奇多，而且互不兼容。当时重要的品牌有 Trident8900/9000, Cirrus Logic 54xx 系列。
当时游戏分两种， DOS 的和 Windows （ WIN31 ）的。
DOS 游戏占了绝大部分。当时显卡芯片制造商在软件支持方面没有一个强而且统一的标准。唯一统一的标准是 BIOS INT10 ，那个标准只支持 640x480x16 或 320*240*256 以下的显示模式。而当时的显卡芯片则在不同程度上提供超越这个标准的能力。另一个标准是 VESA 的标准，这个标准的问题是它只规定像素级别的操作，对块操作则没有什么支持。画东西得一点一点的画，每画一个点都是一个中断调用，所以很慢。快的方法直接访问位于物理地址 0xA0000 的显存。而访问显存则是没有什么标准的。
这种局面对软件开发商，硬件开发商，以及用户都造成了不利的影响。软件开发商得根据不同的显卡来编写不同的代码，硬件开发商则要为那些大牌应用程序（比如 wordperfect/autocad ）开发驱动程序，这些驱动程序的要求又各不相同。最终用户则不知所措，没有什么可以保证你的显卡和应用程序能够一起工作。
在声卡方面也是类似的情况，好在 Createive SoundBlaster 处于声卡市场的统治地位，所以所有的软件商至少保证它的程序对于 SoundBlatser 是能工作的。 而小硬件商者尽量把自己的产品做成 SB 兼容（记得当时的 DOS 游戏大多会带一个 setup.exe 。让用户来选择显卡芯片和声卡芯片）。
再来看一看 Windows 下怎么样。象扫雷，纸牌这类游戏对于图形系统无论是功能上还是速度上要求都不高， GDI 就可以搞定。而复杂一些的游戏则需要额外的支持。提供这个支持的库叫做 WinG 。 WinG 和 DDraw 有着相同的使命，即提供一个与硬件无关的高性能的图形编程界面。但 WinG 显然没有完成这个使命，它提供的性能还是不够高（相对于 DOS 下直接写屏）。它也没能成为 DDraw 的前身，因为它是一个完全基于 Win16 的构架。
这就是 DirectX 出现的背景。
DirectX 到底意味着什么？我觉得它实际上包含了三个部分，首先是 Microsoft 与硬件商的协议，硬件商的职责除了制造芯片板卡以外还要提供一个驱动程序，这类驱动程序提供了一个一致的接口来调用或查询硬件所提供的功能。这个接口称为 DDK 。软件开发商对 DDK 应该是一无所知的（至少理想情况下是这样）。第二部分是 Microsoft 与软件开发商的协议。 Microsoft 向软件商承诺：只要你遵守这套协议，我保证无论 Windows 是运行在何种显卡上，你的程序都能正常运行。这个协议叫做 SDK 。第三部分这是 DirectX 本身，这部分东西负责把 DDK 得到的功能加上增值服务转化成 SDK 所需要提供的东西。这样软件和硬件间的耦合就在相当大的程度上分离开来了。硬件商从此只需要为 Windows 写一个驱动程序，而不用为各个应用程序写一个驱动程序。软件开发者也不必过于关心程序到底运行在什么芯片板卡上。用户购买设备的时候也只需要认清 Windows compatible 这两个字。每个人都是获益者。
[ 闲话：关于标准 ]
“ 每个人都是获益者 ” 这种好事可不是每天都会发生的。如果真是这样，为什么不早发生呢？
标准不是谁都可以制定的，定标准的人得有一定的实力，别人才会拥护你制定的标准。而在 PC 世界里，直到那时， Microsoft 绝对的统治地位开始显露（虽然 IBM 还在夜郎自大的叫嚣 OS2Warp 是如何的稳定，如何的高性能）。所以 Microsoft 有实力来制定这样的标准，为了支持新一代的 Windows, Microsoft 也有需要来制定这样一个标准。
Microsoft 得到的好处是什么？使在 Windows 平台上开发更为方便，自然有更多开发者被吸引过来，开发者越多应用也就越丰富，自然用户也就越多。这自不在话下。另一个更大到好处是，从此再无操作系统能在 PC 上与 Windows 抗衡。因为如果有一个新的操作系统要想和 Windows 争一下短长，它至少要支持 Windows 所支持的设备。而这些设备的标准捏在 Microsoft 的手里，如果你用这个标准，你就总是跟在 Microsoft 背后面转。 Microsoft 想改一点什么你也得跟着改。如果你不用这个标准，有多少硬件商会花力气来为你这个市场份额很小的操作系统开发驱动程序？即使你愿意为每个硬件来写驱动，只怕你也没有能力在第一时间来提供对最新硬件的支持。 Linux 基本上就是中了这个套。
DX2.0
DX2.0 发布于 1996 年春。这套 SDK 包括了六个部分。 DirectDraw, DirectSound, DirectPlay, Direct3D, DirectInput, AutoPlay 。这基本划定了 DX 所要处理的问题的范围，这些基本的模块的划分虽然只以后版本中有所增减，但大致上保持了如此风貌至今。 DX2 采用了 COM 构架。这一决定也从未曾改变。
当时主要的游戏游戏几乎全是 2D 的。若干幅卷轴作为背景，加上一些 Sprite 在上面移动，作为角色。 DDraw 基本上是为这类游戏设计的。
DDraw 提供了 4 个 Interface,IDirectDraw, IDirectDrawSurface, IDirectDrawClipper, IDirectDrawPalette 。 DDraw 的基本工作过程是这样的，你首先要创建一个 IDirectDraw 的 interface ，一般这由 DirectDrawCreate 来完成，但你也可以用 CoCreateInstance 。然后你通过 IDirectDraw::CreateSurface 来创建一些 OffScreenSurface, 用以保存背景或 Sprite 。然后就是把背景和 Sprite 用 IDirectDrawSurface::BltFast 画在不同的位置上。最后调用 Flip 方法将 BackBuffer 瞬间置成 FrontBuffer 。 DDraw 只能用来画长方形。而象角色这类非规则图形，则通过 SetColorKey 将周边无用的像素设成透明。
从 2.0 开始， D3D 就提供了两种模式， retained-mode 和 immediate-mode 。 Immediate-mode 提供 primitive 层面上的功能，相对来说比较底层。 Retained-Mode 则提供 model 层面上的功能 , 以及其他一些 “ 高级 ” 特性，如动画支持。当时 Microsoft 宣称除了从其他 API 上移植旧代码，大家都应该使用 retained-mode 。
但那些所谓的高级功能并不是软件开发者所需要的，相反，由于 retained-mode 层次太高，如果你正好做它支持的事情，用起来很方便，但如果你要做一些它不直接支持的事情，则非常的牵手绊脚（这是所有高层 API 所共有的特点）。
并不如 Microsoft 所希望的那样， retained-mode 从头到尾就没有受到过开发者的欢迎，所以从 DX6 开始， retained-mode 逐渐淡出， DX8 彻底取消了 retained-mode 。相反，并不是主打的 Immediate-mode 倒是每个版本都有所改进，并且越来越兴旺。
让我们看一看 2.0 里的 immediate-mode 都有些什么。 IDirect3D, IDirect3DDevice, IDirec3DExecuteBuffer, IDirect3DLight, IDirect3DMaterial, IDirect3DTexture, IDirect3DViewport, 一共是 7 个 interface 。 IDirect3D 负责创建除 IDirect3DExecuteBuffer 以外的各类 interface 。 IDirect3DDevice 用来设置矩阵，设置当前 Texture, 建立并执行 ExecuteBuffer ， IDirect3DExecuteBuffer 则用数据的形式描述了 DrawPrimitive 的操作。在这个早期版本里几乎没有没有 RenderState / TextureStageState 这类概念。是一个非常简单的 API 。
虽然当时已经是 1996 年了，但游戏几乎清一色的是 2D 游戏，所以，即使 DX 提供了 D3D, 但并没有什么人真正使用它。唯一两个伪 3D 的游戏 Doom2 / Duke3D 又运行在 DOS 下。
伴着 Win95 的普及 EISA/VESA 显卡已逐渐被 PCI 显卡所取代，代表显卡有 S3765/S3868 。
[ 闲话：关于 COM]
在我看来 COM 并不是一件必需品。它更像是一种编程规范或指导原则，而且应该是 Microsoft 公司内部的规范和原则，但 Microsoft 却把它拿出来，强加给所有的开发者，这实在是一件不太可思议的事情，但 Microsoft 确实这么做了。 GUID, QueryInterface 这些张牙舞爪的东西着实吓退了一帮初学者，但 COM 所提供的好处 DX 却没享用到什么，比如说分布式对象系统，我从来没有看到过有人试图把 DX 作为一个 Server, 放在一个单独的进程里，或是放在不同的机器上。好在 DX 也没有非常频繁地使用 COM 相关的特性。看久了也就习惯了。
3.0
紧跟着 2.0 ， Microsoft 于 1996 年夏季推出了 3.0 。从 SDK 的方面来看几乎没有什么变化， DDraw 和 D3D 纹丝不动。 DSound 和 DPlay 增强了一点。为什么要推出这个与 2.0 如此相似的版本呢？原因是 NT4.0 希望整合 DirectX 。所以 Microsoft 开发了两个 Runtime ，一个工作在 Win95 上，另一个工作在 NT 上，这两个 Runtime 共享相同的 API 。
4.0
4.0 没有正式发布过， Microsoft 也没有官方记载。我只能从一个名叫 Reymond Chen 的人的 WebBlog 上找到一些线索，转译如下：
DirectX 4 怎么了 ? 如果你看一眼 DirectX 的历史 , 你会发现没有 DirectX 4 。直接从 DirectX 3 跳到 DirectX 5 。为什么会这样 ? 在 DirectX 3 发布了之后 , 有二个后继者产品同时被开发 : 希望在短期内发行的称作 DirectX4 ，希望有较大改变并有更多时间开发的叫 DirectX5 。但从游戏开发者那里得到的反馈是 , 他们并不在意 DirectX 4 的那些小改动 ; 相比之下令他们更感兴趣是 DirectX 5 所能提供的功能 。因此决定取消 DirectX 4 ，并把所有的功能都加入 DirectX 5 。 那么为什么不把 DirectX 5 改名为 DirectX 4 呢 ? 那是因为在当时所有的文档中已有成百上千个地方分别称呼这二个项目为 DirectX 4 和 DirectX 5 。在项目开发到一半的时候更换名字只会造成更大的混乱 …..
http://weblogs.asp.net/oldnewthing/...1/22/61647.aspx
所以 4.0 就这样消失了。
http://bbs.chinagamedev.net/showthread.php?t=8239
DirectX 简史
两点声明
首先 , 这不是一篇 DX 教程，仅提供一些饭后的谈资，所以别指望从这学到些什么编程技术。
其次，这是一篇野史，本人与 Microsoft 以及 DirectX 开发者也毫无干系。
简介
DirectX （简称 DX ）是 Microsoft 在 Windows 平台上提供的一组开发多媒体程序的 API 。 其中包括了 2D/3D 图像，声音，输入设备，网络设备等几个部分。本文主要讨论的其图像方面内容的演化。
DX 的 2D 部分称为 DirectDraw ，简称 DDraw 。 DDraw 所提供的主要功能是画平面图形 , 这个功能适合于制作 2D 游戏。 DX 的 3D 部分称为 Direct3D, 简称 D3D, 主要用于 3D 游戏的开发。早期的 D3D 是很依赖于 DDraw 的， D3D 负责将 3D 的模型通过坐标变换投影到 2D 的平面，然后内部调用 DDraw 的功能把他画出来。但后来 3D 游戏成为了主流，几乎所有的显卡都提供了一定的 3D 加速功能。所以 D3D 得到了更多的重视，也逐渐和 DDraw 划清了界限。而 DDraw 则逐渐衰败，到了 DX8 以后， DDraw 甚至被取消了。这也是很合理的，你既然能画 3D 东西，自然能画 2D 的东西。加之 DDraw 的复杂性根本不能与现在的 D3D 相提并论，所以被取消是必然的。
DX 从出现至今已将近十年，经过了 9 个版本的改进，现在已成为 PC 上游戏开发的最重要的工业标准。但这并不是与生俱来的，而是经历了无数的挫折，改进。让我们来回顾一下这段历史吧。
DX1.0
我第一次听说有 DirectX 这个名词的时候 DX 已经发展到了 3.0 。那时 DX1.0 早已是传说中的东西了，时至今日，传说更是变成了神话。即使在互联网上也极难找到关于 1.0 的资料。我唯一找得到的传闻是， 1.0 开发于 1994 年底到 1995 年 9 月。主要开发人员为： Craig Eisler , Alex St.John, Eric Engstrom. 运行在 Windows95 之上。
让我们回想一下当时的情况： Window95 还在开发和最后测试中。绝大多数 PC 运行的操作系统是 DOS6.22 和 Windows3.1 。 CPU 基本上是 386/486 ，显卡多是 EISA/VESA 。显卡厂商出于战国时代，品牌奇多，而且互不兼容。当时重要的品牌有 Trident8900/9000, Cirrus Logic 54xx 系列。
当时游戏分两种， DOS 的和 Windows （ WIN31 ）的。
DOS 游戏占了绝大部分。当时显卡芯片制造商在软件支持方面没有一个强而且统一的标准。唯一统一的标准是 BIOS INT10 ，那个标准只支持 640x480x16 或 320*240*256 以下的显示模式。而当时的显卡芯片则在不同程度上提供超越这个标准的能力。另一个标准是 VESA 的标准，这个标准的问题是它只规定像素级别的操作，对块操作则没有什么支持。画东西得一点一点的画，每画一个点都是一个中断调用，所以很慢。快的方法直接访问位于物理地址 0xA0000 的显存。而访问显存则是没有什么标准的。
这种局面对软件开发商，硬件开发商，以及用户都造成了不利的影响。软件开发商得根据不同的显卡来编写不同的代码，硬件开发商则要为那些大牌应用程序（比如 wordperfect/autocad ）开发驱动程序，这些驱动程序的要求又各不相同。最终用户则不知所措，没有什么可以保证你的显卡和应用程序能够一起工作。
在声卡方面也是类似的情况，好在 Createive SoundBlaster 处于声卡市场的统治地位，所以所有的软件商至少保证它的程序对于 SoundBlatser 是能工作的。 而小硬件商者尽量把自己的产品做成 SB 兼容（记得当时的 DOS 游戏大多会带一个 setup.exe 。让用户来选择显卡芯片和声卡芯片）。
再来看一看 Windows 下怎么样。象扫雷，纸牌这类游戏对于图形系统无论是功能上还是速度上要求都不高， GDI 就可以搞定。而复杂一些的游戏则需要额外的支持。提供这个支持的库叫做 WinG 。 WinG 和 DDraw 有着相同的使命，即提供一个与硬件无关的高性能的图形编程界面。但 WinG 显然没有完成这个使命，它提供的性能还是不够高（相对于 DOS 下直接写屏）。它也没能成为 DDraw 的前身，因为它是一个完全基于 Win16 的构架。
这就是 DirectX 出现的背景。
DirectX 到底意味着什么？我觉得它实际上包含了三个部分，首先是 Microsoft 与硬件商的协议，硬件商的职责除了制造芯片板卡以外还要提供一个驱动程序，这类驱动程序提供了一个一致的接口来调用或查询硬件所提供的功能。这个接口称为 DDK 。软件开发商对 DDK 应该是一无所知的（至少理想情况下是这样）。第二部分是 Microsoft 与软件开发商的协议。 Microsoft 向软件商承诺：只要你遵守这套协议，我保证无论 Windows 是运行在何种显卡上，你的程序都能正常运行。这个协议叫做 SDK 。第三部分这是 DirectX 本身，这部分东西负责把 DDK 得到的功能加上增值服务转化成 SDK 所需要提供的东西。这样软件和硬件间的耦合就在相当大的程度上分离开来了。硬件商从此只需要为 Windows 写一个驱动程序，而不用为各个应用程序写一个驱动程序。软件开发者也不必过于关心程序到底运行在什么芯片板卡上。用户购买设备的时候也只需要认清 Windows compatible 这两个字。每个人都是获益者。
[ 闲话：关于标准 ]
“ 每个人都是获益者 ” 这种好事可不是每天都会发生的。如果真是这样，为什么不早发生呢？
标准不是谁都可以制定的，定标准的人得有一定的实力，别人才会拥护你制定的标准。而在 PC 世界里，直到那时， Microsoft 绝对的统治地位开始显露（虽然 IBM 还在夜郎自大的叫嚣 OS2Warp 是如何的稳定，如何的高性能）。所以 Microsoft 有实力来制定这样的标准，为了支持新一代的 Windows, Microsoft 也有需要来制定这样一个标准。
Microsoft 得到的好处是什么？使在 Windows 平台上开发更为方便，自然有更多开发者被吸引过来，开发者越多应用也就越丰富，自然用户也就越多。这自不在话下。另一个更大到好处是，从此再无操作系统能在 PC 上与 Windows 抗衡。因为如果有一个新的操作系统要想和 Windows 争一下短长，它至少要支持 Windows 所支持的设备。而这些设备的标准捏在 Microsoft 的手里，如果你用这个标准，你就总是跟在 Microsoft 背后面转。 Microsoft 想改一点什么你也得跟着改。如果你不用这个标准，有多少硬件商会花力气来为你这个市场份额很小的操作系统开发驱动程序？即使你愿意为每个硬件来写驱动，只怕你也没有能力在第一时间来提供对最新硬件的支持。 Linux 基本上就是中了这个套。
DX2.0
DX2.0 发布于 1996 年春。这套 SDK 包括了六个部分。 DirectDraw, DirectSound, DirectPlay, Direct3D, DirectInput, AutoPlay 。这基本划定了 DX 所要处理的问题的范围，这些基本的模块的划分虽然只以后版本中有所增减，但大致上保持了如此风貌至今。 DX2 采用了 COM 构架。这一决定也从未曾改变。
当时主要的游戏游戏几乎全是 2D 的。若干幅卷轴作为背景，加上一些 Sprite 在上面移动，作为角色。 DDraw 基本上是为这类游戏设计的。
DDraw 提供了 4 个 Interface,IDirectDraw, IDirectDrawSurface, IDirectDrawClipper, IDirectDrawPalette 。 DDraw 的基本工作过程是这样的，你首先要创建一个 IDirectDraw 的 interface ，一般这由 DirectDrawCreate 来完成，但你也可以用 CoCreateInstance 。然后你通过 IDirectDraw::CreateSurface 来创建一些 OffScreenSurface, 用以保存背景或 Sprite 。然后就是把背景和 Sprite 用 IDirectDrawSurface::BltFast 画在不同的位置上。最后调用 Flip 方法将 BackBuffer 瞬间置成 FrontBuffer 。 DDraw 只能用来画长方形。而象角色这类非规则图形，则通过 SetColorKey 将周边无用的像素设成透明。
从 2.0 开始， D3D 就提供了两种模式， retained-mode 和 immediate-mode 。 Immediate-mode 提供 primitive 层面上的功能，相对来说比较底层。 Retained-Mode 则提供 model 层面上的功能 , 以及其他一些 “ 高级 ” 特性，如动画支持。当时 Microsoft 宣称除了从其他 API 上移植旧代码，大家都应该使用 retained-mode 。
但那些所谓的高级功能并不是软件开发者所需要的，相反，由于 retained-mode 层次太高，如果你正好做它支持的事情，用起来很方便，但如果你要做一些它不直接支持的事情，则非常的牵手绊脚（这是所有高层 API 所共有的特点）。
并不如 Microsoft 所希望的那样， retained-mode 从头到尾就没有受到过开发者的欢迎，所以从 DX6 开始， retained-mode 逐渐淡出， DX8 彻底取消了 retained-mode 。相反，并不是主打的 Immediate-mode 倒是每个版本都有所改进，并且越来越兴旺。
让我们看一看 2.0 里的 immediate-mode 都有些什么。 IDirect3D, IDirect3DDevice, IDirec3DExecuteBuffer, IDirect3DLight, IDirect3DMaterial, IDirect3DTexture, IDirect3DViewport, 一共是 7 个 interface 。 IDirect3D 负责创建除 IDirect3DExecuteBuffer 以外的各类 interface 。 IDirect3DDevice 用来设置矩阵，设置当前 Texture, 建立并执行 ExecuteBuffer ， IDirect3DExecuteBuffer 则用数据的形式描述了 DrawPrimitive 的操作。在这个早期版本里几乎没有没有 RenderState / TextureStageState 这类概念。是一个非常简单的 API 。
虽然当时已经是 1996 年了，但游戏几乎清一色的是 2D 游戏，所以，即使 DX 提供了 D3D, 但并没有什么人真正使用它。唯一两个伪 3D 的游戏 Doom2 / Duke3D 又运行在 DOS 下。
伴着 Win95 的普及 EISA/VESA 显卡已逐渐被 PCI 显卡所取代，代表显卡有 S3765/S3868 。
[ 闲话：关于 COM]
在我看来 COM 并不是一件必需品。它更像是一种编程规范或指导原则，而且应该是 Microsoft 公司内部的规范和原则，但 Microsoft 却把它拿出来，强加给所有的开发者，这实在是一件不太可思议的事情，但 Microsoft 确实这么做了。 GUID, QueryInterface 这些张牙舞爪的东西着实吓退了一帮初学者，但 COM 所提供的好处 DX 却没享用到什么，比如说分布式对象系统，我从来没有看到过有人试图把 DX 作为一个 Server, 放在一个单独的进程里，或是放在不同的机器上。好在 DX 也没有非常频繁地使用 COM 相关的特性。看久了也就习惯了。
3.0
紧跟着 2.0 ， Microsoft 于 1996 年夏季推出了 3.0 。从 SDK 的方面来看几乎没有什么变化， DDraw 和 D3D 纹丝不动。 DSound 和 DPlay 增强了一点。为什么要推出这个与 2.0 如此相似的版本呢？原因是 NT4.0 希望整合 DirectX 。所以 Microsoft 开发了两个 Runtime ，一个工作在 Win95 上，另一个工作在 NT 上，这两个 Runtime 共享相同的 API 。
4.0
4.0 没有正式发布过， Microsoft 也没有官方记载。我只能从一个名叫 Reymond Chen 的人的 WebBlog 上找到一些线索，转译如下：
DirectX 4 怎么了 ? 如果你看一眼 DirectX 的历史 , 你会发现没有 DirectX 4 。直接从 DirectX 3 跳到 DirectX 5 。为什么会这样 ? 在 DirectX 3 发布了之后 , 有二个后继者产品同时被开发 : 希望在短期内发行的称作 DirectX4 ，希望有较大改变并有更多时间开发的叫 DirectX5 。但从游戏开发者那里得到的反馈是 , 他们并不在意 DirectX 4 的那些小改动 ; 相比之下令他们更感兴趣是 DirectX 5 所能提供的功能 。因此决定取消 DirectX 4 ，并把所有的功能都加入 DirectX 5 。 那么为什么不把 DirectX 5 改名为 DirectX 4 呢 ? 那是因为在当时所有的文档中已有成百上千个地方分别称呼这二个项目为 DirectX 4 和 DirectX 5 。在项目开发到一半的时候更换名字只会造成更大的混乱 …..
http://weblogs.asp.net/oldnewthing/...1/22/61647.aspx
所以 4.0 就这样消失了。
black
2004-10-23
, 18:52
5.0
1997 年夏季 DirectX5 发布了，这个版本比之前三个版本有着较大的变化。 DDraw 的主要改动如下：增加了 Viewport 的概念；利用 MMX 技术提高硬件模拟层的性能；支持创建比 BackBuffer 更大的 OffScreenSurface ；支持 AGP 显卡，可以把 OffScreenSurface 建立在系统内存上，从而摆脱显存大小的限制。 DDraw 发展到这个阶段，已完全站稳了脚跟， 2D 游戏基本上都已到了 Windows 平台上。只有少数一些喜欢怀旧的人还在玩 DOS 下的游戏。
在 D3D 方面，虽然在文档中， Microsoft 仍然推荐 Retained-Mode ，但他们显然认识到了 Immediate-Mode 更受欢迎，所以在 Immediate-Mode 上作了很大的修改，并且完善了文档。
在这个版本中，你可以看到两个 D3DDevice interface ，一个是 IDirect3DDevice ，这个 interface 基本上兼容于 2.0/3.0 里的 device ，通过 ExecuterBuffer 来画东西。另一个是 IDirect3DDevice2 ，它提供了 DrawPrimitive / DrawIndexedPrimitive / SetRenderState 等方法，你无需使用 ExecuterBuffer 这个类似于 opengl 里 DisplayList 的概念。 这个 Device 和我们现在所看到的 DX8/DX9 里的 Device 已经有点像了。但注意，由于当时没有 VertexBuffer / IndexBuffer 的概念，所以， DrawPrimitve / DrawIndexedPrimitive 实际相当于现在的 DrawPrimitiveUp / DrawIndexedPrimitiveUp 。而且 Vertex 种类也只有三种， Vertex / Lit Vertex / Lit & Transformed Vertex 。
当时 3D 游戏却并不繁荣，但有几个重要的 3D 游戏出现在那个时期前后 : 古墓丽影 1 和 Quake 1 。这两个游戏都运行在在 DOS 下，靠的是软件渲染。另一个是 Need For Speed 2, NFS 运行在 Win95 之上，需要 DX3 支持。有趣的是这三个游戏都额外支持一个称为 Glide 的 API 。
提起 Glide ，你可能觉得陌生，但如果说到 3dfx / voodoo 马上就觉得如雷灌耳了吧。 Glide 就是 voodoo 卡的 API 。当时绝大部分显卡制造商还只是把目光集中在 Mpeg 解码上。 3dfx 却已经开发出了真正具有 3D 加速的硬件 voodoo1 芯片。 Voodoo1 具有 z-buffer, alpha blending, bi-linear filting 等重要的功能，并且均以硬件方式实现，这给 3D 游戏的画面质量的速度以质的改变。在软件支持方面， 3dfx 并不追随 D3D 或是 OpenGL ，而是自己开发了一套和 voodoo 硬件紧密结合的 API --Glide 。由于有了硬件支持， glide 的游戏远胜于 D3D 的游戏，这个状态持续了很久。
D3D5 没有受到热烈的欢迎，相反遭到了强烈的抨击，抨击来自 IDSoft 的 Carmark ，主要意见集中在易用性上：
(1996 年底 )
我用了六个月的 OpenGL ，这个 API 给我很深刻的印象，尤其是在易用性方面，一个月以前，我把 Quake 移植到了 OpenGL 上，这是一段令人愉快的经历，没用多长时间，代码也很干净。
然后我试图把 QuakeGL 移植到 D3D-IM 上，以便学习这个 API ，并拿它和 OpenGL 作一下比较。好吧，我已经学够了。我不会完成这个移植，我的时间可以用来做更有意义的事情。
…..
D3D-IM 是一个遭透了的 API ，它给使用它的程序员带来无尽的痛苦，却没有丝毫好处。我不认为它适合于做任何事情，而 OpenGL 则什么都干的很好，从 Quake 到 SoftImage 。从技术上讲， D3D 毫无存在的理由。
我相信 D3D 未来的版本会烂的少一些，但开发社团何必和这个先天不足的 API 一同经历混乱的进化过程。
…...
http://www.bluesnews.com/archives/carmack122396.html
(1997 年中 )
我们没有必要盲从 Microsoft 所犯的每一个错误。
http://doom-ed.com/blog/1997/07/03/d3d-vs-opengl
D3D 的负责人 Alex St.John 对此给以了回应
http://rmitz.org/stjohn.html
http://www.winnetmag.com/Article/Ar...7172/17172.html
但 DX5 项目一结束， Alex 就被 Microsoft 解雇了。
6.0
6.0 推出是在 1998 年夏。 DDraw 在 DX5 的时候已经颇为完善，所以 6.0 的 DDraw 主要做的是易用性的改善和性能的提高，以及对多显示器的支持。
相比之下 D3D 的改动则很大。
首先， Retained-Mode 被扔到了一个称为 DirectX Media 的组里，意味着它已经不是核心的部分了。 Intermediate-Mode 终于成为了首发阵容。 D3D6 为它增加了很多新的特性，比如， VertexBuffer, FVF ， MultiTexture ， StencilBuffer 。都在这个版本中引入。 D3D6 仍然保留了 ExecuterBuffer ，但这也是 ExecuterBuffer 最后一次登场。
无可置疑 DX6 在 3D 方面作了巨大的努力，也取得了很大的进步，但这并没有扭转颓势，还是受到了不少的批评。批评主要来自 Glide 阵营。在 3dfx 的新闻组里，你可以清晰地感觉到这样一种认识： D3D 作了太多的事情，比如说 Vertex Transform 和 Lightening 的事情完全应该由游戏的开发者来做，这样才能有细微的控制和最佳的优化。 D3D 硬是要接管了这个过程，但又管不好。
这是因为 Glide 基本上是一个 2D 的 API ， Glide 程序员已经习惯了程序员控制坐标转换和光照， API 只管光栅化的这种工作方式，所以他们自然的感觉 D3D 把手伸得太长。
不久后， Microsoft 推出了 6.1 ，在 DDraw / D3D API 上没有变化。
在 DX6 推出前后， 3D 加速卡开始多元， Voodoo1 / Voodoo2 / Riva 128 /TNT1 / Ati Rage Pro / S3 Savage / G400 ， 1999 年以后推出的 TNT2 和 VOODOO3 代表了当时的最高水平。
[ 闲话：关于 API]
有三个 API 并存，一个的提供者是向来无往不利的 Microsoft ，一个的推崇者是游戏程序员里的大哥大，另一个当时最好 3D 硬件唯一支持的 API( 后来 voodoo 也开始支持 opengl/d3d) 。到底选那一个呢？小公司基本上是随便压一个宝，大公司的态度则是跨 API ，就是试图在三个 API 上建立一个抽象层，尽量把更多的逻辑移到这层以上来。
Microsoft 也放出风声要和 OpenGL 社团紧密合作创建一个工作在 OpenGL 和 D3D 之上的 API 。 但这个 API 从没有真的出现过，可能是因为后来 D3D 逐渐占到了统治地位。
1997 年夏季 DirectX5 发布了，这个版本比之前三个版本有着较大的变化。 DDraw 的主要改动如下：增加了 Viewport 的概念；利用 MMX 技术提高硬件模拟层的性能；支持创建比 BackBuffer 更大的 OffScreenSurface ；支持 AGP 显卡，可以把 OffScreenSurface 建立在系统内存上，从而摆脱显存大小的限制。 DDraw 发展到这个阶段，已完全站稳了脚跟， 2D 游戏基本上都已到了 Windows 平台上。只有少数一些喜欢怀旧的人还在玩 DOS 下的游戏。
在 D3D 方面，虽然在文档中， Microsoft 仍然推荐 Retained-Mode ，但他们显然认识到了 Immediate-Mode 更受欢迎，所以在 Immediate-Mode 上作了很大的修改，并且完善了文档。
在这个版本中，你可以看到两个 D3DDevice interface ，一个是 IDirect3DDevice ，这个 interface 基本上兼容于 2.0/3.0 里的 device ，通过 ExecuterBuffer 来画东西。另一个是 IDirect3DDevice2 ，它提供了 DrawPrimitive / DrawIndexedPrimitive / SetRenderState 等方法，你无需使用 ExecuterBuffer 这个类似于 opengl 里 DisplayList 的概念。 这个 Device 和我们现在所看到的 DX8/DX9 里的 Device 已经有点像了。但注意，由于当时没有 VertexBuffer / IndexBuffer 的概念，所以， DrawPrimitve / DrawIndexedPrimitive 实际相当于现在的 DrawPrimitiveUp / DrawIndexedPrimitiveUp 。而且 Vertex 种类也只有三种， Vertex / Lit Vertex / Lit & Transformed Vertex 。
当时 3D 游戏却并不繁荣，但有几个重要的 3D 游戏出现在那个时期前后 : 古墓丽影 1 和 Quake 1 。这两个游戏都运行在在 DOS 下，靠的是软件渲染。另一个是 Need For Speed 2, NFS 运行在 Win95 之上，需要 DX3 支持。有趣的是这三个游戏都额外支持一个称为 Glide 的 API 。
提起 Glide ，你可能觉得陌生，但如果说到 3dfx / voodoo 马上就觉得如雷灌耳了吧。 Glide 就是 voodoo 卡的 API 。当时绝大部分显卡制造商还只是把目光集中在 Mpeg 解码上。 3dfx 却已经开发出了真正具有 3D 加速的硬件 voodoo1 芯片。 Voodoo1 具有 z-buffer, alpha blending, bi-linear filting 等重要的功能，并且均以硬件方式实现，这给 3D 游戏的画面质量的速度以质的改变。在软件支持方面， 3dfx 并不追随 D3D 或是 OpenGL ，而是自己开发了一套和 voodoo 硬件紧密结合的 API --Glide 。由于有了硬件支持， glide 的游戏远胜于 D3D 的游戏，这个状态持续了很久。
D3D5 没有受到热烈的欢迎，相反遭到了强烈的抨击，抨击来自 IDSoft 的 Carmark ，主要意见集中在易用性上：
(1996 年底 )
我用了六个月的 OpenGL ，这个 API 给我很深刻的印象，尤其是在易用性方面，一个月以前，我把 Quake 移植到了 OpenGL 上，这是一段令人愉快的经历，没用多长时间，代码也很干净。
然后我试图把 QuakeGL 移植到 D3D-IM 上，以便学习这个 API ，并拿它和 OpenGL 作一下比较。好吧，我已经学够了。我不会完成这个移植，我的时间可以用来做更有意义的事情。
…..
D3D-IM 是一个遭透了的 API ，它给使用它的程序员带来无尽的痛苦，却没有丝毫好处。我不认为它适合于做任何事情，而 OpenGL 则什么都干的很好，从 Quake 到 SoftImage 。从技术上讲， D3D 毫无存在的理由。
我相信 D3D 未来的版本会烂的少一些，但开发社团何必和这个先天不足的 API 一同经历混乱的进化过程。
…...
http://www.bluesnews.com/archives/carmack122396.html
(1997 年中 )
我们没有必要盲从 Microsoft 所犯的每一个错误。
http://doom-ed.com/blog/1997/07/03/d3d-vs-opengl
D3D 的负责人 Alex St.John 对此给以了回应
http://rmitz.org/stjohn.html
http://www.winnetmag.com/Article/Ar...7172/17172.html
但 DX5 项目一结束， Alex 就被 Microsoft 解雇了。
6.0
6.0 推出是在 1998 年夏。 DDraw 在 DX5 的时候已经颇为完善，所以 6.0 的 DDraw 主要做的是易用性的改善和性能的提高，以及对多显示器的支持。
相比之下 D3D 的改动则很大。
首先， Retained-Mode 被扔到了一个称为 DirectX Media 的组里，意味着它已经不是核心的部分了。 Intermediate-Mode 终于成为了首发阵容。 D3D6 为它增加了很多新的特性，比如， VertexBuffer, FVF ， MultiTexture ， StencilBuffer 。都在这个版本中引入。 D3D6 仍然保留了 ExecuterBuffer ，但这也是 ExecuterBuffer 最后一次登场。
无可置疑 DX6 在 3D 方面作了巨大的努力，也取得了很大的进步，但这并没有扭转颓势，还是受到了不少的批评。批评主要来自 Glide 阵营。在 3dfx 的新闻组里，你可以清晰地感觉到这样一种认识： D3D 作了太多的事情，比如说 Vertex Transform 和 Lightening 的事情完全应该由游戏的开发者来做，这样才能有细微的控制和最佳的优化。 D3D 硬是要接管了这个过程，但又管不好。
这是因为 Glide 基本上是一个 2D 的 API ， Glide 程序员已经习惯了程序员控制坐标转换和光照， API 只管光栅化的这种工作方式，所以他们自然的感觉 D3D 把手伸得太长。
不久后， Microsoft 推出了 6.1 ，在 DDraw / D3D API 上没有变化。
在 DX6 推出前后， 3D 加速卡开始多元， Voodoo1 / Voodoo2 / Riva 128 /TNT1 / Ati Rage Pro / S3 Savage / G400 ， 1999 年以后推出的 TNT2 和 VOODOO3 代表了当时的最高水平。
[ 闲话：关于 API]
有三个 API 并存，一个的提供者是向来无往不利的 Microsoft ，一个的推崇者是游戏程序员里的大哥大，另一个当时最好 3D 硬件唯一支持的 API( 后来 voodoo 也开始支持 opengl/d3d) 。到底选那一个呢？小公司基本上是随便压一个宝，大公司的态度则是跨 API ，就是试图在三个 API 上建立一个抽象层，尽量把更多的逻辑移到这层以上来。
Microsoft 也放出风声要和 OpenGL 社团紧密合作创建一个工作在 OpenGL 和 D3D 之上的 API 。 但这个 API 从没有真的出现过，可能是因为后来 D3D 逐渐占到了统治地位。
black
2004-10-23
, 18:52
7.0
夏季看来是 DX 更新版本的季节， 1999 年夏， DX7 如期而至。在功能上， D3D 率先支持 Hardware TnL ，以及其他不少高级的渲染技术，如 Matrix Blending 动画， Blinn-Bump mapping. Cubic Environment mapping 。 Hardware TnL 是一个极为重要的功能，就是让显卡来进行 3 维坐标变换和光照计算。 这项繁重的工作以前都是由 CPU 来进行，有了 Hardware TnL 后， CPU 的计算能力就能被节省下来进行 AI 或物理模型的计算。
在 API 布局上， Microsoft 作了大刀阔斧的修改，挪走了几乎所有从 2.0 起就有的 Interface, 诸如， IDirect3DViewport, IDirect3DMaterial, IDirect3DTexture, IDirect3DExecuteBuffer, IDirect3DLight, IDirect3DViewPort 。 只剩下三个 Interface, IDirect3D, IDirect3DDevice, IDirect3DVertexBuffer 。那些被取消的 Interface 变成了简单的数据结构。 IDirect3DTexture 则用 IDirectDrawSurface 来代替。
D3DX 首次出现，这是一个辅助性的 Library 。 其中包含了许多经常要被用到但逻辑上又不属于 D3D 例程。
更出乎意料的是这个版本的 DX 除了支持 C++ 以外还支持 Visual Basic 。也就是说，从逻辑上讲，你可以用 VB 编一个完整的游戏。但实际上似乎没有人去干这件事情。所以这个特性的实际意义并不在于此，而在于 DX 可以有除 C++ 以外的 Client 。而具备这个能力可以表明 DX 内部逻辑的清晰与完整性达到了一个新的高度。
DX7 是 D3D 真正走向胜利的第一步。根本的原因是在于 Microsoft 和硬件商开始了对未来 3D 技术的合作 .Microsoft 知道硬件商正在发展什么技术，并在新版本的 DX 中给以支持，同时也保持对新技术发展方向有一定的影响力。从而使 DX 在对新技术的支持上始终保持领先地位，这是 OpenGL 所无法做到的。
在 DX7 发布时，唯一一块能支持 Hardware TnL 的显卡是 nVidia 的 Geforce256 。
[ 闲话：关于 3dfx]
3dfx 从 voodoo1 起家，到 voodoo2 如日中天，再到 voodoo3 被 nVidia 逐渐赶上， voodoo4/5 时代开始走向没落，终于没有熬过 2000 年 IT 界寒冷的冬天，于那年年底宣布破产。
虽然与劲敌的 nVidia 的激烈竞争是一个原因，但更大程度上是自己搞砸了。连续的决策失误把自己逼上了绝路。
首先，在 D3D 还没有成长起来的时候，没有将其彻底打垮。试想一下，如果 Microsoft 放弃了 D3D ， Glide 将有很大机会成为 PC 上 3D 唯一的 API 。持有这样一个 API ，会给其他硬件商的崛起造成很大的障碍。而 3dfx 却错失良机， Glide 发展缓慢，从 2.x 到 3.x 竟然花了两年多的时间，而且没有本质的进步，临死基本上还是一个 2D 的 API 。如果说作为一个硬件商，不想更多介入软件事务，那么就应该积极的支持 D3D 或者是 OpenGL 。但 3dfx 也没有这样做，他们很晚才开始编写 D3D 和 OpenGL 的驱动程序。
其次， 1998 年底， 3dfx 收购了板卡制造商 STB ，并且从此高端芯片只提供给 STB ，低端的芯片才给以前的合作伙伴如华硕，创新， ELSA 。这种自绝于人民的行为无疑是要把这些板卡制造商推进 nVidia 的怀抱。
再者，当 3dfx 还沉湎于 multitexture 时 nVidia 早已进入了下一个时代，技术上也确实落后了。
3dfx 破产之后， nVidia 替他收了尸。招募了一些他的员工，购买了一些无形资产，如 voodoo/3dfx 的商标。但很久也没有看到 nVidia 用这些购买来的东西做点什么。后来终于明白了 nVidia 根本就不想用这些东西做些什么。他只是怕有人用 voodoo/3dfx 玩一手借尸还魂，平添一个潜在的威胁。
夏季看来是 DX 更新版本的季节， 1999 年夏， DX7 如期而至。在功能上， D3D 率先支持 Hardware TnL ，以及其他不少高级的渲染技术，如 Matrix Blending 动画， Blinn-Bump mapping. Cubic Environment mapping 。 Hardware TnL 是一个极为重要的功能，就是让显卡来进行 3 维坐标变换和光照计算。 这项繁重的工作以前都是由 CPU 来进行，有了 Hardware TnL 后， CPU 的计算能力就能被节省下来进行 AI 或物理模型的计算。
在 API 布局上， Microsoft 作了大刀阔斧的修改，挪走了几乎所有从 2.0 起就有的 Interface, 诸如， IDirect3DViewport, IDirect3DMaterial, IDirect3DTexture, IDirect3DExecuteBuffer, IDirect3DLight, IDirect3DViewPort 。 只剩下三个 Interface, IDirect3D, IDirect3DDevice, IDirect3DVertexBuffer 。那些被取消的 Interface 变成了简单的数据结构。 IDirect3DTexture 则用 IDirectDrawSurface 来代替。
D3DX 首次出现，这是一个辅助性的 Library 。 其中包含了许多经常要被用到但逻辑上又不属于 D3D 例程。
更出乎意料的是这个版本的 DX 除了支持 C++ 以外还支持 Visual Basic 。也就是说，从逻辑上讲，你可以用 VB 编一个完整的游戏。但实际上似乎没有人去干这件事情。所以这个特性的实际意义并不在于此，而在于 DX 可以有除 C++ 以外的 Client 。而具备这个能力可以表明 DX 内部逻辑的清晰与完整性达到了一个新的高度。
DX7 是 D3D 真正走向胜利的第一步。根本的原因是在于 Microsoft 和硬件商开始了对未来 3D 技术的合作 .Microsoft 知道硬件商正在发展什么技术，并在新版本的 DX 中给以支持，同时也保持对新技术发展方向有一定的影响力。从而使 DX 在对新技术的支持上始终保持领先地位，这是 OpenGL 所无法做到的。
在 DX7 发布时，唯一一块能支持 Hardware TnL 的显卡是 nVidia 的 Geforce256 。
[ 闲话：关于 3dfx]
3dfx 从 voodoo1 起家，到 voodoo2 如日中天，再到 voodoo3 被 nVidia 逐渐赶上， voodoo4/5 时代开始走向没落，终于没有熬过 2000 年 IT 界寒冷的冬天，于那年年底宣布破产。
虽然与劲敌的 nVidia 的激烈竞争是一个原因，但更大程度上是自己搞砸了。连续的决策失误把自己逼上了绝路。
首先，在 D3D 还没有成长起来的时候，没有将其彻底打垮。试想一下，如果 Microsoft 放弃了 D3D ， Glide 将有很大机会成为 PC 上 3D 唯一的 API 。持有这样一个 API ，会给其他硬件商的崛起造成很大的障碍。而 3dfx 却错失良机， Glide 发展缓慢，从 2.x 到 3.x 竟然花了两年多的时间，而且没有本质的进步，临死基本上还是一个 2D 的 API 。如果说作为一个硬件商，不想更多介入软件事务，那么就应该积极的支持 D3D 或者是 OpenGL 。但 3dfx 也没有这样做，他们很晚才开始编写 D3D 和 OpenGL 的驱动程序。
其次， 1998 年底， 3dfx 收购了板卡制造商 STB ，并且从此高端芯片只提供给 STB ，低端的芯片才给以前的合作伙伴如华硕，创新， ELSA 。这种自绝于人民的行为无疑是要把这些板卡制造商推进 nVidia 的怀抱。
再者，当 3dfx 还沉湎于 multitexture 时 nVidia 早已进入了下一个时代，技术上也确实落后了。
3dfx 破产之后， nVidia 替他收了尸。招募了一些他的员工，购买了一些无形资产，如 voodoo/3dfx 的商标。但很久也没有看到 nVidia 用这些购买来的东西做点什么。后来终于明白了 nVidia 根本就不想用这些东西做些什么。他只是怕有人用 voodoo/3dfx 玩一手借尸还魂，平添一个潜在的威胁。
8.0
2000 年夏， DX8 乘胜追击
这一次在功能上的进步毫不逊于 DX7 之于 DX6 ，最大的突破在于引入了 VertexShader 和 PixelShader 。 VertexShader 是作用于每一个顶点的一种小程序，这种程序负责三维坐标变换以及顶点光照，贴图坐标和雾化参数的计算。而 PixelShader 是另一种小程序，这种程序负责对每一个像素，根据它所对应的贴图，材质，以及所采用的特效，计算其最终颜色。这两种程序都是靠显卡硬件执行，所以不占 CPU 的运算能力，这一点和 D3D7 所提出的 Hardware TnL 是一致的。和 Hardware TnL 相比， VertexShader 的突破则是： Hardware TnL 怎样来 T(ransform) 和 L(it) 的算法是固定的，程序员所能控制的只是这些算法的参数，比如变换矩阵和光源信息。 PixelShader 所要取代的是从 DX6 开始出现的 MulitStages Texture pipeline 。而 VertexShader 和 PixelShader 是可编程的，所以，它提供的灵活性非以前任何一个 D3D 版本可同日而语。
除了 Shader 以外， D3D8 还提供了其他若干高级特性，如 VolumeTexture ， Higher-Order Primitive 。 这两项特性并不实用，至少从目前看来是这样。但 Shader 的引入足以使 D3D8 熠熠生辉了。
API 的布局也向着更合理的方向迈进。 DDraw 终于退出了历史舞台。 DDraw 的功能实际上是 D3D 的一个真子集，到了 DX8 时， D3D 能够轻易的做所有 DDraw 能做的事情，而且做的更好，所以 DDraw 没有存在的价值了。
这带来的一个额外的好处是， D3D 的初始化过程变得格外的简捷明了。以前的混乱很大程度上来自 D3D 和 DDraw 相互掺杂，你首先要建立一个 DDraw 的 interface ，然后 SetCooperateLevel ，然后用 DDraw 创建一个 Surface 作为 PrimaryBuffer, 然后用 QueryInterface 从 DDraw interface 里 Query 出一个 D3D interface, 最后调用 DDraw 的 CreateDevice 创建一个 D3DDevice interface 。这是多么繁琐和令人困惑的过程 ! 这种繁琐的过程从 DX2 开始就只是这样。 DX8 终于把这个过程变成了简单而清晰的两句话 :
pD3D = Direct3DCreate8(SDK_VERSION);
pD3D->CreateDevice(….&pDevice);
真是谢天谢地！
其他主要的变化是， IDirect3D8 仅负责创建 IDirect3DDevice8 ，而其他 interface 都由 IDirect3DDevice8 来创建。首次加入了 IDirect3DIndexBuffer8, 并加回了 texture 和 surface 等一些 interface 。（ Texture interface 在 DX7 例被 DDrawSurface 所替代）。
DX8 这样一个 API 就很令人赏心悦目了，相信如果 Carmack 拿这个版本和 OpenGL 比较，绝对会客气很多。
2001 年夏， Microsoft 推出了 DX8.1 ，较之于 8.0 主要的改进是增加了 PixelShader 1.2/1.3/1.4 。
以前总是每年出一个全新的版本，到 DX8 以后，这个速度开始减缓，通常是出一个新版本以后的一两年中只出改进版。 DX9 亦是如此。主要的原因是自 DX7 以后，每一个 DX 版本（ major release ）实际对应于一代新的硬件设备，硬件的更新周期要长于软件，所以 DX 要放慢脚步，另外，游戏开发的复杂程度也越来越高，开发周期也越来越长，而开发商不是很喜欢在开发过程中更新 API 。
DX8 发布至今，无数 3D 游戏涌现，其中绝大多数是基于 D3D 的，基于 OpenGL 的屈指可数， DOOM3 / Never Winter Night / Medal of Honor 。。。 API 之争胜负已判， Microsoft 又一次笑到了最后。
2000 年夏， DX8 乘胜追击
这一次在功能上的进步毫不逊于 DX7 之于 DX6 ，最大的突破在于引入了 VertexShader 和 PixelShader 。 VertexShader 是作用于每一个顶点的一种小程序，这种程序负责三维坐标变换以及顶点光照，贴图坐标和雾化参数的计算。而 PixelShader 是另一种小程序，这种程序负责对每一个像素，根据它所对应的贴图，材质，以及所采用的特效，计算其最终颜色。这两种程序都是靠显卡硬件执行，所以不占 CPU 的运算能力，这一点和 D3D7 所提出的 Hardware TnL 是一致的。和 Hardware TnL 相比， VertexShader 的突破则是： Hardware TnL 怎样来 T(ransform) 和 L(it) 的算法是固定的，程序员所能控制的只是这些算法的参数，比如变换矩阵和光源信息。 PixelShader 所要取代的是从 DX6 开始出现的 MulitStages Texture pipeline 。而 VertexShader 和 PixelShader 是可编程的，所以，它提供的灵活性非以前任何一个 D3D 版本可同日而语。
除了 Shader 以外， D3D8 还提供了其他若干高级特性，如 VolumeTexture ， Higher-Order Primitive 。 这两项特性并不实用，至少从目前看来是这样。但 Shader 的引入足以使 D3D8 熠熠生辉了。
API 的布局也向着更合理的方向迈进。 DDraw 终于退出了历史舞台。 DDraw 的功能实际上是 D3D 的一个真子集，到了 DX8 时， D3D 能够轻易的做所有 DDraw 能做的事情，而且做的更好，所以 DDraw 没有存在的价值了。
这带来的一个额外的好处是， D3D 的初始化过程变得格外的简捷明了。以前的混乱很大程度上来自 D3D 和 DDraw 相互掺杂，你首先要建立一个 DDraw 的 interface ，然后 SetCooperateLevel ，然后用 DDraw 创建一个 Surface 作为 PrimaryBuffer, 然后用 QueryInterface 从 DDraw interface 里 Query 出一个 D3D interface, 最后调用 DDraw 的 CreateDevice 创建一个 D3DDevice interface 。这是多么繁琐和令人困惑的过程 ! 这种繁琐的过程从 DX2 开始就只是这样。 DX8 终于把这个过程变成了简单而清晰的两句话 :
pD3D = Direct3DCreate8(SDK_VERSION);
pD3D->CreateDevice(….&pDevice);
真是谢天谢地！
其他主要的变化是， IDirect3D8 仅负责创建 IDirect3DDevice8 ，而其他 interface 都由 IDirect3DDevice8 来创建。首次加入了 IDirect3DIndexBuffer8, 并加回了 texture 和 surface 等一些 interface 。（ Texture interface 在 DX7 例被 DDrawSurface 所替代）。
DX8 这样一个 API 就很令人赏心悦目了，相信如果 Carmack 拿这个版本和 OpenGL 比较，绝对会客气很多。
2001 年夏， Microsoft 推出了 DX8.1 ，较之于 8.0 主要的改进是增加了 PixelShader 1.2/1.3/1.4 。
以前总是每年出一个全新的版本，到 DX8 以后，这个速度开始减缓，通常是出一个新版本以后的一两年中只出改进版。 DX9 亦是如此。主要的原因是自 DX7 以后，每一个 DX 版本（ major release ）实际对应于一代新的硬件设备，硬件的更新周期要长于软件，所以 DX 要放慢脚步，另外，游戏开发的复杂程度也越来越高，开发周期也越来越长，而开发商不是很喜欢在开发过程中更新 API 。
DX8 发布至今，无数 3D 游戏涌现，其中绝大多数是基于 D3D 的，基于 OpenGL 的屈指可数， DOOM3 / Never Winter Night / Medal of Honor 。。。 API 之争胜负已判， Microsoft 又一次笑到了最后。
9.0
2002 夏季， DX9 发布。 D3D9 的主要进步是提出了 Shader Model2/Model3 ， 相对于 D3D8 里的 Shader1 ， 2 和 3 有更丰富的指令集和寄存器，逻辑结构也更趋于合理。其他增加的功能有 IDirect3DQuery9 用来采集性能测试的数据， Pixel 级别的 ScissorTest 。
2003 年， DX90b, 和 2004 年 DX90c 在 DX90 的基础上完善了一些功能。并提供了更好的支持工具，如 ShaderDebugger, d3dspy, PIX 。
9.0 并不是历史，而是活生生的现在，所以我也不多说什么了。如果你对 3D Programming 感兴趣的话，你可以到 Mircosoft 的站点上去免费下载 DXSDK9.0C ， SDK 里包含了完整的文档和入门教程。看看你能做些什么。
下载地址如下：
http://www.microsoft.com/downloads/...&DisplayLang=en
最后感谢 maozy99 和 sguy 对完成此文所提供的帮助。
( 完 )
2002 夏季， DX9 发布。 D3D9 的主要进步是提出了 Shader Model2/Model3 ， 相对于 D3D8 里的 Shader1 ， 2 和 3 有更丰富的指令集和寄存器，逻辑结构也更趋于合理。其他增加的功能有 IDirect3DQuery9 用来采集性能测试的数据， Pixel 级别的 ScissorTest 。
2003 年， DX90b, 和 2004 年 DX90c 在 DX90 的基础上完善了一些功能。并提供了更好的支持工具，如 ShaderDebugger, d3dspy, PIX 。
9.0 并不是历史，而是活生生的现在，所以我也不多说什么了。如果你对 3D Programming 感兴趣的话，你可以到 Mircosoft 的站点上去免费下载 DXSDK9.0C ， SDK 里包含了完整的文档和入门教程。看看你能做些什么。
下载地址如下：
http://www.microsoft.com/downloads/...&DisplayLang=en
最后感谢 maozy99 和 sguy 对完成此文所提供的帮助。
( 完 )
308
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
