11

我一直在阅读我的 Visual Studio 版本中包含的 gl.h 头文件，它似乎已经过时了。

我不希望 GLUT 或介于两者之间的任何其他中间件/实用程序库为我做脏活，包括 GLEW。有人可以详细说明为什么以及如何获取/查询 4.0 规范的现代功能集以及 ​​GLEW 背后的总体想法是什么？

4

4 回答 4

15

The gl.h shipping with MSVC++ covers only the functions exported by the opengl32.dll shipping with Windows. This DLL is mostly only a so called "trampoline" into the actual driver. But it only exports a very old version of OpenGL, namely OpenGL-1.1.

Any functionality beyond that must be accessed through the extension mechanism.

I do not want GLUT or any other middleware/utility library in between to do the dirty work for me, that includes GLEW.

GLUT is completely unrelated to GLEW

Could someone elaborate on why and how does one acquire/query for the modern feature set of the 4.0 specification and what's the idea behind GLEW in general?

You aquire the modern feature set through the already mentioned extension system.

There is a function ?glGetProcAddress (exact name depending on the OS environment, in Windows wglGetProcAddress). Using this function you retrieve function pointers to the procedures of extensions for the current OpenGL context (in GLX the function pointers are the same for all contexts, but in Windows they may differ).

Loading a extension goes about this:

typedef (*OGLEXTP_SOMEEXTENSIONFUNCTION)(...)
OGLEXTP_SOMEEXTENSIONFUNCTION oglextp_glSomeExtensionFunction = NULL;
#define glSomeExtensionFunction oglextp_glSomeExtensionFunction;


struct Extensions
{
    bool SomeExtensionFunction;
}

errorcode initGLExtensions(){
    Extensions available;

    GLubyte extensions = glGetStrings(GL_EXTENSIONS);
    parse_extension_string(extensions, available);

    if( available.SomeExtensionFunction ) {
        oglextp_glSomeExtensionFunction = wglGwtProcAddress("glSomeExtensionFunction");
        if( !oglextp_glSomeExtensionFunction )
             return errorcode;
    }
}

And you have to write the bulk code of this for each and every function. Nobody wants to write this. So the developers of GLEW came up with a set of scripts, that fetch the extension specifications from opengl.org and automatically create the whole extension loading and wrap this into a small library, that creates no additional dependencies.

If you want to use higher OpenGL functionality: Use GLEW. Not because it's mandatory, but because it's the most straightforward way to go about this.

于 2012-05-20T08:50:01.143 回答
3

Don't be afraid of GLEW. First, I've actually seen GLEW used in Nvidia OpenGL SDK examples. It's obviously a reliable tool with a friendly license. Second, you can statically link the library and vaporize it as a dependency. (Personally, I just add the source code to my project and #define GLEW_STATIC to make it work.)

于 2012-05-20T04:59:15.247 回答
0

您想访问 OpenGL 4.0 扩展对吗？您可能需要创建一个 OpenGL 4.0 上下文并要求 GLEW 绑定相应的函数。

这是从我的项目中复制的 GLEW 和 GLFW 示例。

  ...

  if (!glfwInit()) {
    exit(EXIT_FAILURE);
  }

  glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 2);   // I requested OpenGL 2.1 context
  glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 1);

  if(!glfwOpenWindow(640, 480, 8, 8, 8, 0, 24, 0, GLFW_WINDOW)) {  // get OpenGL context
    glfwTerminate();
    exit(EXIT_FAILURE);
  }

  if (glewInit() != GLEW_OK) {   // init glew, and bind gl* Extension functions
    glfwTerminate();
    exit(EXIT_FAILURE);
  }

  // now gl* extensions is available here

  ....
于 2012-05-20T03:38:33.970 回答
-1

GLee is another library for loading OpenGL extensions, and it's pretty straightforward and easy to understand the source code (the code generator is a different story). So you can see how loading extension functions works.

Do use the SVN trunk, not the "released" version, since I worked with the author to add support for the OpenGL 4.x extensions.

What I like about GLee is that it only loads the extensions you use, in contrast to GLEW which loads 200+ different extensions, which slows down program startup and especially slows down OpenGL profiling.

于 2012-05-20T03:47:03.500 回答