[转] Carmack 谈 d3d 与 ogl， 定位专业应用的OpenGL， 专注娱乐应用的DirectX， 未来：OpenGL、DirectX并行发展...
我找不到一個理由不讓這篇文章多一份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.
?
轉載于:https://www.cnblogs.com/oiramario/archive/2006/07/24/458421.html
總結
以上是生活随笔為你收集整理的[转] Carmack 谈 d3d 与 ogl， 定位专业应用的OpenGL， 专注娱乐应用的DirectX， 未来：OpenGL、DirectX并行发展...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 经典按键java手机游戏_盘点曾经红极一
- 下一篇： 苹果几是双卡双待_苹果史上首款实体双卡双