Alexandre, please do NOT commit this... The separation of GL calls from DDraw will be part of the D3D core work and not via the usage of funtion pointers. Basically, we will have a d3dcore library linked to OpenGL and if DDraw fails to load it (for example if GL is not present on the system), DDraw will not support D3D. Mike, next time ask on IRC before doing a big patch like this on DDraw / D3D (or ask on the wine-d3d mailing list, it will add to its activity :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Hi Lionel, How long is it going to be before d3dcore is a reality? I think it is a good idea, but I'd like to have dlopen functionality sooner rather than later. Additionally, I don't see how my patch is a step backwards... Mike btw. I had no idea a wine-d3d list even exists. Lionel Ulmer wrote:
Alexandre, please do NOT commit this...
The separation of GL calls from DDraw will be part of the D3D core work and not via the usage of funtion pointers. Basically, we will have a d3dcore library linked to OpenGL and if DDraw fails to load it (for example if GL is not present on the system), DDraw will not support D3D.
Mike, next time ask on IRC before doing a big patch like this on DDraw / D3D (or ask on the wine-d3d mailing list, it will add to its activity :-) ).
Lionel
How long is it going to be before d3dcore is a reality?
Well, this is the problem. The work on it is barely starting for D3D8 and after we will need to rewrite D3D7 based on this common core (at the same time doing regressions, porting the D3D7 code missing over, ...). So it's not something that it's likely to be in Wine before at least 2 months (we are currently too busy adding features to get finally games working to work on this :-) ).
I think it is a good idea, but I'd like to have dlopen functionality sooner rather than later. Additionally, I don't see how my patch is a step backwards...
Well, I mostly only looked at the first one (did not see until later the second one) and I saw a huge patch changing a lot of our code (i.e. all the GL calls) - all this for something we would plan to throw away sometime in the future (not to mention a patch that would have added a LOT of conflicts to my own Wine tree :-) ). Now the second patch is a bit better (as it changes a lot less files) but may still have a (minimal I think) performance penalty due to the indirect calling of all the GL functions. And for the patch to be comitted : - no 'diff -u' please, it kills indentation in all the code where you added the 'if (opengl_initialized)' tests - configure creates a 'SONAME_LIBGL' for you (instead of hard-coding to libGL.so). - what is this 'WINE_MESSAGE' stuff ? Why not use the 'ddraw' channel ?
btw. I had no idea a wine-d3d list even exists.
Sorry for that, I mixed you up with another Mike (who should have known about this list :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Thu, 15 May 2003, Lionel Ulmer wrote:
- no 'diff -u' please, it kills indentation in all the code where you added the 'if (opengl_initialized)' tests
Eh? I hope you mean 'diff -w', there's nothing wrong with -u...
- what is this 'WINE_MESSAGE' stuff ? Why not use the 'ddraw' channel ?
Yeah, I have to second that. -- Dimi.
- no 'diff -u' please, it kills indentation in all the code where you added the 'if (opengl_initialized)' tests
Eh? I hope you mean 'diff -w', there's nothing wrong with -u...
Yeah, I meant '-w' of course :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Hi Lionel, Lionel Ulmer wrote:
So it's not something that it's likely to be in Wine before at least 2 months (we are currently too busy adding features to get finally games working to work on this :-) ).
Well, I have time, and I can work on that if you let me know what to do. For example, where do you want to put the library in the wine tree?
And for the patch to be comitted :
- no 'diff -u' please, it kills indentation in all the code where you added the 'if (opengl_initialized)' tests - configure creates a 'SONAME_LIBGL' for you (instead of hard-coding to libGL.so). - what is this 'WINE_MESSAGE' stuff ? Why not use the 'ddraw' channel ?
OK, how does this one look? Mike ? dlls/ddraw/ddraw_opengl.diff ? dlls/ddraw/ddraw_opengl3.diff ? dlls/ddraw/gl_private.h Index: dlls/ddraw/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/ddraw/Makefile.in,v retrieving revision 1.28 diff -u -r1.28 Makefile.in --- dlls/ddraw/Makefile.in 21 Nov 2002 21:04:16 -0000 1.28 +++ dlls/ddraw/Makefile.in 16 May 2003 04:33:43 -0000 @@ -5,7 +5,7 @@ MODULE = ddraw.dll IMPORTS = user32 gdi32 kernel32 EXTRAINCL = @X_CFLAGS@ -EXTRALIBS = $(LIBUUID) @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@ @OPENGL_LIBS@ +EXTRALIBS = $(LIBUUID) @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@ LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: dlls/ddraw/ddraw_private.h =================================================================== RCS file: /home/wine/wine/dlls/ddraw/ddraw_private.h,v retrieving revision 1.35 diff -u -r1.35 ddraw_private.h --- dlls/ddraw/ddraw_private.h 2 Jan 2003 19:51:25 -0000 1.35 +++ dlls/ddraw/ddraw_private.h 16 May 2003 04:33:44 -0000 @@ -353,6 +353,7 @@ extern Convert ModeEmulations[8]; extern int _common_depth_to_pixelformat(DWORD depth,LPDIRECTDRAW ddraw); +extern BOOL opengl_initialized; /****************************************************************************** * Structure conversion (for thunks) Index: dlls/ddraw/main.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/main.c,v retrieving revision 1.31 diff -u -r1.31 main.c --- dlls/ddraw/main.c 15 Mar 2003 00:12:43 -0000 1.31 +++ dlls/ddraw/main.c 16 May 2003 04:33:44 -0000 @@ -37,6 +37,11 @@ /* This for all the enumeration and creation of D3D-related objects */ #include "ddraw_private.h" #include "wine/debug.h" +#include "wine/library.h" +#include "wine/port.h" + +#define GLPRIVATE_NO_REDEFINE +#include "gl_private.h" #define MAX_DDRAW_DRIVERS 3 static const ddraw_driver* DDRAW_drivers[MAX_DDRAW_DRIVERS]; @@ -55,6 +60,185 @@ LPVOID lpContext; } DirectDrawEnumerateProcData; +#ifdef HAVE_OPENGL + +static void *gl_handle = NULL; +BOOL opengl_initialized = 0; + +#define MAKE_FUNCPTR(f) typeof(f) * p##f = NULL; + +MAKE_FUNCPTR(glAlphaFunc) +MAKE_FUNCPTR(glBegin) +MAKE_FUNCPTR(glBindTexture) +MAKE_FUNCPTR(glBlendFunc) +MAKE_FUNCPTR(glClear) +MAKE_FUNCPTR(glClearColor) +MAKE_FUNCPTR(glClearDepth) +MAKE_FUNCPTR(glClearStencil) +MAKE_FUNCPTR(glClipPlane) +MAKE_FUNCPTR(glColor3f) +MAKE_FUNCPTR(glColor3ub) +MAKE_FUNCPTR(glColor4ub) +MAKE_FUNCPTR(glColorMaterial) +MAKE_FUNCPTR(glCullFace) +MAKE_FUNCPTR(glDeleteTextures) +MAKE_FUNCPTR(glDepthFunc) +MAKE_FUNCPTR(glDepthMask) +MAKE_FUNCPTR(glDisable) +MAKE_FUNCPTR(glDrawBuffer) +MAKE_FUNCPTR(glDrawPixels) +MAKE_FUNCPTR(glEnable) +MAKE_FUNCPTR(glEnd) +MAKE_FUNCPTR(glFlush) +MAKE_FUNCPTR(glFogf) +MAKE_FUNCPTR(glFogfv) +MAKE_FUNCPTR(glFogi) +MAKE_FUNCPTR(glFrontFace) +MAKE_FUNCPTR(glGenTextures) +MAKE_FUNCPTR(glGetBooleanv) +MAKE_FUNCPTR(glGetFloatv) +MAKE_FUNCPTR(glGetIntegerv) +MAKE_FUNCPTR(glHint) +MAKE_FUNCPTR(glLightModelfv) +MAKE_FUNCPTR(glLightModeli) +MAKE_FUNCPTR(glLightfv) +MAKE_FUNCPTR(glLoadIdentity) +MAKE_FUNCPTR(glLoadMatrixf) +MAKE_FUNCPTR(glMaterialf) +MAKE_FUNCPTR(glMaterialfv) +MAKE_FUNCPTR(glMatrixMode) +MAKE_FUNCPTR(glMultMatrixf) +MAKE_FUNCPTR(glNormal3f) +MAKE_FUNCPTR(glNormal3fv) +MAKE_FUNCPTR(glPolygonMode) +MAKE_FUNCPTR(glPolygonOffset) +MAKE_FUNCPTR(glPopMatrix) +MAKE_FUNCPTR(glPushMatrix) +MAKE_FUNCPTR(glRasterPos2f) +MAKE_FUNCPTR(glReadBuffer) +MAKE_FUNCPTR(glReadPixels) +MAKE_FUNCPTR(glShadeModel) +MAKE_FUNCPTR(glStencilFunc) +MAKE_FUNCPTR(glStencilMask) +MAKE_FUNCPTR(glStencilOp) +MAKE_FUNCPTR(glTexCoord2f) +MAKE_FUNCPTR(glTexCoord2fv) +MAKE_FUNCPTR(glTexEnvi) +MAKE_FUNCPTR(glTexImage2D) +MAKE_FUNCPTR(glTexParameteri) +MAKE_FUNCPTR(glTexParameterfv) +MAKE_FUNCPTR(glTexSubImage2D) +MAKE_FUNCPTR(glTranslatef) +MAKE_FUNCPTR(glVertex3f) +MAKE_FUNCPTR(glVertex3fv) +MAKE_FUNCPTR(glVertex4f) +MAKE_FUNCPTR(glXCreateContext) +MAKE_FUNCPTR(glXDestroyContext) +MAKE_FUNCPTR(glXMakeCurrent) +MAKE_FUNCPTR(glXSwapBuffers) + +#undef MAKE_FUNCPTR + +static BOOL DDRAW_bind_to_opengl( void ) +{ + char *glname = SONAME_LIBGL; + + gl_handle = wine_dlopen(glname, RTLD_NOW, NULL, 0); + if(!gl_handle) { + ERR("Wine cannot find the OpenGL graphics library (%s).\n",glname); + return FALSE; + } + +#define LOAD_FUNCPTR(f) \ + if((p##f = wine_dlsym(gl_handle, #f, NULL, 0)) == NULL) \ + { \ + WARN("Can't find symbol %s\n", #f); \ + goto sym_not_found; \ + } + + LOAD_FUNCPTR(glAlphaFunc) + LOAD_FUNCPTR(glBegin) + LOAD_FUNCPTR(glBindTexture) + LOAD_FUNCPTR(glBlendFunc) + LOAD_FUNCPTR(glClear) + LOAD_FUNCPTR(glClearColor) + LOAD_FUNCPTR(glClearDepth) + LOAD_FUNCPTR(glClearStencil) + LOAD_FUNCPTR(glClipPlane) + LOAD_FUNCPTR(glColor3f) + LOAD_FUNCPTR(glColor3ub) + LOAD_FUNCPTR(glColor4ub) + LOAD_FUNCPTR(glColorMaterial) + LOAD_FUNCPTR(glCullFace) + LOAD_FUNCPTR(glDeleteTextures) + LOAD_FUNCPTR(glDepthFunc) + LOAD_FUNCPTR(glDepthMask) + LOAD_FUNCPTR(glDisable) + LOAD_FUNCPTR(glDrawBuffer) + LOAD_FUNCPTR(glDrawPixels) + LOAD_FUNCPTR(glEnable) + LOAD_FUNCPTR(glEnd) + LOAD_FUNCPTR(glFlush) + LOAD_FUNCPTR(glFogf) + LOAD_FUNCPTR(glFogfv) + LOAD_FUNCPTR(glFogi) + LOAD_FUNCPTR(glFrontFace) + LOAD_FUNCPTR(glGenTextures) + LOAD_FUNCPTR(glGetBooleanv) + LOAD_FUNCPTR(glGetFloatv) + LOAD_FUNCPTR(glGetIntegerv) + LOAD_FUNCPTR(glHint) + LOAD_FUNCPTR(glLightModelfv) + LOAD_FUNCPTR(glLightModeli) + LOAD_FUNCPTR(glLightfv) + LOAD_FUNCPTR(glLoadIdentity) + LOAD_FUNCPTR(glLoadMatrixf) + LOAD_FUNCPTR(glMaterialf) + LOAD_FUNCPTR(glMaterialfv) + LOAD_FUNCPTR(glMatrixMode) + LOAD_FUNCPTR(glMultMatrixf) + LOAD_FUNCPTR(glNormal3f) + LOAD_FUNCPTR(glNormal3fv) + LOAD_FUNCPTR(glPolygonMode) + LOAD_FUNCPTR(glPolygonOffset) + LOAD_FUNCPTR(glPopMatrix) + LOAD_FUNCPTR(glPushMatrix) + LOAD_FUNCPTR(glRasterPos2f) + LOAD_FUNCPTR(glReadBuffer) + LOAD_FUNCPTR(glReadPixels) + LOAD_FUNCPTR(glShadeModel) + LOAD_FUNCPTR(glStencilFunc) + LOAD_FUNCPTR(glStencilMask) + LOAD_FUNCPTR(glStencilOp) + LOAD_FUNCPTR(glTexCoord2f) + LOAD_FUNCPTR(glTexCoord2fv) + LOAD_FUNCPTR(glTexEnvi) + LOAD_FUNCPTR(glTexImage2D) + LOAD_FUNCPTR(glTexParameteri) + LOAD_FUNCPTR(glTexSubImage2D) + LOAD_FUNCPTR(glTranslatef) + LOAD_FUNCPTR(glVertex3f) + LOAD_FUNCPTR(glVertex3fv) + LOAD_FUNCPTR(glVertex4f) + LOAD_FUNCPTR(glXCreateContext) + LOAD_FUNCPTR(glXDestroyContext) + LOAD_FUNCPTR(glXMakeCurrent) + LOAD_FUNCPTR(glXSwapBuffers) +#undef LOAD_FUNCPTR + + return TRUE; + +sym_not_found: + ERR("Wine cannot find certain functions that it needs inside the OpenGL\n" + "graphics library. To enable Wine to use OpenGL please upgrade\n" + "your OpenGL libraries\n"); + wine_dlclose(gl_handle, NULL, 0); + gl_handle = NULL; + return FALSE; +} + +#endif /* HAVE_OPENGL */ + /*********************************************************************** * DirectDrawEnumerateExA (DDRAW.@) */ @@ -531,6 +715,9 @@ wine_tsx11_lock_ptr = (void *)GetProcAddress( mod, "wine_tsx11_lock" ); wine_tsx11_unlock_ptr = (void *)GetProcAddress( mod, "wine_tsx11_unlock" ); } +#ifdef HAVE_OPENGL + opengl_initialized = DDRAW_bind_to_opengl(); +#endif /* HAVE_OPENGL */ } if (DDRAW_num_drivers > 0) Index: dlls/ddraw/mesa_private.h =================================================================== RCS file: /home/wine/wine/dlls/ddraw/mesa_private.h,v retrieving revision 1.42 diff -u -r1.42 mesa_private.h --- dlls/ddraw/mesa_private.h 12 May 2003 03:09:17 -0000 1.42 +++ dlls/ddraw/mesa_private.h 16 May 2003 04:33:44 -0000 @@ -26,26 +26,7 @@ #ifdef HAVE_OPENGL -#undef APIENTRY -#undef CALLBACK -#undef WINAPI - -#define XMD_H /* This is to prevent the Xmd.h inclusion bug :-/ */ -#include <GL/gl.h> -#include <GL/glx.h> -#ifdef HAVE_GL_GLEXT_H -# include <GL/glext.h> -#endif -#undef XMD_H - -#undef APIENTRY -#undef CALLBACK -#undef WINAPI - -/* Redefines the constants */ -#define CALLBACK __stdcall -#define WINAPI __stdcall -#define APIENTRY WINAPI +#include "gl_private.h" /* X11 locking */ Index: dlls/ddraw/ddraw/hal.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/ddraw/hal.c,v retrieving revision 1.9 diff -u -r1.9 hal.c --- dlls/ddraw/ddraw/hal.c 13 Jan 2003 18:30:47 -0000 1.9 +++ dlls/ddraw/ddraw/hal.c 16 May 2003 04:33:45 -0000 @@ -139,8 +139,10 @@ } #ifdef HAVE_OPENGL - if (d3d_hal_data.hwCaps.dwFlags & D3DDD_WINE_OPENGL_DEVICE) { - /*GL_DirectDraw_Init(&dd_gbl);*/ + if( opengl_initialized ) { + if (d3d_hal_data.hwCaps.dwFlags & D3DDD_WINE_OPENGL_DEVICE) { + /*GL_DirectDraw_Init(&dd_gbl);*/ + } } #endif Index: dlls/ddraw/ddraw/main.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/ddraw/main.c,v retrieving revision 1.40 diff -u -r1.40 main.c --- dlls/ddraw/ddraw/main.c 11 May 2003 03:46:53 -0000 1.40 +++ dlls/ddraw/ddraw/main.c 16 May 2003 04:33:45 -0000 @@ -179,10 +179,11 @@ *obj = ICOM_INTERFACE(This, IDirectDraw4); } #ifdef HAVE_OPENGL - else if ( IsEqualGUID( &IID_IDirect3D , refiid ) || + else if ( opengl_initialized && + ( IsEqualGUID( &IID_IDirect3D , refiid ) || IsEqualGUID( &IID_IDirect3D2 , refiid ) || IsEqualGUID( &IID_IDirect3D3 , refiid ) || - IsEqualGUID( &IID_IDirect3D7 , refiid ) ) + IsEqualGUID( &IID_IDirect3D7 , refiid ) ) ) { IDirect3DImpl *d3d_impl; HRESULT ret_value; Index: dlls/ddraw/ddraw/user.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/ddraw/user.c,v retrieving revision 1.15 diff -u -r1.15 user.c --- dlls/ddraw/ddraw/user.c 7 Mar 2003 20:34:34 -0000 1.15 +++ dlls/ddraw/ddraw/user.c 16 May 2003 04:33:46 -0000 @@ -174,8 +174,11 @@ | DDFXCAPS_BLTSTRETCHY | DDFXCAPS_BLTSTRETCHYN) This->caps.dwCaps |= DDCAPS_GDI | DDCAPS_PALETTE | BLIT_CAPS; #ifdef HAVE_OPENGL - /* Hack for D3D code */ - This->caps.dwCaps |= DDCAPS_3D; + if( opengl_initialized ) + { + /* Hack for D3D code */ + This->caps.dwCaps |= DDCAPS_3D; + } #endif /* HAVE_OPENGL */ This->caps.dwCaps2 |= DDCAPS2_CERTIFIED | DDCAPS2_NOPAGELOCKREQUIRED | DDCAPS2_PRIMARYGAMMA | DDCAPS2_WIDESURFACES; @@ -199,8 +202,11 @@ DDSCAPS_PRIMARYSURFACE | DDSCAPS_SYSTEMMEMORY | DDSCAPS_VIDEOMEMORY | DDSCAPS_VISIBLE; #ifdef HAVE_OPENGL - /* Hacks for D3D code */ - This->caps.ddsCaps.dwCaps |= DDSCAPS_3DDEVICE | DDSCAPS_MIPMAP | DDSCAPS_TEXTURE | DDSCAPS_ZBUFFER; + if( opengl_initialized ) + { + /* Hacks for D3D code */ + This->caps.ddsCaps.dwCaps |= DDSCAPS_3DDEVICE | DDSCAPS_MIPMAP | DDSCAPS_TEXTURE | DDSCAPS_ZBUFFER; + } #endif /* HAVE_OPENGL */ This->caps.ddsOldCaps.dwCaps = This->caps.ddsCaps.dwCaps; Index: dlls/ddraw/dsurface/main.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/dsurface/main.c,v retrieving revision 1.46 diff -u -r1.46 main.c --- dlls/ddraw/dsurface/main.c 15 Mar 2003 01:11:14 -0000 1.46 +++ dlls/ddraw/dsurface/main.c 16 May 2003 04:33:46 -0000 @@ -179,48 +179,51 @@ return S_OK; } #ifdef HAVE_OPENGL - else if ( IsEqualGUID( &IID_D3DDEVICE_OpenGL, riid ) || - IsEqualGUID( &IID_IDirect3DHALDevice, riid) ) + else if( opengl_initialized ) { - IDirect3DDeviceImpl *d3ddevimpl; - HRESULT ret_value; + if ( IsEqualGUID( &IID_D3DDEVICE_OpenGL, riid ) || + IsEqualGUID( &IID_IDirect3DHALDevice, riid) ) + { + IDirect3DDeviceImpl *d3ddevimpl; + HRESULT ret_value; - ret_value = d3ddevice_create(&d3ddevimpl, This->ddraw_owner->d3d, This); - if (FAILED(ret_value)) return ret_value; + ret_value = d3ddevice_create(&d3ddevimpl, This->ddraw_owner->d3d, This); + if (FAILED(ret_value)) return ret_value; - *ppObj = ICOM_INTERFACE(d3ddevimpl, IDirect3DDevice); - TRACE(" returning Direct3DDevice interface at %p.\n", *ppObj); + *ppObj = ICOM_INTERFACE(d3ddevimpl, IDirect3DDevice); + TRACE(" returning Direct3DDevice interface at %p.\n", *ppObj); - This->ref++; /* No idea if this is correct.. Need to check using real Windows */ - return ret_value; - } - else if (IsEqualGUID( &IID_IDirect3DTexture, riid ) || - IsEqualGUID( &IID_IDirect3DTexture2, riid )) - { - HRESULT ret_value = S_OK; + This->ref++; /* No idea if this is correct.. Need to check using real Windows */ + return ret_value; + } + else if (IsEqualGUID( &IID_IDirect3DTexture, riid ) || + IsEqualGUID( &IID_IDirect3DTexture2, riid )) + { + HRESULT ret_value = S_OK; - if ((This->surface_desc.ddsCaps.dwCaps & DDSCAPS_TEXTURE) == 0) return E_NOINTERFACE; + if ((This->surface_desc.ddsCaps.dwCaps & DDSCAPS_TEXTURE) == 0) return E_NOINTERFACE; - /* In case the texture surface was created before the D3D creation */ - if (This->tex_private == NULL) { - if (This->ddraw_owner->d3d == NULL) { - ERR("Texture created with no D3D object yet.. Not supported !\n"); - return E_NOINTERFACE; - } + /* In case the texture surface was created before the D3D creation */ + if (This->tex_private == NULL) { + if (This->ddraw_owner->d3d == NULL) { + ERR("Texture created with no D3D object yet.. Not supported !\n"); + return E_NOINTERFACE; + } - ret_value = This->ddraw_owner->d3d->create_texture(This->ddraw_owner->d3d, This, FALSE, This->mip_main); - if (FAILED(ret_value)) return ret_value; - } - if (IsEqualGUID( &IID_IDirect3DTexture, riid )) { - *ppObj = ICOM_INTERFACE(This, IDirect3DTexture); - TRACE(" returning Direct3DTexture interface at %p.\n", *ppObj); - } else { - *ppObj = ICOM_INTERFACE(This, IDirect3DTexture2); - TRACE(" returning Direct3DTexture2 interface at %p.\n", *ppObj); - } - This->ref++; - return ret_value; - } + ret_value = This->ddraw_owner->d3d->create_texture(This->ddraw_owner->d3d, This, FALSE, This->mip_main); + if (FAILED(ret_value)) return ret_value; + } + if (IsEqualGUID( &IID_IDirect3DTexture, riid )) { + *ppObj = ICOM_INTERFACE(This, IDirect3DTexture); + TRACE(" returning Direct3DTexture interface at %p.\n", *ppObj); + } else { + *ppObj = ICOM_INTERFACE(This, IDirect3DTexture2); + TRACE(" returning Direct3DTexture2 interface at %p.\n", *ppObj); + } + This->ref++; + return ret_value; + } + } #endif return E_NOINTERFACE; --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/ddraw/gl_private.h 2003-05-15 14:12:26.000000000 +0900 @@ -0,0 +1,178 @@ + +#ifndef __GRAPHICS_WINE_GL_PRIVATE_H +#define __GRAPHICS_WINE_GL_PRIVATE_H + +#ifdef HAVE_OPENGL + +#undef APIENTRY +#undef CALLBACK +#undef WINAPI + +#define XMD_H /* This is to prevent the Xmd.h inclusion bug :-/ */ +#include <GL/gl.h> +#include <GL/glx.h> +#ifdef HAVE_GL_GLEXT_H +# include <GL/glext.h> +#endif +#undef XMD_H + +#undef APIENTRY +#undef CALLBACK +#undef WINAPI + +/* Redefines the constants */ +#define CALLBACK __stdcall +#define WINAPI __stdcall +#define APIENTRY WINAPI + +#define MAKE_FUNCPTR(f) extern typeof(f) * p##f; + +MAKE_FUNCPTR(glAlphaFunc) +MAKE_FUNCPTR(glBegin) +MAKE_FUNCPTR(glBindTexture) +MAKE_FUNCPTR(glBlendFunc) +MAKE_FUNCPTR(glClear) +MAKE_FUNCPTR(glClearColor) +MAKE_FUNCPTR(glClearDepth) +MAKE_FUNCPTR(glClearStencil) +MAKE_FUNCPTR(glClipPlane) +MAKE_FUNCPTR(glColor3f) +MAKE_FUNCPTR(glColor3ub) +MAKE_FUNCPTR(glColor4ub) +MAKE_FUNCPTR(glColorMaterial) +MAKE_FUNCPTR(glCullFace) +MAKE_FUNCPTR(glDeleteTextures) +MAKE_FUNCPTR(glDepthFunc) +MAKE_FUNCPTR(glDepthMask) +MAKE_FUNCPTR(glDisable) +MAKE_FUNCPTR(glDrawBuffer) +MAKE_FUNCPTR(glDrawPixels) +MAKE_FUNCPTR(glEnable) +MAKE_FUNCPTR(glEnd) +MAKE_FUNCPTR(glFlush) +MAKE_FUNCPTR(glFogf) +MAKE_FUNCPTR(glFogfv) +MAKE_FUNCPTR(glFogi) +MAKE_FUNCPTR(glFrontFace) +MAKE_FUNCPTR(glGenTextures) +MAKE_FUNCPTR(glGetBooleanv) +MAKE_FUNCPTR(glGetFloatv) +MAKE_FUNCPTR(glGetIntegerv) +MAKE_FUNCPTR(glHint) +MAKE_FUNCPTR(glLightModelfv) +MAKE_FUNCPTR(glLightModeli) +MAKE_FUNCPTR(glLightfv) +MAKE_FUNCPTR(glLoadIdentity) +MAKE_FUNCPTR(glLoadMatrixf) +MAKE_FUNCPTR(glMaterialf) +MAKE_FUNCPTR(glMaterialfv) +MAKE_FUNCPTR(glMatrixMode) +MAKE_FUNCPTR(glMultMatrixf) +MAKE_FUNCPTR(glNormal3f) +MAKE_FUNCPTR(glNormal3fv) +MAKE_FUNCPTR(glPolygonMode) +MAKE_FUNCPTR(glPolygonOffset) +MAKE_FUNCPTR(glPopMatrix) +MAKE_FUNCPTR(glPushMatrix) +MAKE_FUNCPTR(glRasterPos2f) +MAKE_FUNCPTR(glReadBuffer) +MAKE_FUNCPTR(glReadPixels) +MAKE_FUNCPTR(glShadeModel) +MAKE_FUNCPTR(glStencilFunc) +MAKE_FUNCPTR(glStencilMask) +MAKE_FUNCPTR(glStencilOp) +MAKE_FUNCPTR(glTexCoord2f) +MAKE_FUNCPTR(glTexCoord2fv) +MAKE_FUNCPTR(glTexEnvi) +MAKE_FUNCPTR(glTexImage2D) +MAKE_FUNCPTR(glTexParameteri) +MAKE_FUNCPTR(glTexParameterfv) +MAKE_FUNCPTR(glTexSubImage2D) +MAKE_FUNCPTR(glTranslatef) +MAKE_FUNCPTR(glVertex3f) +MAKE_FUNCPTR(glVertex3fv) +MAKE_FUNCPTR(glVertex4f) +MAKE_FUNCPTR(glXCreateContext) +MAKE_FUNCPTR(glXDestroyContext) +MAKE_FUNCPTR(glXMakeCurrent) +MAKE_FUNCPTR(glXSwapBuffers) +#undef MAKE_FUNCPTR + +#ifndef GLPRIVATE_NO_REDEFINE + +#define glAlphaFunc pglAlphaFunc +#define glBegin pglBegin +#define glBindTexture pglBindTexture +#define glBlendFunc pglBlendFunc +#define glClear pglClear +#define glClearColor pglClearColor +#define glClearDepth pglClearDepth +#define glClearStencil pglClearStencil +#define glClipPlane pglClipPlane +#define glColor3f pglColor3f +#define glColor3ub pglColor3ub +#define glColor4ub pglColor4ub +#define glColorMaterial pglColorMaterial +#define glCullFace pglCullFace +#define glDeleteTextures pglDeleteTextures +#define glDepthFunc pglDepthFunc +#define glDepthMask pglDepthMask +#define glDisable pglDisable +#define glDrawBuffer pglDrawBuffer +#define glDrawPixels pglDrawPixels +#define glEnable pglEnable +#define glEnd pglEnd +#define glFlush pglFlush +#define glFogf pglFogf +#define glFogfv pglFogfv +#define glFogi pglFogi +#define glFrontFace pglFrontFace +#define glGenTextures pglGenTextures +#define glGetBooleanv pglGetBooleanv +#define glGetFloatv pglGetFloatv +#define glGetIntegerv pglGetIntegerv +#define glHint pglHint +#define glLightModelfv pglLightModelfv +#define glLightModeli pglLightModeli +#define glLightfv pglLightfv +#define glLoadIdentity pglLoadIdentity +#define glLoadMatrixf pglLoadMatrixf +#define glMaterialf pglMaterialf +#define glMaterialfv pglMaterialfv +#define glMatrixMode pglMatrixMode +#define glMultMatrixf pglMultMatrixf +#define glNormal3f pglNormal3f +#define glNormal3fv pglNormal3fv +#define glPolygonMode pglPolygonMode +#define glPolygonOffset pglPolygonOffset +#define glPopMatrix pglPopMatrix +#define glPushMatrix pglPushMatrix +#define glRasterPos2f pglRasterPos2f +#define glReadBuffer pglReadBuffer +#define glReadPixels pglReadPixels +#define glShadeModel pglShadeModel +#define glStencilFunc pglStencilFunc +#define glStencilMask pglStencilMask +#define glStencilOp pglStencilOp +#define glTexCoord2f pglTexCoord2f +#define glTexCoord2fv pglTexCoord2fv +#define glTexEnvi pglTexEnvi +#define glTexImage2D pglTexImage2D +#define glTexParameteri pglTexParameteri +#define glTexParameterfv pglTexParameterfv +#define glTexSubImage2D pglTexSubImage2D +#define glTranslatef pglTranslatef +#define glVertex3f pglVertex3f +#define glVertex3fv pglVertex3fv +#define glVertex4f pglVertex4f +#define glXCreateContext pglXCreateContext +#define glXDestroyContext pglXDestroyContext +#define glXMakeCurrent pglXMakeCurrent +#define glXSwapBuffers pglXSwapBuffers + +#endif /* GLPRIVATE_NO_REDEFINE */ + +#endif /* HAVE_OPENGL */ + +#endif /* __GRAPHICS_WINE_GL_PRIVATE_H */ +
Mike, next time ask on IRC before doing a big patch like this on DDraw / D3D (or ask on the wine-d3d mailing list, it will add to its activity :-) ). from a broader point of view (since this type of "oops I step on your toes" issue rose twice in a couple of weeks), would it be of some interest to hold architectural sessions (on #irc as the linux folks just did for example to discuss 2.6 must be:s) to: 1/ spread the word of on going work 2/ discuss orientation of architecture, good bad choices...
A+ -- Eric Pouech
On Thu, May 15, 2003 at 08:38:41PM +0200, Eric Pouech wrote:
Mike, next time ask on IRC before doing a big patch like this on DDraw / D3D (or ask on the wine-d3d mailing list, it will add to its activity :-) ). from a broader point of view (since this type of "oops I step on your toes" issue rose twice in a couple of weeks), would it be of some interest to hold architectural sessions (on #irc as the linux folks just did for example to discuss 2.6 must be:s) to: 1/ spread the word of on going work 2/ discuss orientation of architecture, good bad choices... Hmm, No, I Don't Think So (tm) Since IRC is not persistent, A Wiki would be much better ;) OK, IRC is probably best suited for some vivid (and flaming ;) discussion, but for outlining some Way To Go, a Wiki would probably be best.
-- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt
Setting up a logbot isn't hard, indeed, I could put one on my server if you want. I already run irssi on it constantly. On Thu, 2003-05-15 at 20:52, Andreas Mohr wrote:
On Thu, May 15, 2003 at 08:38:41PM +0200, Eric Pouech wrote:
Mike, next time ask on IRC before doing a big patch like this on DDraw / D3D (or ask on the wine-d3d mailing list, it will add to its activity :-) ). from a broader point of view (since this type of "oops I step on your toes" issue rose twice in a couple of weeks), would it be of some interest to hold architectural sessions (on #irc as the linux folks just did for example to discuss 2.6 must be:s) to: 1/ spread the word of on going work 2/ discuss orientation of architecture, good bad choices... Hmm, No, I Don't Think So (tm) Since IRC is not persistent, A Wiki would be much better ;) OK, IRC is probably best suited for some vivid (and flaming ;) discussion, but for outlining some Way To Go, a Wiki would probably be best. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
On Fri, May 16, 2003 at 09:49:55AM +0100, Mike Hearn wrote:
Setting up a logbot isn't hard, indeed, I could put one on my server if you want. I already run irssi on it constantly. OK, then let me rephrase my requirements to *persistent* and *consistent*. (since an IRC session is far from consistent)
We're talking about architectural issues here, and architecture is about creating *order* (of steps to take, of things to implement, of...). Andreas Mohr
Andreas Mohr wrote:
On Fri, May 16, 2003 at 09:49:55AM +0100, Mike Hearn wrote:
Setting up a logbot isn't hard, indeed, I could put one on my server if you want. I already run irssi on it constantly.
OK, then let me rephrase my requirements to *persistent* and *consistent*. (since an IRC session is far from consistent)
We're talking about architectural issues here, and architecture is about creating *order* (of steps to take, of things to implement, of...).
first, I'd like to hear more about the interest of the idea and not the interest of the tool. secondly, to me, the real benefits of those sessions wouldn't be to have a decent architectural document available (which we nevertheless don't have in lots of areas in Wine), but rather to have developpers share their views / ideas / planned activities on a set of subjects. last, I fully agree with Dimi that Alexandre participation would be greatly appreciated A+ -- Eric Pouech
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Vendredi 16 Mai 2003 20:18, Eric Pouech a écrit :
first, I'd like to hear more about the interest of the idea and not the interest of the tool. secondly, to me, the real benefits of those sessions wouldn't be to have a decent architectural document available (which we nevertheless don't have in lots of areas in Wine), but rather to have developpers share their views / ideas / planned activities on a set of subjects. last, I fully agree with Dimi that Alexandre participation would be greatly appreciated
Well, currently we only have a small interface header for the first draft it contains comments, ideas and structures current definitions but it progress slowly ;) i have take the point te begin to split d3d8 into 2 parts and share one part for current d3dx8.dll and futures d3d9.dll, d3dx9.dll After we'll see how ddraw can use it (as most of the d3d7 needs are the same of d3d8). Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+xTC7p7NA3AmQTU4RAo6hAJ9U0MZkGyKWvT936KsC+q+MAoF5RwCdEhxI e9N5kg19j/l7ifWfDOatljY= =eXmc -----END PGP SIGNATURE-----
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
first, I'd like to hear more about the interest of the idea and not the interest of the tool. secondly, to me, the real benefits of those sessions wouldn't be to have a decent architectural document available (which we nevertheless don't have in lots of areas in Wine), but rather to have developpers share their views / ideas / planned activities on a set of subjects. last, I fully agree with Dimi that Alexandre participation would be greatly appreciated
I have nothing against having such discussions, but I think it's important to make sure that everyone has access to them. Part of the issue with D3D is that the design discussions are taking place on a "private" list, so apart from the handful of people who know about that list, nobody has any idea what's going on. I'm worried that there would be the same problem with IRC: only people who happen to hang around at the right time would have the information. We could of course publish IRC logs but that's not exactly convenient to read... So I'm not sure it would be better than the discussions we already have on wine-devel. -- Alexandre Julliard julliard(a)winehq.com
On 16 May 2003, Alexandre Julliard wrote:
I have nothing against having such discussions, but I think it's important to make sure that everyone has access to them. Part of the issue with D3D is that the design discussions are taking place on a "private" list, so apart from the handful of people who know about that list, nobody has any idea what's going on. I'm worried that there would be the same problem with IRC: only people who happen to hang around at the right time would have the information. We could of course publish IRC logs but that's not exactly convenient to read... So I'm not sure it would be better than the discussions we already have on wine-devel.
I certainly agree that wine-devel should be the main communication medium for obvious reasons. However, the latency on the list is rather large lately (both from an email delivery perspective, as well as a psihological one). Having more of a conversation where the latency is a few seconds allows for a different style of discussion, where one can bring up small ideas that are maybe not worth a thread on wine-devel. The result of such a meeting should be nicely summarized and posted on wine-devel and WineHQ. I think we should give it a try. -- Dimi.
On Fri, May 16, 2003 at 03:33:12PM -0400, Dimitrie O. Paun wrote:
I certainly agree that wine-devel should be the main communication medium for obvious reasons. However, the latency on the list is rather large lately (both from an email delivery perspective, as well as a psihological one). Having more of a conversation where the latency is a few seconds allows for a different style of discussion, where one can bring up small ideas that are maybe not worth a thread on wine-devel.
The result of such a meeting should be nicely summarized and posted on wine-devel and WineHQ.
I think we should give it a try. I second that.
IMHO we should have our monthly "architectural meeting" and have some volunteer go through the log and add the relevant content to the Wine architecture page -- wait, which page again?? ;) At least we should try to have a more focussed and detailed development. For some central issues, nobody knows where exactly we're going (or at most one person ;) You can sign me up for these meetings... Andi
On Fri, May 16, 2003 at 11:43:29AM -0700, Alexandre Julliard wrote:
I have nothing against having such discussions, but I think it's important to make sure that everyone has access to them. Part of the issue with D3D is that the design discussions are taking place on a "private" list, so apart from the handful of people who know about that list, nobody has any idea what's going on.
Well, one could say exactly the same about internal Codeweavers discussions about Wine rearchitecture :-) My main point on answering to the patch sent was mostly one about 'code ownership' : before doing 'intrusive / big' patches, inquire to the people which are known to work on the code if the work is not a risk of duplication / .... Finally, to come back on the wine-d3d list, it was mostly something to focus attention on, to get the stuff back going when the activity was at the lowest and after that to do 'fine tuning' of what people are working on (ie just firing a mail saying 'I am getting game X to work, working on feature Y', something that would have been very boring to 'normal' wine-devel subscribers). Nowadays, as you may see, it works without any need to send mail on this mailing list and as we are mostly 4 people, we rarely step on ones toes. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer <lionel.ulmer(a)free.fr> writes:
Well, one could say exactly the same about internal Codeweavers discussions about Wine rearchitecture :-)
Oh sure, that's precisely why I suggested to Mike to send his opengl stuff to wine-patches, so that there can be a wider discussion about it.
My main point on answering to the patch sent was mostly one about 'code ownership' : before doing 'intrusive / big' patches, inquire to the people which are known to work on the code if the work is not a risk of duplication
IMO sending a proposed patch is a good way to do that; of course you don't want to spend 6 months working on something without consulting others, but if it's just a couple of hours of work, I think "send patch first, ask questions later" is a reasonable strategy. It's a lot easier to debate the merits of the respective solutions when you can actually see what the code looks like. -- Alexandre Julliard julliard(a)winehq.com
So I'm not sure it would be better than the discussions we already have on wine-devel.
I'm not at all convinced that we have enough discussions (being on wine-devel, or somewhere else). If I try to schematize the type of discussions we may have, I could think of three categories: A/ evolution of current architecture, setting goals, directions/directives... B/ detailed architecture (interfaces) C/ implementation details we already have a good set of type C/ with, for example, patches review from wine-patches, and I don't think we need something extra for C/ at the moment B/ is mostly done by, for a given item, by a single person, which doesn't give lots of opportunities to be discussed until we reach the C/ stage. Failing to know that someone is tackling an issue at this stage ends up with people stepping on the other one's toes (read wintab, openGL dynamic linking...) C/ is also little discussed, and it's the area where I think we should focus on first. If it works, B/ and C/ would flow more easily. That's also the area where Alexandre is mostly welcome (on stage B/ we need some other people: for example, Lionel on D3D & OpenGL, Dimi for (some) comctl...). So, when proposing IRC chatting, I was trying to find out some sparkles to fire up the type C/ kind of discussion. Again, the way to the discussion is just a way, the most important is that the discussion takes place (and there is not a single way of doing it) From an interaction point of view: - for C/, peer review is OK IMO, and it can be done with mail, no issue here. - for B/, it will require some material (preview patches...), but in most of the cases mail (and its latency should be fine too) - however for A/ we need both in some cases low latency to agree quickly on some directions, and also long latency so that some proof of concepts can be derived. If we should end up with a low latency echange (let's call it that way to avoid tools oriented issues), I think we also need a (non exhaustive) list of items to be looked at, to be set before the exchange. I would put: - wine configuration - dynamic mount of FS in wine - package dependency (ie detect available packages at runtime not at compile time) - Win32 / Win16 separation A+ -- Eric Pouech
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
So, when proposing IRC chatting, I was trying to find out some sparkles to fire up the type C/ kind of discussion. Again, the way to the discussion is just a way, the most important is that the discussion takes place (and there is not a single way of doing it)
I guess you mean A/ here. Anyway we can certainly give it a try and see what happens. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
So, when proposing IRC chatting, I was trying to find out some sparkles to fire up the type C/ kind of discussion. Again, the way to the discussion is just a way, the most important is that the discussion takes place (and there is not a single way of doing it)
I guess you mean A/ here. Anyway we can certainly give it a try and see what happens.
oops, A/ of course next questions, when shall we try/start ? from what I see (on the mail activity), it seems that around 8/9pm French time (which should be something like 2/3 pm pacific time). I favor a Friday (it easier for me if we keep on going quite late :-(, but any other day would do if it's a show stopper please let me know if it's ok for you A+ -- Eric Pouech
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
from what I see (on the mail activity), it seems that around 8/9pm French time (which should be something like 2/3 pm pacific time). I favor a Friday (it easier for me if we keep on going quite late :-(, but any other day would do if it's a show stopper
please let me know if it's ok for you
In general I think Friday would be fine. Of course I'll be mostly on vacation for the next 3 weeks starting this Thursday, so I probably won't be able to make it before a while :-( But anyway that's a general problem with real-time meetings, there will never be a day that works for everybody, so I guess we just need to decide on a day of week and time, and have the meeting with whomever manages to be around. -- Alexandre Julliard julliard(a)winehq.com
On May 19, 2003 05:25 pm, Alexandre Julliard wrote:
In general I think Friday would be fine. Of course I'll be mostly on vacation for the next 3 weeks starting this Thursday, so I probably won't be able to make it before a while :-(
I'll be away June 6 - July 7 on vacation. I think it's quite important that we get Alexandre in the meeting, any chance of doing it Wed? -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
I'll be away June 6 - July 7 on vacation. I think it's quite important that we get Alexandre in the meeting, any chance of doing it Wed?
Fine with me. -- Alexandre Julliard julliard(a)winehq.com
On Tue, May 20, 2003 at 10:45:55AM -0700, Alexandre Julliard wrote:
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
I'll be away June 6 - July 7 on vacation. I think it's quite important that we get Alexandre in the meeting, any chance of doing it Wed?
Fine with me. Not so fine with me, since I'll be on excursions this and next week. :-\
-- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt
Alexandre Julliard wrote:
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
I'll be away June 6 - July 7 on vacation. I think it's quite important that we get Alexandre in the meeting, any chance of doing it Wed?
Fine with me.
me too A+ -- Eric Pouech
On Tue, May 20, 2003 at 09:03:54PM +0200, Eric Pouech wrote:
Alexandre Julliard wrote:
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
I'll be away June 6 - July 7 on vacation. I think it's quite important that we get Alexandre in the meeting, any chance of doing it Wed?
Fine with me.
me too
This wednesday? Just give the time in UTC/GMT, i'll try to be there ;) Ciao, Marcus
This wednesday? Just give the time in UTC/GMT, i'll try to be there ;)
Ciao, Marcus
let's try this wenesday before a few lucky ones get (well deserved :-) vacation this should be around 6 pm GMT (if I got it right) A+ -- Eric Pouech
On Tue, 20 May 2003, Marcus Meissner wrote:
This wednesday?
Yes.
Just give the time in UTC/GMT, i'll try to be there ;)
Say 3pm EDT, which should be 1900 UTC (but don't get fooled by Daylight Savings Time, UTC does not get adjusted by DST). For those in Europe, that should be around 20:00 London/UK time, and I think for Germany is 21:00 Uhr :) -- Dimi.
This wednesday? Just give the time in UTC/GMT, i'll try to be there ;)
Ditto, but I'd not recommend using #winehq on freenode - there is a high volume of tech support traffic on that channel, it might prove rather distracting. Perhaps #winemeet?
On Thu, 15 May 2003, Eric Pouech wrote:
from a broader point of view (since this type of "oops I step on your toes" issue rose twice in a couple of weeks), would it be of some interest to hold architectural sessions (on #irc as the linux folks just did for example to discuss 2.6 must be:s) to: 1/ spread the word of on going work 2/ discuss orientation of architecture, good bad choices...
Anything is fine with me to get Alexandre to talk... :) -- Dimi.
participants (11)
-
Alexandre Julliard -
Andreas Mohr -
Dimitrie O. Paun -
Dimitrie O. Paun -
Eric Pouech -
Lionel Ulmer -
Marcus Meissner -
Mike Hearn -
Mike Hearn -
Mike McCormack -
Raphaël Junqueira