我找不到一个理由不让这篇文章多一份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
PDA
查看完整版本 : Carmack 谈 d3d 与 ogl
black
2004-10-23, 14:56
不知道此文的确切时间
但从文中的一些内容来看，可能是在dx3.0 - dx5.0 之间
不知道卡马克者，质疑卡马克实力者，请不要发言。否则可能会被全世界的程序员用口水淹死
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
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无疑是非常必要的，从中我们可以了解它们的历史、现状和未来的发展，借机了解整个图形技术的发展状况。
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很有机会成为该领域的主宰。
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环境基本不耗费多少硬件资源。
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规格与显卡的性能
支持何种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就这样消失了。
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逐渐占到了统治地位。
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玩一手借尸还魂，平添一个潜在的威胁。
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又一次笑到了最后。
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对完成此文所提供的帮助。
(完)
xade
2004-10-23, 19:27
John Carmack谈论OpenGL 和 D3D
现在，我已经对了有了足够的了解。我并不打算把导入过程进行到底。我完全可以用庑┦奔淅醋龈又匾氖虑椤?br>
乱码识别
现在，我已经对了（貌似应该是“此”）有了足够的了解。我并不打算把导入过程进行到底。我完全可以用这些时间来做更加重要的事情。
black
2004-10-23, 19:45
乱码校验
我并不打算把导入过程进行到底。我完全可以用这些时间来做追更多的 MM。
xade
2004-10-23, 20:47
轰杀楼上 1w 次
vBulletin 3.5.4, 版权所有 ©2000-2006, Jelsoft Enterprises Ltd.