[wined3d] Converting Wined3d to use WGL instead of GLX
aric.cyr at gmail.com
Sat Dec 17 06:57:06 CST 2005
On 12/17/05, Lionel Ulmer <lionel.ulmer at 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.
Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)
More information about the wine-devel