【汉化相关】DirectX简史

shane007 · 发表于 2009-5-30 09:55

简介

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。在项目开发到一半的时候更换名字只会造成更大的混乱…..

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逐渐占到了统治地位。

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对完成此文所提供的帮助。

(完)

灰色小狼 · 发表于 2009-5-30 22:11

可怜的OpenGL…… [s:6]

【汉化相关】DirectX简史

【汉化相关】DirectX简史

楼主热贴

社区热点

浏览过的版块