为什么glewInit（）在对glfwWindowHint（）进行一些调用后会产生GL

为什么glewInit（）在对glfwWindowHint（）进行一些调用后会产生GL_INVALID_ENUM(Why does glewInit() result in GL_INVALID_ENUM after making some calls to glfwWindowHint())

出于某种原因，当我调用glfwWindowHint（）时：

glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);

然后拨打电话：

glewInit()

我最终得到一个glError：GL_INVALID_ENUM。 当我省略所有glfwWindowHint（）调用时，一切正常，并且没有设置glError。 我错误地使用这些库，或者这是glfw中的错误还是glew？

请注意，我使用的是glew-1.10.0和glfw-3.0.3

这是一个简单的程序来说明我看到的问题：

#include <iostream> #include "GL/glew.h" #include "GLFW/glfw3.h" int main(char* argc, char* argv[]) { GLFWwindow* window; if (!glfwInit()) { return -1; } glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); window = glfwCreateWindow(800, 600, "Hello World", NULL, NULL); if (!window) { glfwTerminate(); return -1; } glfwMakeContextCurrent(window); //glewExperimental = GL_TRUE; tried commenting this out but I still get the error if(glewInit() != GLEW_OK) { return -1; } switch(glGetError()) { case GL_INVALID_ENUM: std::cout << "why is this happening?"; } }

For some reason when I call glfwWindowHint():

glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);

and later make a call to:

glewInit()

I end up getting a glError: GL_INVALID_ENUM. When I leave out all of the glfwWindowHint() calls everything works fine and no glError is set. Am I using these libraries incorrectly, or if this is a bug in glfw, or glew?

Note that I'm using glew-1.10.0 and glfw-3.0.3

Here's a simple program to illustrate the issue I'm seeing:

#include <iostream> #include "GL/glew.h" #include "GLFW/glfw3.h" int main(char* argc, char* argv[]) { GLFWwindow* window; if (!glfwInit()) { return -1; } glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); window = glfwCreateWindow(800, 600, "Hello World", NULL, NULL); if (!window) { glfwTerminate(); return -1; } glfwMakeContextCurrent(window); //glewExperimental = GL_TRUE; tried commenting this out but I still get the error if(glewInit() != GLEW_OK) { return -1; } switch(glGetError()) { case GL_INVALID_ENUM: std::cout << "why is this happening?"; } }

最满意答案

因为在核心配置文件上下文中，使用glGetString (...)查询扩展字符串是无效的。 您必须使用glGetStringi (...)并逐个查询每个扩展。 坦率地说，这是一个糟糕的设计，因为glGetStringi必须通过大多数平台上的扩展加载机制加载。 这是鸡和鸡蛋的情况，核心配置文件中的正确行为肯定是在初始化之前使用glewExperimental = TRUE并忽略glewInit (...)之后的无效枚举错误。

我应该指出，这不是你做错了。 这是一个问题，如何在幕后实施GLEW，以及OpenGL ARB的一个有些可疑的决定。 我会将GL_EXTENSIONS为使用glGetString (...)查询的有效内容，但定义了一些特殊字符串（例如“GL_CORE_PROFILE”）以在核心配置文件中返回。 然后每个人都以我看到的方式获胜。

顺便说一句，major.minor 3.3的glfwWindowHint不会导致出现此问题。 实际上你使用的是GLFW_OPENGL_CORE_PROFILE 。 核心配置文件仅对OpenGL 3.2+有效，因此这个问题只能通过major.minor≥3.2 和 core的组合来表现出来。

Because in a core profile context, it is invalid to query the extension string using glGetString (...). You have to use glGetStringi (...) and query each extension one-by-one. Frankly this is terrible design, since glGetStringi has to be loaded through the extension loading mechanism on most platforms. It is a chicken and egg sort of situation, the proper behavior in a core profile is definitely to use glewExperimental = TRUE before initialization and ignore an invalid enum error immediately following glewInit (...).

I should point out that this is nothing that you are doing wrong. It is a problem with how GLEW is implemented behind the scenes and a somewhat questionable decision by the OpenGL ARB. I would have left GL_EXTENSIONS a valid thing to query with glGetString (...) but defined some special string (e.g. "GL_CORE_PROFILE") to return in a core profile. Everybody wins then, the way I see it.

Incidentally, it is not theglfwWindowHint for major.minor 3.3 that causes this issue to show up. It is actually your use of GLFW_OPENGL_CORE_PROFILE. Core profiles are only valid for OpenGL 3.2+, so this issue will only manifest itself with a combination of major.minor ≥ 3.2 and core.