http://bugs.winehq.org/show_bug.cgi?id=5310
------- Additional Comments From the3dfxdude@gmail.com 2006-14-11 15:18 ------- Sorry about that. So what I am to understand is the GLIntercept program works by overriding opengl32. So you need gdi32 to call opengl32 for the interception to work, because your app calls the gdi32 version of the functions.
According to OpenGL faq on windows http://www.opengl.org/resources/faq/technical/mswindows.htm "5.190 What do I need to know about mixing WGL and GDI calls?
On the Win32 platform a number of platform specific function calls are duplicated in the OpenGL ICD mechanism and the GDI. This may cause confusion as they appear to be functionally identical, the only difference being whether wgl precedes the rest of the function name. To ensure correct operation of OpenGL use ChoosePixelformat, DescribePixelformat, GetPixelformat, SetPixelformat, and SwapBuffers, instead of the wgl equivalents, wglChoosePixelformat, wglDescribePixelformat, wglGetPixelformat, wglSetPixelformat, and wglSwapBuffers. In all other cases use the wgl function where available. Using the five wgl functions is only of interest to developers run-time linking to an OpenGL driver. Not using the functions as described may result in a black OpenGL window, or a correctly functioning application in Windows 9x that produces a black OpenGL window on Windows NT/2000."
Their recommendation is to have an app use the gdi version of the opengl functions to make sure it will always work properly. This might go as well for the the GLIntercept program (I only see wgl* in the source code btw). This dependence on wgl by the program might be a design mistake?
What's worse is that the current goal for wgl is to make it routed through gdi. I don't think this problem will be fixed for you. I think you will need to override gdi itself, or write a new tool. Although you could just fork wine's gdi to provide the functionality you want.
-
Wine Bugs