On 12/17/05, Lionel Ulmer <[EMAIL PROTECTED]> 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)
