編者按
本篇文章來自公開的圖形編程學習的電子書 OpenGLBook 的前言部分（一本免費學習 OpenGL 4.0 的編程教程線上書籍，目前已經不再維護），文章不是直接開始編程教學，而是從計算機圖形學的歷史開始敘述，並且以 OpenGL，一個圖形應用程序接口（API）的歷史作為敘述主線至今。
簡單地來說，圖形應用程序接口是為了使得不同的圖形程序（如電子遊戲）能夠在不同的顯卡硬件設備上調用顯卡驅動而形成的軟件抽象層。聽上去似乎是一件不太重要的事，但卻是連接顯卡硬件發展和遊戲軟件開發效果之間最關鍵的中間翻譯角色。
落日間今後會在保持遊戲研究和跨界探索的同時，增加獨立遊戲文化與創作、遊戲設計與開發的認識與祛魅工作。我們也正在同新夥伴們進行一項合作內容計劃，通過擁抱更加具體化的實踐與現實，讓圍繞遊戲的數字人文實踐能夠貫穿本體論的思考與具體的製作（poiesis）中去。
葉梓濤
落日間
Eddy Luten
艾迪·盧頓個人網站上的簡介：大家好，我是 Eddy Luten，是一名擁有二十年專業經驗的軟件工程師。在我的職業生涯中，我發現了對構建有效解決問題的系統的熱情。
初譯：趙晟蘇
校對：葉梓濤
原文鏈接：https://openglbook.com/
編輯過程刪去了結尾部分關於開始學習 OpenGL 的一些具體要求，包括但不限於 1. 需要 C 語言關於指針、數據結構和函數等基礎知識，並知道如何用編譯器鏈接到庫，還有基本的數學知識。2. GPU 需要完全支持 OpenGL 4.0。3. 軟件安裝 C 編譯器，如 Visual Studio，GCC（GNU Compiler Collection），Xcode，並且使用諸如 Eclipse 這樣的IDE 或者文本編輯器。 4. 確定編譯器的庫目錄以確保支持 OpenGL 5. 額外需要安裝處理上下文的 FreeGLUT，加載擴展的 GLEW 等其他庫。
感謝友人白逸、於京平提供的技術角度的編輯建議。
What is OpenGL? 什麼是 OpenGL？
在最基本的層面上，OpenGL 是一個允許程序員與圖形硬件通信的軟件接口（software interface）。當然，OpenGL 的內涵遠不止於此，你會很高興知道本書將為你講解 OpenGL 的更多細節。不過，在我們動手開始編碼之前，你需要了解一下計算機圖形學（Computer Graphics）和 OpenGL 的歷史。
在這篇文章中，我們將探討以下主題： 計算機和計算機圖形學的開端，OpenGL 是什麼，它是如何誕生的， 計算機圖形學是如何工作的，以及學習本書的硬件和軟件要求。
注意：如果你想直接開始圖形編程，而不想讀這些冗長的歷史，你可以直接跳到下面的「要求」部分，讀完它，然後開始閱讀下一章。不過，我必須強調，全面瞭解計算機、計算機圖形學和 OpenGL 的歷史對於理解未來的開發工作非常重要。
最初
無論是通過文字、繪畫還是肢體語言，圖像一直是傳遞信息和記錄歷史的重要手段。視覺反饋的要求是如此重要，以至於如果你看不到某樣東西，就很難肯定它的存在。例如，在十七世紀安東尼·範‧列文虎克（Antonie van Leeuwenhoek）發明顯微鏡並在視覺上發現細菌之前，細菌的存在純屬猜測，但這後來卻成為現代科學不可或缺的一部分。
計算機數據僅以電脈衝的形式表現，這同樣是肉眼無法看到的。所以必須發明一種顯示這種數據的方法，因此早期的計算機科學家通過安裝在電路板上的一系列燈管或穿孔長紙帶（即所謂的「打孔卡‘punch cards’」），從他們的機器上獲得視覺反饋。
可以想象，這些信息的可讀性很差，需要大量的轉譯工作才能將信息轉換成人類可讀的格式。儘管計算機最終配備了電動打字機，但輸出效果卻遠未達到最佳。
顯示器： 陰極射線管
費迪南德·布勞恩，陰極射線管的發明者
1897 年，費迪南德·布勞恩（Ferdinand Braun）在德國發明瞭 CRT（陰極射線管 Cathode Ray Tube），這是一種真空管，其目的是在屏幕上顯示圖像。你可能見過或使用過顯像管電視和計算機顯示器，它們一直是主流，直到最近。
陰極射線顯像管已被用於電視和示波器輸出，但沒有人想到要將這種技術與計算機結合起來。第一次使用顯像管顯示計算機輸出是 1951 年在麻省理工學院（MIT），當時開發的「旋風（Whirlwind）」計算機是美國海軍的飛行模擬器。CRT 使操作人員能夠立即看到計算機程序的輸出，而無需打孔卡、一排排燈管或整理成卷的打印輸出進行轉譯。
雖然由於運營成本高昂，「旋風」項目本身並不十分成功，但通過引入顯像管作為一種可行的計算機輸出設備，它在計算機圖形學的發展方向上邁出了重要的一步。顯像管在計算機圖形學的發展中扮演了重要角色，並在 50 多年的時間裡一直是首選的輸出設備，直到被更新的平板技術所取代。
第一次互動
與畫板配合使用的光筆
儘管 CRT 允許計算機顯示其輸出，但大部分都是文本，並只是為了讀出計算機的當前狀態。這種情況持續了一段時間，因為除了作為純粹的計算用的設備外，沒人考慮過計算機的其他功能。直到 1961 年，伊萬·薩瑟蘭（Ivan Sutherland）在麻省理工學院的畢業論文中開發了一個名為 Sketchpad 的計算機程序，才極大地改變了我們對計算機的看法。
薩瑟蘭的 Sketchpad 程序允許用戶使用光筆在陰極射線顯像管上實時繪製幾何圖形，這在當時具有開創性意義，即使在多年後的今天依然引人注目。它不僅定義了計算機圖形學，還引入了 GUI（發音為「gooey」，代表圖形用戶界面 Graphic User Interface）的前身，併為後來的面向對象編程概念奠定了基礎。Sketchpad 創造了一種範式轉變，即計算機不再是簡單的數字運算設備，還可以用來顯示幾何圖形。
參考：實時計算機圖形 Real-Time Computer Graphics
實時計算機圖形是即時生成的，通常是根據用戶通過鼠標、鍵盤或任何其他輸入設備的輸入而生成的。實時圖形通常應用於諸如電子遊戲和設計程序等應用中。
1968 年，伊萬·薩瑟蘭（Ivan Sutherland）和鮑勃·斯普勞爾（Bob Sproull）實現了另一項技術壯舉，即「達摩克利斯之劍（The Sword of Damocles）」，也就是我們現在所說的虛擬現實技術的前身。這套系統通過頭盔向用戶顯示簡單的三維線框模型，由於重量較重，該系統被懸掛在天花板上。這本身就可能是最早之一（如果不是最早的話）的由計算機生成三維圖形的形式。
更小、更快、更便宜
當然，技術並不是從打孔卡一躍發展到交互式圖形的；計算機也是從龐大的機器逐漸發展到你我每天都在使用的小型設備。
Eniac，著名的第一代計算機
從 20 世紀 40 年代到 50 年代中期，計算機使用真空管（vacuum tube）進行處理，這佔據了整個房間。真空管是一種能以某種方式改變一個電子信號的裝置，例如開關（switching），而開關是計算機所必不可少的功能。組裝一臺計算機所需的部件體積龐大，摸上去滾燙。在這個時代製造的所有機器沒有一臺是一樣的，因此它們的程序無法與其他機器兼容。這個時代通常被稱為計算機的第一世代（first generation），代表了現代計算機科學的第一步。第一節中提到的這些機器使用打孔卡和燈作為輸出設備，因此它們對計算機圖形學的發展貢獻甚微。
20 世紀 50 年代中期，晶體管（transistors）開始取代真空管，創造出更小、更快、更便宜、更節能的第二代計算機。晶體管不僅因其體積小而能夠製造出更小的計算機，而且還開創了全新一代的消費電子產品。例如，收音機現在可以用電池供電並隨身攜帶，而以前它們都是沉重的固定盒子。
但晶體管本身並不是計算機的聖盃，20 世紀 60 年代中期，一種名為集成電路（Integrated Circuit）的新技術帶來了第三代計算機。集成電路將通常由一系列單個晶體管實現的特定功能微型化到單個芯片上。在第三代計算機中，許多計算機都配備了比如鍵盤、顯示器等設備，以及一種名為「操作系統（Operating System）」的新型軟件，該軟件允許計算機運行多個程序。這個時代的一個重要操作系統被稱為 UNIX，它影響了操作系統的許多（如果不是全部）的後續發展。
1971 年，英特爾公司發明了微處理器（Operating System），實現了計算機領域的重大突破，開創了第四代計算機的先河。中央處理器（CPU，Central Processing Units）通常是由許多集成電路焊接而成的電路板，而英特爾公司的 4004 微處理器將所有這些功能都集成在一塊芯片上。由於生產工藝更加廉價，計算機從大型公司和政府使用的專用設備慢慢過渡到更容易為大眾所接受的設備。我們目前仍處於第四代計算機階段，因為我們還沒有擺脫微處理器。
Intel 4004微處理器，開創這一切的小芯片
個人計算機
第一批個人電腦於 20 世紀 70 年代中後期開始出現，但當時被視為業餘愛好者的發燒級機器。隨著 1977 年蘋果電腦公司發佈 Apple II 和 Commodore International 發佈 PET，這種情況發生了一些變化。這些機器普及了家用計算機的概念，但在計算機圖形方面並沒有太多優勢。
到了 20 世紀 80 年代，隨著圖形用戶界面等技術被引入個人計算機市場，這種情況發生了一些變化。在這一時期，第一批專用圖形附加卡（graphics add-on cards）也開始出現，特別是 IBM 的 CGA（彩色圖形適配器，Color Graphics Adapter），它是 IBM 個人計算機平臺上的第一塊彩色圖形卡，通過標準化一種繪製計算機圖形方法為未來的發展鋪平了道路，但在圖形能力方面並沒有提供太多的功能。
在 20 世紀 70 年代和 80 年代，大多數視頻遊戲都是在專用系統上運行的，電影也很少使用計算機動畫，實時三維圖形僅用於可視化（visualization）目的，因為當時還沒有足夠快的消費級硬件。這些年在消費類硬件上出現了許多「第一」，但直到 20 世紀 80 年代末到 90 年代初，電腦遊戲才在 個人電腦 PC 平臺上佔據了一席之地，並開始真正推動更好看、性能更好的實時圖形的發展。
1992年，id Software 發行了第一人稱射擊遊戲《德軍總部 3D》，這是當時推動硬件實現的一款電腦遊戲。雖然《德軍總部》不是真正的 3D 遊戲，但它定義了未來 3D 電腦遊戲的標準。僅僅一年之後，id Software 發行了他們的第一款真正的 3D 遊戲《毀滅戰士》。這是第一次，玩家可以通過臺階和電梯探索他們的環境，而不用被固定在某個高度。許多遊戲模仿了《毀滅戰士》的外觀和感覺，並被稱為「毀滅戰士克隆‘Doom-clones’」。《毀滅戰士》使用軟件渲染器將它的實時圖像渲染到屏幕上，就像 90 年代早期的所有其他遊戲一樣，但這種情況即將改變。
OpenGL：最初的十年
Silicon Graphics（通常簡稱為 SGI）是一家成立於 1981 年的公司，專門從事三維計算機製圖，併為此開發了專門的軟件和硬件。SGI 開發的一個軟件庫是 IRIS GL（集成光柵成像系統圖形庫 Integrated Raster Imaging System Graphical Library），用於在 SGI 的高性能工作站上生成 2D 和 3D 圖形。這個庫即將發展成為 20 世紀 90 年代最重要的計算機圖形開發成果之一。
20 世紀 90 年代初，SGI 因其高性能的硬件和易於使用的軟件而成為三維圖形工作站市場的引領者。IRIS GL 是事實上的行業標準三維圖形庫，蓋過了所有其他三維圖形接口標準化的開發和嘗試。但儘管 IRIS GL 廣為流行，它卻存在一個主要問題：它是一個與 SGI 自己的平臺相融合的專利系統（proprietary system），而競爭對手正在利用它們自己的 API（應用程序接口）向 SGI 的優勢逼近。
SGI 公司大膽地對 IRIS GL 進行了清理，刪除了所有與計算機圖形無關的功能，並於 1992 年將其作為 OpenGL（開放圖形庫，Open Graphics Library）向公眾發佈，OpenGL 是用於實時計算機圖形的跨平臺標準化 API（應用程序接口）。
軟件供應商必須在他們自己的平臺上提供 OpenGL 標準的實現（implementation），而硬件供應商則必須提供允許 OpenGL 與被稱為「設備驅動程序（device drivers）」的底層圖形硬件對話的程序。SGI 公司已經向其客戶提供了這一功能以及一些高層 API，而其他供應商也在抓緊時間開發這一新的、易於使用的API。
靈活性
由於 SGI 沒有提供任何實際的源代碼（source-code），而只是說明了 API 應如何工作的規範（specification）。這種抽象的設計使硬件和軟件廠商可以自由選擇實現 OpenGL 的方式；這種抽象層一直沿用至今。正因為如此，許多平臺和設備都支持 OpenGL；事實上，你很難找到一個不支持 OpenGL 的現代平臺。
但是，OpenGL 為實現者提供的最大優勢可能是它對擴展的支持。如果 OpenGL 規範沒有提供對特定功能的支持，硬件或軟件供應商可以決定通過使用擴展的方式自行添加該功能。許多廠商都選擇這樣做，它們的擴展可以用前綴來區分，如 NVIDIA 的 NV_、Apple 的 AGL_，等等。擴展可以提供強大的功能，但通常只對於廠商的 OpenGL 實現所特有。
然後你可以通過一個擴展加載機制在程序中加載這些擴展，並檢索函數指針，就可以調用這些擴展提供的功能。然而，這種加載機制並沒有標準化，因此每個平臺都有自己特定的擴展加載函數。這種限制在 Microsoft Windows 平臺上最為明顯，因為 OpenGL 頭文件自 OpenGL 1.1 版以來就沒有更新過，即使在最新的 Windows 開發工具包中也是如此。本章稍後將詳細介紹這種情況的原因。
開放的標準
之所以選擇「OpenGL」這個名字，不僅是因為它聽起來像個好聽的流行語，它還包含了一些實際的含義。由於 OpenGL 是一個不斷發展的規範，因此必須有人來決定其中的內容。因此，1992 年成立了 ARB（OpenGL 架構審查委員會 Architecture Review Board），該委員會由多家知名軟件和硬件供應商組成，他們通過投票系統共同決定 OpenGL 標準的未來。除了決定將哪些新功能納入 OpenGL 規範外，它還決定將哪些擴展功能將被提升為下一個 OpenGL 版本的核心功能。
儘管任何人都可以自由開發 OpenGL 的實現方案，但要使其被認定為真正的 OpenGL 實現方案，ARB 必須通過一致性測試予以批准。這些測試通過嚴格的測試程序來驗證實現者聲稱的與特定 OpenGL 版本的兼容性。
參考：樣本一致性測試（Sample Conformance Tests）
要查看部分一致性測試結果，請訪問 Mesa3D.org，點擊一致性測試標題。
OpenGL 很快成為業界領先的實時圖形應用程序接口，因為它基本上是唯一能在多個平臺上可用的。
Windows 上的 OpenGL
1993 年，微軟公司的工作站操作系統 Windows NT 進入市場時，基於 UNIX 的工作站已經開始使用 OpenGL。Windows NT 是作為 UNIX 的直接競爭對手發佈的，它支持聯網（NT 首字母縮寫的意思是網絡技術）和 32 位硬件。Windows NT 引入了至今仍在使用的功能，如用於創建 Windows 應用程序的 Win32 API。但由於系統中沒有 3D 圖形庫，微軟承諾在 Windows NT 中添加對 OpenGL 的支持。
Windows NT 3.5是第一個支持 OpenGL的 Windows 版本——勉強支持
微軟公司終於在 1994 年發佈的 Windows NT 3.5 中實現了 OpenGL，但實現 OpenGL 的程度僅限於通過實現 SGI 公司當時提供的示例實現來聲稱其兼容性。該示例實現的目的僅僅是演示如何實現 OpenGL，併為供應商提供參考。不用說，這實現的速度慢得可怕，因為它沒有經過優化，並且當時 PC 上幾乎不存在圖形加速器。事實上，這個性能問題非常明顯，以至於微軟知識庫中有一篇文章 (KB121282) 警告說，使用 NT 3.5 的 OpenGL 屏保程序可能會降低機器的運行速度，因為它會佔用計算機 CPU 的大量時間。
DirectX
微軟看到了視頻遊戲市場的商機，於是為 Windows 尋找自己的 3D 圖形 API，以慫恿遊戲開發人員拋開 DOS（微軟的第一個操作系統），純粹為 Windows 開發遊戲。他們的首次嘗試是 WinG，它只是將命令傳遞到底層的 GDI（圖形設備接口 Graphics Device Interface）接口，不提供 3D 功能。為此，微軟不得不在 1995 年收購了一家名為 RenderMorphics 的公司，該公司生產了一種名為 Reality Lab 的 3D 圖形 API。該 API 更名為 Direct3D，並在名為 DirectX 的 SDK（軟件開發工具包 Software Development Kit）中發佈，其中還捆綁了其他一些遊戲開發專用的 API：
- DirectDraw 用於快速繪製 2D 圖形
- DirectInput 用於捕捉搖桿輸入
- DirectPlay 用於聯網和通信
- DirectSound 用於聲音播放
Direct3D 的最初版本使用起來很不方便，開發人員採用該 API 的速度也很慢。這使得微軟在繼續支持 OpenGL 的同時，也在努力使 Direct3D 成為具有競爭力的 API。OpenGL 1.1 規範已在 Windows 95 和 Windows NT 4.0 中實施，它帶來了急需的性能提升，但這也是微軟最後一次更新 OpenGL ，轉而採用自己的 API。
「API 大戰」的開端
id software 的約翰·卡馬克
雖然微軟一直堅持認為 OpenGL 最適合用於「專業圖形」，即工作站上的 CAD（計算機輔助設計 Computer Aided Design），但它已開始在視頻遊戲中得到應用，而微軟正試圖通過 DirectX 在 Windows 平臺上主導這一行業。OpenGL 最大的突破來自於 id Software 公司頗具影響力的開發人員約翰·卡馬克（John Carmack）將其著名的視頻遊戲《雷神之錘》移植到 Windows 平臺上來使用 OpenGL API，並向開發人員展示了使用 OpenGL API 是多麼容易。
1996 年 12 月，卡馬克發佈了一份文檔，概述了他對 Direct3D API 的抱怨。他通過比較兩種應用程序接口在屏幕上繪製三角形所需的代碼，概述了這兩種應用程序接口之間的差異；在他的示例中，OpenGL 只需要四行代碼，而 Direct3D 則需要大量的命令和賦值。（校注：2011 年，John Carmack 表示他更喜歡 DirectX 而不是 OpenGL，並且認為微軟有勇氣繼續做出重大的不兼容的改變來改進 API，而 OpenGL 則因兼容性問題而受到阻礙。）
卡馬克直言不諱的解釋方式嚴重損害了 Direct3D 的聲譽，以至於 Direct3D 開發人員亞歷克斯·聖·約翰（Alex St. John）在 1997 年 2 月發表了一篇後續文章，為他的 API 辯護，而奇怪的是，微軟也承認了它的缺陷。他解釋說，Direct3D 在設計時考慮的是直接訪問硬件而不是軟件，由此產生的界面可能並不美觀，但它完成了工作。微軟再次強調，OpenGL 是一個 CAD 庫，不會很快在消費類硬件上得到支持。
這一回應激怒了 SGI 公司，1997 年 6 月，他們對聖約翰的批評做出了自己的回應。這份冗長的文件概述了「Direct3D 設計和當前實施中一些最顯著的缺陷」。它從技術角度而非市場角度指出了兩個 API 之間的差異，並通過更多的代碼示例詳細闡述了卡馬克提到的易用性問題。
參考資料：來來回回
- John Carmack 關於 OpenGL 的 .plan 文件。
- 亞歷克斯-聖約翰撰寫的關於 Direct3D、OpenGL 和約翰-卡馬克的文章。
- 上述 SGI 文件現在只能通過 Archive.org 獲取。
如果您想了解更多相關信息以及當時的微軟文化和亞歷克斯·聖·約翰，可以閱讀這本很棒的書《帝國的變節者（Renegades of the Empire）》，或者訪問他的博客 AlexStJohn.com，在那裡他偶爾會談論他在微軟的時光，以及仍在進行的 OpenGL 與 Direct3D 之爭。
Direct3D 在 5.0 版本中變得更加實用，該版本從 API 中刪除了一些令人不舒服的功能。在這一點上，兩種應用程序接口都對用戶相當友好，功能集也很相似，但這種現狀即將改變。
驅動程序的崩潰
由於 OpenGL 和 Direct3D 在 Windows NT 上處於膠著狀態，微軟需要一個優勢。在 Windows NT 中，OpenGL 驅動程序是通過使用迷你客戶端驅動程序（Mini-Client Driver，MCD）實現的，它是硬件和軟件之間性能較低的折衷方案，但卻是創建驅動程序最簡單的解決方案。MCD 允許供應商挑選他們希望在硬件上加速的部分，而其餘部分則在提供的軟件實現上運行（反之亦然）。微軟通過不允許在 Windows 95 上授權使用 MCD，從而有效地將 OpenGL 限制在微軟提供的軟件實現上，從而獲得了他們所需的優勢。
這一決定對正試圖進入消費市場的 OpenGL 來說是一個巨大的打擊，更不用說那些幾個月來一直在實現這些驅動程序的硬件供應商了。值得慶幸的是，SGI 提供了一種將硬件驅動程序引入 Windows 95 的解決方案，稱為「可安裝客戶端驅動」（ICD，Installable Client Driver）。事實上，這種實現方式比 MCD 驅動程序模式要快上好幾倍，它被證明是一種不幸中的萬幸。硬件供應商抓住這一機遇，迅速開始提供驅動程序。不久之後，遊戲開發商開始在他們的遊戲中使用 OpenGL，再次證明它是 Direct3D 的可行替代品。
硬件的演變
20 世紀 90 年代末，OpenGL 將自己建立為一種三維計算機圖形的行業標準，而不僅僅是 CAD 程序的標準，儘管它是該市場的唯一爭奪者。諸如《雷神之錘 2》《虛幻》和《半條命》等 PC 視頻遊戲充分利用了 OpenGL 的優勢，充分展示了自己的潛力，廣受歡迎。大約在這個時候，第一款消費級專用 3D 圖形硬件開始出現，從此改變了視頻遊戲行業。
舊的 3dfx 標誌
最早的 3D 加速器之一是 3Dfx Interactive 的 Voodoo Graphics，這是一款高性能附加卡，一上市就樹立了標準。雖然還有其他附加卡，如 ATI 3D Rage 和 S3 ViRGE，但 3Dfx 顯卡在性能和功能上都遠遠超過了它們。除此之外，3Dfx 還提供了自己的 3D 圖形 API，名為 Glide，可以直接訪問底層圖形硬件。在當時，Glide 是最快的 API，但由於它是針對特定供應商的，幾年後就被競爭對手的 API 所淘汰。儘管如此，Glide 還是對整個行業產生了影響，導致其他 API 在相當長的一段時間內處於追趕狀態。（校注：3dfx 有非常有趣的一段歷史，他們創始人的老東家就是本文主角 SGI，他們使用一個假的用工作站製作的 Demo 拉投資，這段歷史可以參考極客灣視頻：20年前的遊戲與PC：探秘3D遊戲史上最輝煌的歲月（上） 以及紀錄訪談 3dfx Interactive (Documentary / Interview)，在 Voodoo 推出之後，卡馬克發佈了基於 OpenGL 的硬件加速版本的《GLQuake》）
舊的英偉達圖標
英偉達（NVIDIA）公司很快就在 1999 年推出了 GeForce 256 附加卡，並稱之為 GPU（圖形處理單元 Graphics Processing Unit），它支持一種名為變換與照明（通常稱為 T&L，Transform & Lighting）的全新技術。T&L 將頂點變換計算和光照計算從計算機的 CPU 轉移到了 GPU 上（校注：英偉達將 GPU 概念定義為支持硬件 T&L 的圖形芯片）。
GPU 的主要優勢在於它能快速完成浮點運算，因為這種硬件專門用於這項任務，而 CPU 則專門用於整數和更通用目的的運算。更多的軟件功能被轉移到了 GPU 上，而 3Dfx 從來沒有實現過 T&L，這最終導致了他們的敗落。（校注：根據極客灣視頻，3dfx 的失敗還有一系列諸如和世嘉的合作告吹，收回授權，獨造顯卡，圖形 API 等原因，3Dfx 也進行了支持硬件 T&L 的 Rampage 架構的研發，但是並沒有成功）
3Dfx 破產後，英偉達™（NVIDIA®）公司收購了其大部分知識產權（包括著名的 SLI 技術，校注：最早被稱作Scan Line Interleave，使用交錯渲染方式，主卡副卡渲染單雙數行，後來改為 Scalable Link Interface 可拓展鏈接界面，可以將兩張或以上的顯卡連在一起使用），但沒有繼續 Voodoo 產品線，也沒有支持 3Dfx 的任何舊產品。到 2000 年，GPU 市場上的競爭對手只剩下英偉達公司的 GeForce 2 和 ATI 公司的鐳龍 Radeon 7000 系列 GPU。這兩家廠商只提供對 OpenGL 和 Direct3D 的支持，為這些應用程序接口的正面交鋒掃清了障礙。
參考：軟件與硬件
當我們說某項功能是軟件功能（software functionality）時，這意味著它是在 CPU 而不是 GPU 上執行的。當我們說某項功能是硬件功能時，這意味著該功能是在專用硬件上執行的。例如，軟件渲染僅通過 CPU 完成，而硬件渲染僅在 GPU 上完成。
範式轉變
本世紀初，隨著 GPU 的性能呈指數級增長，隨著越來越多的軟件功能被轉移到 GPU 上。由於 CPU 無法跟上 GPU 的發展，CPU 在渲染實時 3D 圖形方面已經過時。事實上，當前的 3D 圖形渲染方法將 CPU 視為主要瓶頸，因此必須發明新的方法來規避 CPU 的使用。
緩衝區
在此之前，為了在屏幕上進行渲染，程序員會從程序中發出一系列命令，由 GPU 進行解釋，這就是所謂的即時模式（immediate mode）。這種方法在處理較小的數據集時表現良好，但在處理較大的數據集時，由於所有函數調用都來自程序本身，因此性能會受到 CPU 性能的影響。
新方法以緩衝對象（buffer objects）的形式出現。緩衝以顯示列表（display list）和頂點數組（vertex arrays）的形式出現已有一段時間，但它們各有缺點。顯示列表仍然使用即時模式，而頂點數組則存儲在系統內存中，因此每次調用都必須將它們傳輸到 GPU。
取而代之的是，新的緩衝對象將在初始化後存儲在 GPU 的內存中，直到不再需要為止。在 OpenGL 中，這些對象被稱為頂點緩衝對象（Vertex Buffer Objects，VBO），而在 Direct3D 中，它們被稱為頂點緩衝區（Vertex Buffers）。您將在以後的章節中瞭解到更多有關 VBO 的信息，該章節將向您介紹 VBO 以及它們為何如此快速的原因。
參考：緩衝區
在計算機科學中，緩衝區是內存中存儲臨時數據的地方。當我們用完這些數據後，緩衝區就會被刪除，內存就可以重新使用了。
著色器
2000 年，微軟發佈了 Direct3D 8.0，它支持一種名為著色器的新特性。著色器基本上就是直接在 GPU 上運行的小程序，因此可以充分利用 GPU 的更多能力，並將更多的功能從 CPU 上移開。Direct3D 8.0 發佈時，公佈了兩種類型的著色器，即頂點著色器和像素著色器。（校注：2001年，英偉達發佈 GeForce 3，第一款兼容 Direct3D 8.0 的3D卡，使用了可編程著色器架構，能夠使用著色器語言，微軟提出了 Shader Model，要求顯卡廠商生產時提供對應的功能和指令的支持），
頂點著色器（vertex shaders）是一種 GPU 程序，每個頂點執行一次，像素著色器（pixel shaders）是一種 GPU 程序，每個像素執行一次。著色器在許多任務中無需使用 CPU，從而帶來了更好的可編程性和性能，但由於其語法類似於 CPU 的彙編編程語言（Assembly programming language），因此很難編程。
2003 年，隨著 Direct3D 9.0 的發佈，高級著色器語言（HLSL，High-Level Shader Language）的形式在著色器方面取得了重大突破。這種新語言允許使用基於 C 語言語法的高級語言來操作著色器。此時，著色器的使用變得更加可行，並得到了廣泛採用。你將在之後的章節中瞭解到更多關於頂點和像素著色器的知識，我們將在這些章節中深入探討如何實現所有這些功能，以及如何在自己的程序中使用著色器。
（校注：DirectX 9.0c 帶來了 Shader Model 3.0 的支持，加入了例如位移貼圖 Displacement Texture、次表面散射 Subsurface Scattering、軟陰影 Soft Shadow、全局光照 Global Illumination 等特效））
OpenGL 的發展停滯
上段沒有提到 OpenGL 是有原因的，那就是 OpenGL 當時不支持任何著色器。OpenGL 直到 2004 年發佈了 OpenGL 2.0 並同時發佈了 OpenGL 著色語言 （GLSL，OpenGL Shading Language）後才正式支持著色器，當時。儘管使用著色器的擴展功能在 2004 年之前就已廣泛存在，但它們並不是官方規範的一部分，需要數年時間才能完全恰當地實現。
在核心功能方面，OpenGL 已大大落後於 Direct3D。就像 Direct3D 在 90 年代末一直在迎頭趕上一樣，OpenGL 現在必須趕上 Direct3D，但這並未實現。從 2004 年到 2006 年，Direct3D 9.0 在市場上佔據主導地位，只有少數遊戲支持 OpenGL。2005 年，支持 Direct3D 9.0 的 Xbox 360 發佈後，對 Direct3D 的支持更上一層樓。在此期間，ARB 沒有任何消息，OpenGL 似乎真死了一段時間。
2006 年，OpenGL 2.1 作為原始 2.0 規範的一個小增量發佈，只帶來了少量新功能。雪上加霜的是，微軟在發佈新的 Windows Vista 操作系統的同時還發布了 Direct3D 10.0，其中包括對 API 的重大修改和許多新功能。硬件開始向新的方向發展，從即時模式、固定功能方法轉向更可編程的方向，而這正是 OpenGL 所缺乏的。
與此同時，OpenGL 開發者社區開始躁動不安，他們要求 ARB 或 SGI 給出答案，但得到的卻是完全不同的結果。
新版 OpenGL
在 2006 年的 SIGGRAPH 大會上，SGI 宣佈 OpenGL 今後將由科納斯（Khronos）集團，而不是 SGI 管理，SGI 仍擁有 OpenGL 和所有相關版權，但將不再對其進行管理。Khronos 集團是一個由硬件和軟件廠商組成的聯盟，與 OpenGL 有著千絲萬縷的聯繫，主要致力於創建和維護開放標準的 API，在收購 OpenGL 之前最著名的是用於 3D 內容的 COLLADA 文件格式。最後，在 OpenGL 方面，兩年來首次傳出 OpenGL API 的全新版本將帶來一些重大變化。
Longs Peak 和 Mt. Evans
OpenGL 的兩個新版本發佈了，臨時代號為 Longs Peak（朗斯峰）和 Mt. Evans（埃文斯山） ，以科羅拉多州的山脈命名。Longs Peak 將是 2007 年夏天發佈的第一個規範，而 Mt. Evans 將在幾個月後的同年 10 月發佈。
這些修訂承諾了一個全新的 API，能夠與 Direct3D 10 的 API 競爭，就像 Direct3D 10 所做的那樣，Mt. Evans 將消除即時模式渲染，只依賴緩衝區和著色器。這次 API 重寫是一個偉大的事業，需要幾個技術小組（Technical Sub-Groups，TSG），他們專注於自己的 OpenGL 規範的專業領域。
對象模型 TSG （Object Model TSG）就是其中之一，負責處理如何在新的 API 中表示緩衝區和其他類型的對象。擬定的對象模型提出了一種只需調用幾個函數就能創建對象的全新方法。最重要的是，通過使用模板（templates），所有類型的對象所使用的方法都將保持一致。這意味著供應商之間將不再存在不符合之處，他們將以五花八門的方式提供他們的對象創建功能。
Longs Peak 將是一個與當時硬件兼容的 API，並保留與舊版本 OpenGL 的向後兼容性，而 Mt. Evans 將消除向後兼容性，並採取未來的立場。這與對象模型一起成為了被提議的 API 的主要部分，引起了 OpenGL 社區的極大期待。
但 2007 年夏天過去了，Khronos 沒有任何消息，10 月 30 日，又傳出新規範被推遲的消息。雖然社區有些不滿，但總體上認為新規範值得等待，於是又過了一年。
OpenGL 3.0
OpenGL 2.1 小版本發佈至今已有兩年，而上一次重大版本 OpenGL 3.0 於 2008 年 7 月發佈，距今已有四年。閱讀規範後，我們很快就注意到這不是 Longs Peak。事實上，它看起來並沒有什麼變化：即時模式依然存在，提議的對象模型不見了，也沒有計劃將其納入 OpenGL 未來的任何版本中。在引入一些新功能的同時，還引入了一種叫做廢棄模式（deprecation model）的東西。
廢棄模式將所有即時模式功能標記為棄用，轉而使用更現代的方法。然而，OpenGL 3.0 並沒有計劃刪除任何已廢棄的功能，而是將其作為一個完全向後兼容的 API，並保留了過去的所有有缺陷的功能。
這引起了社區的憤怒，他們在 OpenGL 社區留言板和其他網絡上大聲抗議。有人無端指責說，OpenGL 保持向後兼容是因為 Khronos 不想失去那些仍在使用即時模式並拒絕變化的 CAD 客戶。許多 Windows 開發人員開始放棄 OpenGL，轉而使用 Direct3D，其中包括一些被指控的 CAD 軟件開發人員。如果說之前 OpenGL 的前景黯淡無光，那麼這次的發佈無疑讓人看到了 OpenGL 在 API 大戰中的徹底失敗。
衝擊之後
但在最初的失望過後，新規範被證明具有一些 Direct3D 所不具備的特性。例如，OpenGL 3.0 包含 Direct3D 10 的許多功能，但可以在 Windows XP 上使用，而 Direct3D 10 由於採用了新的驅動程序模型，需要 Windows Vista 才能運行。
大約一年後的 2009 年 3 月，OpenGL 3.1 發佈，它最終從 OpenGL 規範中刪除了 3.0 中所有被標記為過時的即時模式功能，從而使其向 Longs Peak 和 Mt.Evans 中所承諾的 API 踏進了一步。隨著這一快速版本的發佈，OpenGL 終於回到了正確的道路上，僅僅幾個月後，OpenGL 3.2 發佈，通過加入幾何著色器（Geometry Shaders），使 API 達到了 Direct3D 10 的水平。
棄用、核心和兼容性
OpenGL 廢棄模式可能有點令人困惑，因此在本節中，我將嘗試一次性解釋相關的術語。OpenGL 3.0 引入了一項名為廢棄（deprecation）的特性，它「標記（marked）」舊的、不需要的 OpenGL 功能，並警告說這些功能可能會在未來的規範中被移除；基本上，在程序中使用棄用的功能不是一個好主意。
當開發人員想在自己的程序中使用 OpenGL 時，他們需要創建一個所謂的上下文（context），基本上就是一個允許開發人員向 OpenGL 設備傳遞命令的對象。在過去，無論實現的 OpenGL 版本，這些上下文都是以相同的方式創建的。
這意味著，當你創建一個使用 OpenGL 1.5 特性的設備時，如果驅動程序返回的是一個 OpenGL 2.0 設備，這並不會造成危害，因為所有上下文都是完全向後兼容的。OpenGL 3.0 引入了一種創建上下文的新方法，要求在創建上下文時提供以下參數：- 主版本號 - 次版本號 - 可選屬性。
如果是一份 OpenGL 3.0 上下文，相應的值將是 3、0 和一些屬性組合。這一新功能可確保返回的設備是所請求的 OpenGL 設備，否則就意味著該版本不支持。可傳遞的屬性使選擇更加精細，包括以下屬性之一：- 核心配置文件上下文標記（A Core Profile context flag） - 兼容性配置文件上下文標記（A Compatibility Profile context flag） - 向前兼容標記 - 調試標記。
這兩個配置文件之間的區別在於，核心配置文件不包含以前版本中刪除的任何功能，而兼容性配置文件包含這些功能。OpenGL 實現總是保證包含規範的核心配置文件，但不一定包含兼容性配置文件。向前兼容核心規範是最合理的做法，也是創建這種上下文的初衷。
如果您設置了「向前兼容」的標記，返回的上下文將不包含您請求的版本中已廢棄的任何功能，從而使其與可能已刪除這些功能的未來版本兼容。
如果設置了調試標記，返回的調試上下文將包含額外的檢查、驗證和其他功能，這些功能在開發週期中非常有用。
上述標誌都可以組合在一起，但核心標誌和兼容性標誌除外，因為只能返回其中一個標誌。組合標誌可以使用位操作符 OR （即 C 語言中的管線命令符號 (|) ）。
如果這些術語對你來說還有點模糊，別擔心，我們會在附錄中再次講解，我們將在特定平臺上從頭開始設置 OpenGL 上下文。現在，請記住有兩種 OpenGL 配置文件：Core（核心）和 Compatibility（兼容性），前者是更現代的配置文件，後者是兼容舊版 OpenGL 功能的配置文件。
OpenGL 4.0
OpenGL 3.2 發佈一年後，OpenGL 4.0 作為最新一代 GPU 的應用程序接口發佈，與 Direct3D 11 類似。與此同時，OpenGL 3.3 也發佈了，它在兼容上一代硬件的同時，儘可能多地實現了 OpenGL 4.0 的功能。
OpenGL 4.0 中的一項重要新功能稱為「曲面細分（Tessellation）」，它允許對場景中的表面和自動細節級別進行精細控制。我們將在以後的章節中探討什麼是曲面細分以及如何使用它。（校注：DX 11 同樣擁有曲面細分的功能）
本書使用的是啟用了核心配置文件的 OpenGL 4.0 規範，這意味著它與任何以前版本的 OpenGL API 都不兼容。為了儘可能與未來兼容，我們也不會使用任何過時的功能。起初，這似乎有點令人生畏，但請放心，學習起來並沒有想象中那麼困難，而且從長遠來看，不學習舊功能將是有益的。
如果你已經瞭解一些即時模式 OpenGL，請注意我們將不介紹這種類型的 OpenGL。在本書中，你將找不到諸如 glBegin、glEnd、glVertex3f 和 glColor3f 等命令（除了這些參考資料），因為 OpenGL 4.0 Core Profile 中沒有這些命令。忘掉到目前為止所學到的關於即時模式 OpenGL 的所有知識，也忘掉即時模式 API 曾存在過，因為它再也不會回來了。
現在是開始學習 OpenGL 的大好時機，因為視頻遊戲正被大量移植到 Microsoft Windows 以外的平臺上，而在 Windows 以外的平臺上獲得實時計算機圖形的唯一途徑就是 OpenGL。例如，《半條命》的開發商 Valve 就使用 OpenGL 作為圖形庫，將他們的許多熱門遊戲移植到了蘋果 Macintosh 上。
此外，現代智能手機（如 iPhone 和基於 Android 的手機）都使用 OpenGL ES 來實現交互式 3D 圖形，這是一種基於嵌入式系統（embedded systems）的 API，與 OpenGL 非常相似。這意味著，您的代碼可以在 PC、Mac、遊戲機以及各種移動設備上運行。
OpenGL ES 本身催生了另一個名為 WebGL 的 API，這是一個跨瀏覽器、跨平臺兼容的三維圖形應用程序接口，適用於網絡瀏覽器。這個庫有可能將網絡和多用戶應用程序提升到一個全新的水平。
總之，OpenGL 遠未消亡，它作為功能齊全的現代 3D 圖形 API 正在蓬勃發展。
軟件管線
在渲染實時計算機圖形時，軟件管線（software pipeline）的存在是為了描述我們希望在屏幕上看到什麼。例如，如果我們想在屏幕上顯示一個綠色的正方形，計算機軟件就會描述該正方形的尺寸、顏色以及在屏幕的哪個位置繪製。
軟件管線還提供了將幾何圖形繪製到屏幕上的功能。值得注意的是，軟件管線實際上並不進行任何繪製或變換，因為在現代系統中，這些功能完全由硬件實現。
軟件管線由幾個不同的層組成，每個層都有自己非常特殊的用途。每一層都可能包含五花八門的功能，但為了簡潔明瞭，我們只討論每一層的高級功能。
首先是應用（Application）層，也就是你調用繪製命令的程序。應用程序是整個進程的控制器，負責監督所有用戶層級的操作，如創建窗口、線程、內存分配、複雜的用戶數據類型，以及通過各自的接口調用 OpenGL 或 Direct3D 等外部庫。
下一層是抽象（Abstraction）層，包含 OpenGL 或 Direct3D API 實現。重要的是要區分應用層中的 API 與抽象層中的 OpenGL 和 Direct3D 實現。用 C 語言來說：您可以將應用層視為只包含定義的頭文件，而抽象層則是包含實際功能的源文件。抽象層來進行發送至下一層，通過以可用的和標準化格式實現硬件層級的功能。
抽象層將其命令傳遞給設備驅動（Device Driver），這是一個與硬件通信的軟件層。這層對於開發人員來說是不可見的，因為其無法通過程序進行交互。就像許多不可見的東西一樣（還記得細菌嗎），設備驅動是軟件管線中最重要的部分之一，因為它將所有單獨的部分連接在一起。由於設備驅動中包含大量專業功能，其文件大小可能相當龐大。
設備驅動程序解釋抽象層傳遞給它的命令，並以硬件可以理解和輕鬆處理的格式將這些命令轉發給底層設備。
從本質上講，軟件流水線就是從程序到專用硬件的傳輸系統（relay）。雖然軟件管線非常重要，但在程序中真正會用到的只有應用層，它向你公開了 API。
編後記（該部分為編者資料收集自行補充）
在本文敘述的時間點之後（2014），圖形 API 的情況實際上更加複雜了。
OpenGL 的設計目標之一是易用性和跨平臺兼容性，其抽象層次不允許開發者直接控制硬件細節來充分利用顯卡的並行計算等能力。故 OpenGL 的管理者 Khronos Group 由最初的 AMD 開發的 Mantle 而發展出了更加底層的圖形 API 標準
Vulkan，在 2015 年將其宣佈為下一代的 OpenGL 計劃，隨著移動平臺性能的提升，提供新的統一的行業標準（先前由於移動平臺硬件問題，催生 OpenGL ES 的壓縮版本）。如老牌遊戲開發商 id software 的自研引擎 id tech 6 所開發出的《德軍總部 2》以及《DOOM》就有非常良好的 Vulkan 的表現。
微軟 Direct3D 12 版本也是同樣的思路，更進一步更新為底層 API 來更直接地和底層硬件進行交流，提供優化和充分發揮硬件能力的可能，並隨著後續更新，加入了光線追蹤（Ray Tracing）的功能。而 Apple 蘋果作為軟硬件結合的開發商，也發佈了自家的圖形 API Metal，同樣也是一個底層級的圖形 API。
使用越底層的圖形 API 的遊戲或軟件並不代表其性能一定好，因為其編碼要求更高，如果沒有足夠豐富的經驗和能力，可能還不如使用更高層的 API，就如同樣使用了 DX12 的《方舟進化》的表現遠不如《戰地1》一樣。（在遊戲主機如 PS4上，也有諸如 GNM 底層 API 和使用 GNMX 高層 API 的區別）。
但電子遊戲的開發者並不常直接使用對應的圖形 API 進行遊戲開發，因為那就需要每開發一個平臺都要寫一次圖形和渲染代碼——開發者通常使用遊戲引擎作為一個不同平臺和圖形 API 的中間層來進行開發。
所以當前的遊戲引擎如 Unity，就會支持多種圖形 API （https://docs.unity3d.com/Manual/GraphicsAPIs.html），具體取決於 API 在特定平臺上的可用性。那麼如果開發者要在遊戲引擎（這樣的一個跨平臺應用）中寫調用底層 GPU 的 shader 代碼，那麼你需要使用引擎所推薦的著色器語言，如 Unity 中你需要使用 HLSL（High Level Shading Language，是 Direct X 圖形 API的語言），以及 Unity 官方的 Shaderlab 框架（底層為 Nvidia 的 Cg 語言）來編寫 Shader（或使用 Shader Graph），而後 Unity 會再將其編譯為能夠調用其他圖形 API 的語言。
故縱觀計算機圖形學到電子遊戲渲染的歷史，這始終是一個統一與分裂的市場競爭，以及性能與通用性之間的權衡：1. 不同顯卡硬件及其顯卡驅動需要支持同樣的圖形 API 的標準來便於軟件使用，但最終還是分裂為了多種圖形 API。2. 不同的圖形 API 標準需要被同樣的遊戲引擎的圖形架構所統一，以便於開發者能夠在一個引擎上開發適用於多平臺的遊戲。3. 但是這個遊戲引擎對接各個圖形 API 的圖形架構的統一模版並不能滿足多樣的遊戲渲染風格的要求，故過去的 Unity 統一的內置（built-in）的渲染管線又再一次需要更加可定製化，開放了可編程渲染管線，Scriptable Render Pipeline，將圖形架構變得可以定製修改的，提供一個更靈活的，對應不同圖形 API 的可編程的函數，可容許更加底層定製的渲染管線的自定義。
而今天的手機應用也擁有同樣複雜的情形，使用引擎或者在某些平臺上開發的應用，有可能再一次地成為某種獨立和統一的區塊（例如中國正是一個 app 作為底層平臺的互聯網環境）。網頁端實際上為我們提供了一個通過瀏覽器而在不同平臺上有相同運行環境的統一層（如 mac，windows，安卓和 ios 上的瀏覽器應用），使得瀏覽器的 js 代碼等運行良好，而諸如微信這樣的應用則又再封裝一層，通過改造傳統瀏覽器的一些代碼而再出現了諸如小程序/小遊戲這樣的獨立生態。
這種充滿了複雜度和競爭統一和跨平臺問題過程實際上就正是技術發展和演進的過程，也是我們今天在各種絲滑的應用背後被封裝起來的暗流。
更多可以參考的資料：
- 20年前的遊戲與PC：探秘3D遊戲史上最輝煌的歲月（上）
- 【科普】DirectX和OpenGL：遊戲為什麼離不開它們？
- A Review of Shader Languages
日 | 落譯介計劃 是數字人文實驗室落日間對一些有助於思考遊戲/電子遊戲的外文文本翻譯和推薦/索引計劃。（請查看網站 xpaidia.com/sunset-project/）。
Uricchio 模擬，歷史與電腦遊戲 Simulation, History and Computer Game (2005)
Charles Deemer 什麼是超文本？What is Hypertext？（1994）
Maxwell Foxman 團結則立：Unity 引擎帶來的平臺、工具與創新 (2019)
感謝支持落日間的朋友們！
歡迎讚賞或贊助落日間，加入內測計劃，查看並且優先參與落日間正在進行的其他未公開項目，並且每週收到至少一篇我們情感異樣豐富的小作文。詳情可點擊閱讀原文，或進入：xpaidia.com/donation