sla*_*ast 6 c opengl opengl-es
OpenGL ES声称是OpenGL的一个子集,理论上它意味着任何OpenGL ES程序都可以在PC上作为常规OpenGL运行; 但是,似乎OpenGL ES对某些功能(glOrthovs glOrthof)的命名约定略有不同.这有关系吗？OpenGL ES应用程序是否仍可以使用开箱即用的OpenGL GPU /驱动程序或仅重新编译？
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添加了几个新的关键字,特别是精度限定符.桌面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实际上两种情况之间的工作方式相同.现在,互操作更多的是避免两者都无法使用的功能.