On 12/17/05, Lionel Ulmer lionel.ulmer@free.fr wrote:
On Wed, Dec 14, 2005 at 03:53:12AM +0000, Aric Cyr wrote:
So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d everything works fine, but then wined3d is still dependent on glx.
The answer is easy (did not read the complete thread in details to know if you found out the solution or not): basically, 'wglGetProcAddress' returns functions as expected by Win32 applications, so using the 'stdcall' calling convention whereas 'glXGetProcAddress' returns them in the standard Unix calling convention 'cdecl'.
So you basically have the same problem with GL extensions that you had with direct linking to OpenGL32.DLL instead of to libGL.so => all the calls going through function pointers that you retrieved via 'wglGetProcAddress' will go through thunks to change the calling convention (at the price of a slight performance hit).
That's exactly right. That's the conclusion I came to as well. It's all buried in my previous reply somewhere :)
Moreover, you will have a nice 'header' head-ache as you won't be able to rely on the Linux distribution's version of 'glext.h' but on a version compatible with Windows that adds the proper 'STDCALL' types to the function pointer prototypes.
Actually the header 'ache' doesn't hurt so much. The standard (official) glext.h from SGI defines APIENTRY, which we can just define to WINAPI (or __stdcall) before including glext.h. By default, on Linux anyways, APIENTRY is defined as nothing so there shouldn't be any problems. I have this all working already, and managed to get rid of all those horrible copy&paste #defines in wined3d_gl.h and a few other places as well. All-in-all things look a lot cleaner both in dlls/opengl32 and dlls/wined3d. The only catch is to watch out for what should be WINAPI and what should not, but it seems I got it all under control so far. Looking forward to your comments once I start sending the patches in.
Regards, Aric
-- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)