glewInit() 和客户端程序中GLEW_ARB_xxx_失败

glewInit() and GLEW_ARB_xxx_ failure in client program

本文关键字:GLEW ARB xxx 失败 程序 客户端 glewInit      更新时间:2023-10-16

我写了一个DLL,它使用glew初始化OpenGL上下文。首先,我创建了一个虚拟窗口来创建适当的上下文。其次,创建最终上下文和窗口。 glewInit()函数调用成功,并且某些布尔变量(例如 GLEW_ARB_texture_storage(设置为 1(我有一个与 opengl 3.3 兼容的视频适配器(。

请注意,

glewExperimental=GL_TRUE 

虽然。

但是,当我使用上面的 DLL 编写客户端程序时,相同的GLEW_ARB_texture_storage变量等于 GL_FALSE

因此,我想知道glewInit()最终应该叫什么?似乎从 DLL 调用它是不够的。我也应该从客户端程序端调用它吗?

我实际上不会从您的虚拟上下文中初始化 GLEW。考虑手动加载手动创建最终上下文所需的一两个扩展(例如 WGL_ARB_create_contextWGL_ARB_pixel_format(。当您创建两个不同的上下文时,不能保证在 Windows 上获得相同的 ICD 实现。这就是创建GLEW MX的原因。

现在,我怀疑在您的案例中发生的实际上并不是您获得了两个不同的 ICD(这在现实世界中极为罕见(,而是实际上您创建的第一个上下文是兼容性配置文件,第二个是核心配置文件。

GLEW 使用扩展字符串初始化变量,例如GLEW_ARB_texture_storage,但在核心配置文件中,GLEW 不够智能,无法以正确的方式解析该字符串(多次调用 glGetStringi (...) (。这就是为什么你必须使用 GLEW_EXPERIMENTAL .

GLEW_EXPERIMNETAL告诉 GLEW 尝试加载它知道的每个扩展的每个函数指针,而无需先解析任何扩展字符串来检查可用性。这在核心配置文件中是必要的,但在兼容性中则不然(因为旧的扩展字符串机制在兼容性方面仍然有效(。GLEW 中依赖于解析扩展字符串的任何部分都无法在核心配置文件中正常工作。

我写了一个DLL,它使用glew初始化OpenGL上下文

这不是GLEW所做的。GLEW不初始化OpenGL上下文,GLEW加载OpenGL扩展函数地址并用它们初始化函数指针。您必须使用正在创建的预先存在的 OpenGL 上下文来调用 GLEW,并在线程调用glewInit()中使其处于当前状态。

您的程序在某处创建了一个OpenGL上下文,然后显然调用glewInit()。从您描述它的方式来看,您的 DLL 可能只是通过 DllMain 条目函数调用glewInit(),该函数在加载 DLL 时被调用,这通常是在调用进程WinMain或/main 函数之前,因此尚未创建 OpenGL 上下文。当然,您可以在DLL中创建OpenGL上下文,但您必须问自己,这对DLL的用户是否有意义。