跨平台底层图形API

创建系统抽象时，最好在有意义的最低级别上用通用接口隐藏平台不同的API。

考虑到不同的现代（无固定功能管道）本地图形API：OpenGLES 2.0 +，OpengGL 3.0 +，DirectX 10.0 +，Xbox DirectX 9，LibGCM

如果要创建一个无状态的低级图形API放在所有这些之上，那么使它尽可能薄且尽可能快的最佳方法是什么？

从我的角度来看，最合理的级别是谈论渲染所涉及的资源-vb / ib，渲染表面，纹理，着色器，状态块等。

这里的问题是，其中一些需要采用不同的格式，具体取决于API-这在这里有些棘手。解决该问题的最简单方法是为相应的API预处理静态资源。对于动态着色器，仅使用着色器生成它们-这使得保持本机格式相当简单。

然后，您在更高级别上要做的就是设置带有附加资源的管道，并将其移交给GPU。您会发现并非所有内容都能以这种方式很好地抽象出来，特别是如果您利用了特定于硬件的技巧。但这是一个好的开始。

（旁注：如果将特定于平台的技巧当作一种特殊资源，则可以将整个概念推得很远。）

因此，在某种程度上，您将创建两件事情：硬件资源管理器，以及用于设置这些资源的DAG的工具包。

鉴于您希望涵盖的API种类繁多，典型的包装方法可能效率低下，并且难以在可能会或可能不支持特定功能的其他多个API之间映射API概念。

结果，最明智的方法是创建一个以功能为中心的 API。尽管此方法阻止API用户利用所有可用功能，但它极大地简化了每个后端的实现，并启用了其他特定于后端的优化。

它还极大地简化了API用户不受支持的功能的管理；他们不再需要检查功能X是否存在并确定受影响的功能，而只需要查询功能本身以查看当前配置是否支持该功能。即使您支持要素的部分或有限模式，提供的上下文也使管理起来更加容易。

就创建无状态（也称为基于提交）的渲染器而言，通常使用64位密钥来打包和提交用于渲染的命令。从那时起，根据您要支持的功能和特性，在如何执行命令和提交哪些信息方面具有很大的灵活性。

首先，每个API的功能都不同，因此，不用说包装以上所有API都会很困难。就是说，有时这样做是必要的：在某个时候，一个游戏仅需要在多个平台上运行，而不管这样做有多困难。

我认为执行此操作的最佳方法是提出可以在所有基础API上实现的功能，并对其进行抽象。如果您正在开发多平台游戏，则不会实现每个API支持的每一个晦涩的功能，而只会实现所需的功能。这也有助于使API保持较小且快速。

为避免将每个不同API的实现的混乱情况打包到输出中，应使用平台无关的头文件和平台特定的代码文件进行编译。然后，特定于目标平台的代码文件将是唯一使API保持较小状态的编译文件。

Emil Persson（Humus）在GPU Pro上有一篇关于此的文章

http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html

用于渲染的跨平台界面。拥有DX9控制台的优势以及我们如何将DX10塞入DX9控制台的通用接口中并保持良好的性能。

您可能想检出SDL库或Allegro。它们都是低级，高度可移植的游戏库，它们可以将它们插入OpenGL上下文中，以便您可以在此处渲染图形。SDL的知名度在于他退出了Loki Games，将一些流行的游戏从2000年代移植到Linux，而Allegro投入了大量的时间，并拥有大量的业余游戏开发者社区。