我找不到一个理由不让这篇文章多一份Copy
原地址：http://bbs.emu-zone.org/forums/archive/index.php/t-70.html
在经过这段时间的积累和沉淀
再看一遍这篇文章
只觉得脑海里清楚多了
也算是一次总结
回想起原来的种种疑问
我应该算是渐悟派的吧
PS，文章里有一个CGD的BBS链接，当然已经失效，让我又想起伟大的ChinaGameDev在英明神武的Dizzarz的领导下，已经名存实亡，回想当年一起跟Mays一起找地方放bbs，虽然几次易址，但终于有了家，而现在的CGD，却变成Dizzarz为了得到一份工作而与CSDN作交换的筹码而已。总舵主您先是将Mays苦心经营多年，具有国内GameDev风范的CGD从一个技术网站沦落成BBS，然后持续疏于管理，借口学业很忙，却学不会像Mays那样去找接班人，等自己有了新东家后，现在只是一片废墟。我只能对你表示强烈得BS，谴责你当初口口声声要接下CGD的动机！
勇者之城 > 主论坛 > 地下4楼 > Carmack 谈 d3d 与 ogl
查看完整版本 : Carmack 谈 d3d 与 ogl
black
不知道此文的确切时间
但从文中的一些内容来看，可能是在dx3.0 - dx5.0 之间
不知道卡马克者，质疑卡马克实力者，请不要发言。否则可能会被全世界的程序员用口水淹死
ZT 至 http://bbs.chinagamedev.net/showthread.php?t=8517
black
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
goldegg
偶也来厚道的转贴。
恩，我想说，你用什么顺手就用什么。
goldegg
不论是哪一种类型的图形芯片，总会支持某个版本的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无疑是非常必要的，从中我们可以了解它们的历史、现状和未来的发展，借机了解整个图形技术的发展状况。
goldegg
定位专业应用的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
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
到这里，非常有必要介绍所谓的“纯OpenGL
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
专注娱乐应用的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
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实际上可以显示出
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
未来：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规格与显卡的性能
支持何种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
今天原来是厚道的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 之上。
让我们回想一下