OpenGL ES 声称是 OpenGL 的子集,这在理论上意味着任何 OpenGL ES 程序都可以在 PC 上像普通的 OpenGL 一样运行;但是,似乎 OpenGL ES 对某些函数(glOrtho
vs glOrthof
)的命名约定略有不同。这有关系吗?OpenGL ES 应用程序是否仍然可以使用开箱即用的 OpenGL GPU/驱动程序或仅重新编译?
2 回答
OpenGL ES 应用程序是否仍然可以使用开箱即用的 OpenGL GPU/驱动程序或仅重新编译?
不。有点,但既然你提出来了glOrtho
,这意味着你在谈论 ES 1.x 而不是 2.x,不是为你准备的。ES 3.0 加入了一些新的东西;详情见底部。
OpenGL ES 1.x 不是任何版本的 OpenGL 的子集。它们是一些非常显着的差异。你可能,也许能够编码到一个共同的子集,但你会扔掉很多东西来做这件事。在两个平台上。
ES 2.x 与桌面 GL 2.1 有更多的相似之处,但它仍然不是一个适当的子集。例如glTexImage2D
具有完全不同的行为。在桌面 GL 下,最后三个参数不影响纹理的实际格式。在 ES 2.0 下,它们定义了纹理的实际图像格式。您可以编写一个有效的glTexImage2D
命令,在 ES 2.0 和桌面 GL 2.1 下执行相同的操作,但是在桌面 GL 下执行此操作会浪费很多东西(例如选择大小合适的内部格式)。
话虽如此,您通常可以使用抽象来封锁 API 差异。使用 ES 2.0 会遇到的大问题是 GLSL。
GLSL ES 添加了几个新关键字,特别是精度限定符。Desktop GLSL 1.20(与 GL 2.1 配对)没有这些关键字。桌面 GLSL 1.30 和更高版本可以,但这些都绑定到 GL 3.0硬件。因此,很难为 ES 2.0 编写一个无需修改即可在桌面 GL 2.1 硬件上运行的着色器。
这当然不是不可克服的。一些明智的#defines,它们本身可以针对不同的语言进行#ifdef,可以使这变得相当简单。但是您仍然必须找到所有这些案例。
最近发布的 OpenGL ES 3.0 也不是 OpenGL 3.3 的真子集,但它比 ES 2.0 更接近。真正重要的是 GLSL 3.30 几乎与 GLSL ES 3.00 相同。因此,您可以更轻松地在两者之间交换着色器。
There are certain limits in ES 3.0 that aren't in 3.3, but generally these are easily avoidable (and using most of them is bad practice anyway). And some of the features of ES 3.0 aren't technically in GL 3.3, but they are in commonly-available core extensions to GL 3.3 (such as ARB_texture_storage, and there's the ES3_compatibility extension to increase compatibility). But it's a lot easier to work with now that glTexImage2D
actually works the same way between the two cases. Now, interop is more a matter of avoiding functionality not available to both.
当前版本的 OpenGL (4.x) 和 OpenGL ES (2.x) 是相似的,尽管存在足够的差异,仅通过重新编译移植代码就无法工作。正如@Nicol Bolas 指出的那样,OpenGL 中有许多功能甚至在 OpenGL ES 中都不存在,而一些 API 的行为略有不同。此外,平台支持非常不同(即设置渲染上下文等)。
OpenGL ES 2.0 实际上并不向后兼容 1.x,因为模型从旧的立即模式样式(如 OpenGL 2.1 和更早版本中所奉行的)更改为更现代的基于着色器的模型。
OpenGL v3 和 v4 弃用了许多不合时宜的 2.x 功能,尽管主要驱动程序保留了兼容模式以继续这种较旧的支持。
OpenGL 4.x 中的GL_ARB_ES2_compatibility 扩展有助于将桌面版和移动版更紧密地结合在一起,以简化可移植性。
glOrtho
像vs这样的细微差别glOrthof
显然很容易管理,但是您需要为其他功能编写包装器。