我一直在尝试编写一些适用于所有地方的opengl代码，但不会过多限制自己。
我想在仅支持它的设备上使用opengles2，并在支持的情况下使用opengl核心。
另外，我希望能够在运行时选择我使用的那个（当然，如果可用的话）。
我的问题是：
如果我每次将代码与OpenGL库链接，然后创建GLES2或GL核心上下文，GLES2上下文的行为是否与GLESv2库完全相同？这会是什么影响，标题明智？
例如，GLESv2没有定义BGRA纹理格式，所以我想我必须将所有格式转换为RGBA。这不是什么麻烦，但我对了解替代品感兴趣。
我已经想过动态加载库并加载所有使用过的函数指针，但这对于可能有更简单答案的事情来说是一项巨大的工作。 在这种情况下，我只需要包含glext.h，并声明所用函数的所有函数指针，并填充它们。 这里的问题是glext没有定义任何数据类型（glenum等），所以我总是要包含gl.h. 通过包含两者，我得到gl.h函数声明和我自己的函数指针声明，所以我不能只使用函数指针的通用命名空间......即使这样，一些函数（如glGetError）也不会似乎有一个关联的typedef作为他们的函数指针。
我知道GLEW，但不幸的是，大多数Linux发行版都发布了一个仍然不兼容GLES2的GLEW版本（debian，我正在看着你）。它只是段错误。
你们会怎么做？ opengl函数链接的其他方法是什么？
答案 0 :(得分：1)
我在航空航天工业，我开始使用各种OpenGL子集，因为每个硬件提供商都有自己的版本。 （我希望能够完整记录......好吧......任何东西。）看来我们确实有类似的问题。我会告诉你到目前为止我学到的东西。
首先，您需要向所有配置文件中最大的最佳超集发展。使用硬件供应商提供的最新版本的OpenGL标头。这样你的程序至少可以解决编译部分。
BGRA macro / enum将成为您的GLESv2运行时的一部分，但如果您的平台仅支持RGBA，您肯定永远不会在运行时使用它。
基于平台功能的运行时决策基于OpenGL扩展列表。将扩展列表与应用程序使用的任何内容进行比较，停用不支持的分支并激活支持的分支。您可以通过这种方式区分OpenGL和GLES。