OpenGL向后兼容OpenGL ES吗?

前端之家收集整理的这篇文章主要介绍了OpenGL向后兼容OpenGL ES吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
OpenGL ES声称是OpenGL的一个子集,理论上它意味着任何OpenGL ES程序都可以在PC上作为常规OpenGL运行;然而,似乎OpenGL ES对某些函数(glOrtho vs glOrthof)的命名约定略有不同.这有关系吗? OpenGL ES应用程序是否仍可以使用开箱即用的OpenGL GPU /驱动程序或仅重新编译?

解决方法

Can an OpenGL ES app still work with an OpenGL GPU/driver out of the Box or with only a recompilation?

不,有点,但既然你提出了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添加了几个新的关键字,特别是精度限定符.桌面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完全相同.因此,您可以更轻松地在两者之间交换着色器.

ES 3.0中存在一些不在3.3中的限制,但通常这些限制很容易避免(并且使用它们中的大多数都是不好的做法).并且ES 3.0的一些功能在技术上不在GL 3.3中,但是它们在GL 3.3的常用核心扩展中(例如ARB_texture_storage,并且有ES3_compatibility扩展以增加兼容性).但是现在glTexImage2D实际上在两种情况下的工作方式相同,因此更容易使用.现在,互操作更多的是避免两者都无法使用的功能.

猜你在找的C&C++相关文章