我们将浏览你在 Linux 下会看到的各种游戏库。
Glide2 是一个底层图形 API 和驱动程序，用于访问 XFree86 3.x 下 3dfx Voodoo I、II 和 III 显卡上的 3D 硬件加速功能。
程序只有通过以下两种方式之一使用 Glide2 库，才能使用这些显卡的特殊硬件加速功能
直接使用 Glide2 编写（Myth II、Descent III）
间接使用以 Glide2 后端构建的 Mesa 来模拟 OpenGL（Rune、Unreal Tournament）
3dfx 向开源社区开放了规范和源代码。这使得 Daryll Strauss 能够将 Glide2 移植到 Linux，从而使 XFree86 3.x 用户能够在 Linux 下使用 Voodoo I、II 和 III 显卡。
由于 Glide2 直接访问显卡，Glide2 应用程序需要以 root 身份运行或设置为 setuid root。解决这个问题的方法是创建内核 3dfx 模块。这个模块（及其设备文件/dev/3dfx）允许非 root 用户的非 setuid 应用程序使用 Glide2 图形硬件加速。
不幸的是，Glide2 也已经过时了。它仅用于 Voodoo I、II、III 显卡（这些显卡正在变得过时），在 XFree86 3.x 下（大多数人使用 XFree86 4.x）。由于 3dfx 现在是一家已倒闭的公司，可以肯定的是，Glide2 不会再有任何工作，也不会再有任何使用 Glide2 编写的游戏。
与 Glide2 不同，Glide3 不是用于游戏编程的 API。它仅存在于支持 XFree86 4.x 下 Voodoo III、IV 和 V 显卡上的 DRI。任何使用 Glide2 的游戏都无法与 Glide3 一起工作。这不应该令人惊讶，因为 Glide2 和 Glide3 支持不同的显卡和不同版本的 XFree86。唯一可以同时使用 Glide2（在 XFree86 3.x 下）和 Glide3（在 XFree86 4.x 下）的显卡是 Voodoo III。据报道，使用 Glide2 的 Voodoo III 的性能将优于使用 Glide3 的 Voodoo III。
当你在 XFree86 4.x 下使用 Voodoo III、IV 或 V 时，你希望使用编译为使用 Glide3 作为后端的 Mesa 版本（参见第 3.4 节），以确保你的系统上具有硬件加速的 OpenGL。
OpenGL 是一个高级图形编程 API，最初由 SGI 开发，后来成为 2D 和 3D 图形编程的行业标准。它由架构审查委员会 (ARB) 定义和维护，该组织包括来自 SGI、IBM、DEC 和 Microsoft 的代表。OpenGL 为 2D 和 3D 图形操作提供了一个强大、完整和通用的功能集。
OpenGL 有 3 个规范部分
GL：OpenGL 核心调用
GLU：实用程序调用
GLUT：操作系统独立的窗口事件（鼠标、键盘等）处理程序。
OpenGL 不仅是一个 API，它也是 SGI 编写的实现。该实现尝试在可用时对各种图形操作使用硬件加速，这取决于你的计算机中安装的显卡。如果硬件加速对于特定任务不可行，OpenGL 将回退到软件渲染。这意味着，当你从 SGI 获得 OpenGL 时，如果你想要任何类型的硬件加速，它必须是专门为某些显卡编写和编译的 OpenGL。否则，你只会得到软件渲染。对于 OpenGL 克隆，如 Mesa，情况也是如此。
OpenGL 是 Direct3D 的开源等价物，Direct3D 是 DirectX 的一个组件（第 3.14 节）。重要的区别在于，由于 OpenGL 是开放的（而 DirectX 是封闭的），因此用 OpenGL 编写的游戏比用 DirectX 编写的游戏更容易移植到 Linux 并进行共同开发。
Mesa <http://www.mesa3d.org> 是 OpenGL API 的免费实现，由 Brian Paul 设计和编写。虽然它没有经过官方认证（那将比一个开源项目花费更多的钱），但它是一个几乎完全符合 ARB 规范的 OpenGL 实现。据报道，Mesa 甚至比 SGI 自己的 OpenGL 实现更快。
就像 OpenGL 一样，Mesa 在可能的情况下会利用硬件加速。当特定的图形任务无法通过显卡进行硬件加速时，它会被软件渲染；该任务由你的计算机的 CPU 完成。这意味着 Mesa 有不同的构建版本，具体取决于你拥有的显卡类型。每个构建版本都使用不同的库作为后端渲染器。例如，如果你在 XFree86 3.x 下使用 Voodoo I、II 或 III 显卡，你将使用 mesa+glide2（由 David Bucciarelli 编写），它是 Mesa 的 OpenGL 实现，它使用 Glide2 作为后端来渲染图形操作。
图形渲染有 3 个参与者：客户端应用程序（如 Quake 3）、X 服务器和硬件（显卡）。以前，客户端应用程序被禁止直接写入硬件，这是有充分理由的。允许直接写入硬件的程序可能会以多种方式使系统崩溃。与其信任程序员编写完全没有错误、协作访问硬件的程序，Linux 干脆禁止了它。然而，在带有 DRI（直接渲染基础设施 <http://www.dri.sourceforge.net>）的 X 4.x 下，这种情况发生了变化。DRI 允许 X 客户端以安全和协作的方式将 3D 渲染信息直接写入显卡。
DRI 将 X 服务器排除在外，因此 3D 驱动程序（Mesa 或 OpenGL）可以直接与硬件通信。这加快了速度。3D 渲染信息甚至不必是硬件加速的。从技术角度来看，这有许多优点。
顶点数据不必通过 GLX 进行编码/解码。
图形数据不会通过套接字发送到 X 服务器。
在单处理器机器上，CPU 不必在 XFree86 及其客户端之间切换上下文来渲染图形。
Utah-GLX 是 DRI 的前身。它在数据分离和访问显卡的方法方面做出了一些不同的设计决策，例如依赖 root 访问而不是创建内核基础设施以进行安全访问。它为一些 DRI 不太支持的显卡提供支持，例如 ATI Rage Pro 系列、S3 Virge（尽管任何使用它进行游戏的人，嗯，都很疯狂）和一个开源的 TNT/TNT2 驱动程序（非常不完整）。TNT/TNT2 驱动程序基于对 nVidia 发布的 X 3.3 驱动程序的混淆源代码进行逆向工程。然而，它们真的不完整，实际上，无法使用。
偶尔你会看到一些怪人（带着敬意说）用 xlib 编写游戏。它是一组 C 库，构成了 XFree86 的最低级别编程接口。X 中的任何图形编程最终都使用 xlib 库。
毫不夸张地说，xlib 冗长、神秘且复杂。因此，有很多库，如 SDL（第 3.10 节）用于 2D 图形，OpenGL（第 3.3 节）用于 3D 图形，以及窗口小部件集（第 3.9 节）用于窗口中的小部件，它们隐藏了 xlib 编程不同方面的细节。
虽然有些游戏是用 xlib 编写的，例如 Doom 编辑器 Yadex，但 xlib 本身并不是一个严肃的游戏编写库。大多数游戏不需要 xlib 提供的低级接口。此外，通过使用更高级别的库，游戏编写者可以在多个平台上开发他的游戏，甚至是不使用 XFree86 的平台。
窗口小部件是构成 GUI 应用程序界面的对象。它们包括文本输入框、下拉菜单、滑块条、单选按钮等等。窗口小部件集是相关窗口小部件的集合，旨在具有通用接口和一致的“感觉”。Gtk 是 Linux 上的规范窗口小部件集，但还有许多其他小部件集，如 fltk（一个小型 C++ 窗口小部件集）、Xaw、Qt（KDE 的窗口小部件集）和 Motif（Netscape 使用的窗口小部件集）。Motif 曾经是 Unix 世界中窗口小部件集的王者，但许可费用非常昂贵。“开放组”最终为开源操作系统开放了 Motif 的许可证，但这为时已晚。有许多完全开源的窗口小部件集比 Motif 更完整，外观也更好看，包括 Lesstif，一个完全免费的 Motif 克隆。
SDL <http://www.libsdl.org> 是 Sam Lantiga（UCD 的毕业生，耶！）编写的一个库。它实际上是一个元库，这意味着它不仅是一个隐藏 xlib 编程细节的图形库，它还为声音、音乐和事件处理提供了一个简单的接口。它是 LGPL 许可的，并提供操纵杆和 OpenGL 支持。与 xlib（第 3.8 节）不同，SDL 非常适合游戏编程。
SDL 最引人注目的部分是它是一个跨平台库。除了少数细节外，用 SDL 编写的程序将在 Linux、MS Windows、BeOS、MacOS、MacOS X、Solaris、IRIX、FreeBSD、QNX 和 OSF 下编译。有各种人编写的 SDL 扩展，用于处理你可能提到的任何图形格式、播放 mpeg、显示 truetype 字体、精灵处理以及几乎所有东西。SDL 是所有图形库都应该努力实现的目标的示例。
Sam 编写这样一个酷炫的库有一个不可告人的动机。他是 Loki Software 的首席程序员（他现在为 Blizzard Software 编写代码），Loki Software 在其所有游戏中都使用了 SDL，除了 Quake3。
GGI <http://www.ggi-project.org> 是一个旨在在较低级别代码中实现图形抽象层、将图形硬件支持放入通用代码库以及为图形应用程序带来更高稳定性和可移植性的项目。LibGGI 应用程序在 SVGAlib、fb 和 X 服务器等上运行。从他们的屏幕截图来看，这是一个非常强大的库。
直接使用 LibGGI 的应用程序包括 Heroes、Ultrapoint、Quake 和 Berlin。大多数使用 SVGALib 的应用程序可以通过使用包装器库在 X 或任何其他 LibGGI 后端上运行，该包装器库使用 LibGGI 重新实现了 SVGALib（第 3.12 节）。SDL（第 3.10 节）和 clanlib（第 3.15 节）应用程序可以在 LibGGI 上显示，但通常这些库的本机驱动程序更快，但是，这是一种让 SDL、clanlib 和 SVGALib 应用程序在以前无法运行的地方运行的好方法。
GGI 有一个姊妹项目 KGI，它正在开发内核级替代方案，以替代诸如 linux 帧缓冲和 DRI 之类的系统。这个项目远不如 LibGGI 本身那么先进，但有望结合 DRI 级别的速度以及 UNIX 用户期望的稳定性和安全性。
控制台是你的计算机首次启动时看到的黑色非图形屏幕（并且你没有运行 xdm 或 gdm）。这与具有 xterm 等各种 GUI 事物的 X 环境相反。一个常见的误解是 X 意味着图形，而控制台意味着没有图形。控制台上肯定有图形——我们将讨论实现这一目标的两种最常见方法。
SVGAlib 是一个图形库，可让你在控制台上绘制图形。有许多图形应用程序和游戏使用 SVGAlib，例如 zgv（控制台图形图像查看器）、prboom 和 hhexen。我碰巧是这个库和图形控制台游戏的粉丝；它们非常快速、全屏且引人入胜。SVGAlib 有三个缺点。首先，SVGAlib 可执行文件需要以 root 身份运行或设置为 setuid root，但是，该库在可执行文件开始运行后立即释放 root 状态。其次，SVGAlib 依赖于显卡——如果你的显卡不受 SVGAlib 支持，那你就不走运了。第三，SVGAlib 仅限于 Linux。用 SVGAlib 编写的游戏只能在 Linux 上运行。
帧缓冲区是由图形模式而不是 BIOS 文本模式实现的控制台。为什么要在一个图形环境中模拟文本模式？这允许我们在控制台中运行图形内容，例如允许我们选择我们希望控制台显示的任何字体（这通常由 BIOS 设置）。LDP 提供了一个很好的帧缓冲 HOWTO。使用帧缓冲编写的图形控制台游戏也存在与 SVGA 库相同的缺陷：并非所有硬件都受支持，并且代码只能在 Linux 上运行。
OpenAL <http://www.openal.org> 旨在成为声音领域的 OpenGL，就像 OpenGL 是图形领域的 OpenGL 一样。它最初是 Loki Software 和 Creative Labs 之间的联合项目，旨在成为供应商中立和跨平台的音频 API——相当于 OpenGL 的音频（第 3.3 节）。Loki 不再营业，但 Creative 和开源社区一直保持该项目的活力。它采用 LGPL 许可，并且可以从 OpenAL 网站免费获得规范。它得到了 nVidia 的支持（基于 nForce2/3 的主板配备了用于板载音频的 OpenAL MS Windows 库），Apple 已将 OpenAL 添加到其 OSX 的音频框架中，并且它也可以在 Epic Games Unreal Engine 中找到。
目前，它并非完全跨平台。Linux 上几乎不支持 EAX 或任何硬件加速等增强功能，尽管它在 Windows 实现中确实存在。但是，如果你有 Creative SoundBlaster 或 Audigy 声卡（带有 emu10x 芯片），并且你使用 ALSA 声卡驱动程序，你可以从 http://www.lost.org.uk 获得 OpenAL 库，这些库提供硬件加速和体面的环绕声支持。
DirectX 是一组专有的多媒体 API，最初由 Microsoft 于 1995 年为其各种 Windows 操作系统开发。说“DirectX 就像 OpenGL”或“DirectX 就像 SDL”是错误的，这在 DirectX 教程中很常见。多媒体 API 在 Windows 上比在 Linux 上更集中。更准确的说法可能是“DirectX 就像 DRI、OpenGL 和 SDL 的组合”。截至 2004 年 10 月，最新版本的 DirectX 是 9c。DirectX 的组件是
DirectDraw 提供对视频内存的直接访问，就像 DRI 一样，因此 2D 图形可以直接位图传输到显卡。DirectDraw 就像 SDL 的图形组件，但直接视频卡访问是由 DRI 而不是 SDL 完成的。这就是为什么游戏很容易使 Windows 系统崩溃，但不应该使 Linux 系统崩溃的原因。
Direct3D，就像 OpenGL 一样，提供了一个 3D 图形 API。OpenGL 是开源的、更底层的，并且在多种操作系统下编译，而 D3D 是专有的、更高级别的，并且仅在 Windows 上编译。D3D 首次出现在 1996 年发布的 DirectX 2 中。
DirectAudio 是 2 个音频 API DirectSound 和 DirectMusic 的组合，它们允许直接访问声卡以进行声音和音乐播放。
DirectInput 为游戏输入设备（如操纵杆）提供支持。
DirectPlay 为多人游戏提供简化的网络支持。
DirectShow 提供对 AVI 和 MPG 等电影文件的支持。它是一个与 DirectX 分开的 API，但已与 DirectX 8 集成。
此 API 提供了一种从应用程序内部安装 DirectX 的方法，以简化游戏安装。
根据你谈论的 DirectX 版本，winex（第 10.5.3 节）中的 DirectX 支持范围从良好支持到“某种程度”的支持。wine（第 10.5.1 节）对它的支持很差，vmware（第 10.5.5 节）几乎不支持，而 Win4Lin（第 10.5.4 节）不支持。
关于可移植性的一点评论：DirectX 的每个组件在 Linux 上都有多个对应的库。此外，使用 OpenGL、GGI 或 SDL 等库的游戏编写者将编写一个可以在 Windows、Linux 和许多其他操作系统上轻松编译的游戏。然而，游戏公司仍然坚持使用 DirectX，因此将其受众限制为 Windows 用户。如果你是游戏编写者，请考虑使用跨平台库，并远离 DirectX。
一家名为 realtechVR 的公司启动了一个开源项目 DirectX Port，<http://www.v3x.net/directx>，它像 wine 一样，提供了一个 Direct3D 模拟层，实现了 Direct3D 调用。该项目专注于 BeOS 平台，但现在专注于 MacOS 和 Linux。你可以从他们的 sourceforge 页面 <http://sourceforge.net/projects/dxglwrap> 获取最新的 cvs。