January 2007 - Wine-Devel - list.winehq.org

Re: [3/3] WineD3D: Implement per stream offsets
by Mirek Jan. 17, 2007

Jan. 17, 2007

Hi, one or more nvidia sdk demos using instancing. Mirek Stefan Dösinger napsal(a): > Stumbled uppon that while reading up instancing. This is a functionality > technically required for all d3d9 drivers. The new functionality is not > really tested because I have no app that really needs this, but it should not > cause issues with games not using stream offsets. > > > ------------------------------------------------------------------------ > > From 6bd68813f3b05e525555ab2c28b331d838b50b92 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Sat, 13 Jan 2007 15:09:16 +0100 > Subject: [PATCH] WineD3D: Implement per stream offsets > > --- > dlls/wined3d/directx.c | 2 +- > dlls/wined3d/drawprim.c | 47 +++++++++++++++++++++++++++++++++++++---------- > dlls/wined3d/state.c | 22 ++++++++++++---------- > 3 files changed, 50 insertions(+), 21 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index cbcbdc2..0e6f4bc 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -2244,7 +2244,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > ------------------------------------------------ */ > if (This->dxVersion > 8) { > /* d3d9.dll sets D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES here because StretchRects is implemented in d3d9 */ > - *pCaps->DevCaps2 = 0; > + *pCaps->DevCaps2 = D3DDEVCAPS2_STREAMOFFSET; > /* TODO: VS3.0 needs at least D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET */ > *pCaps->MaxNpatchTessellationLevel = 0; > *pCaps->MasterAdapterOrdinal = 0; > diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c > index 400ffb5..fdc9843 100644 > --- a/dlls/wined3d/drawprim.c > +++ b/dlls/wined3d/drawprim.c > @@ -628,8 +628,12 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > DWORD diffuseColor = 0xFFFFFFFF; /* Diffuse Color */ > DWORD specularColor = 0; /* Specular Color */ > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > + UINT *streamOffset = This->stateBlock->streamOffset; > LONG SkipnStrides = startVertex + This->stateBlock->loadBaseVertexIndex; > > + BYTE *texCoords[WINED3DDP_MAXTEXCOORD]; > + BYTE *diffuse = NULL, *specular = NULL, *normal = NULL, *position = NULL; > + > TRACE("Using slow vertex array code\n"); > > /* Variable Initialization */ > @@ -638,6 +642,29 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > else pIdxBufL = (const long *) idxData; > } > > + /* Adding the stream offset once is cheaper than doing it every iteration. Do not modify the strided data, it is a pointer > + * to the strided Data in the device and might be needed intact on the next draw > + */ > + for (textureNo = 0, texture_idx = 0; textureNo < GL_LIMITS(texture_stages); ++textureNo) { > + if(sd->u.s.texCoords[textureNo].lpData) { > + texCoords[textureNo] = sd->u.s.texCoords[textureNo].lpData + streamOffset[sd->u.s.texCoords[textureNo].streamNo]; > + } else { > + texCoords[textureNo] = NULL; > + } > + } > + if(sd->u.s.diffuse.lpData) { > + diffuse = sd->u.s.diffuse.lpData + streamOffset[sd->u.s.diffuse.streamNo]; > + } > + if(sd->u.s.specular.lpData) { > + specular = sd->u.s.specular.lpData + streamOffset[sd->u.s.specular.streamNo]; > + } > + if(sd->u.s.normal.lpData) { > + normal = sd->u.s.normal.lpData + streamOffset[sd->u.s.normal.streamNo]; > + } > + if(sd->u.s.position.lpData) { > + position = sd->u.s.position.lpData + streamOffset[sd->u.s.position.streamNo]; > + } > + > /* Start drawing in GL */ > VTRACE(("glBegin(%x)\n", glPrimType)); > glBegin(glPrimType); > @@ -707,8 +734,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > continue; > } > > - ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData + (SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride)); > - if (sd->u.s.texCoords[coordIdx].lpData == NULL) { > + ptrToCoords = (float *)(texCoords[coordIdx] + (SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride)); > + if (texCoords[coordIdx] == NULL) { > TRACE("tex: %d - Skipping tex coords, as no data supplied\n", textureNo); > ++texture_idx; > continue; > @@ -796,8 +823,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } /* End of textures */ > > /* Diffuse -------------------------------- */ > - if (sd->u.s.diffuse.lpData != NULL) { > - DWORD *ptrToCoords = (DWORD *)(sd->u.s.diffuse.lpData + (SkipnStrides * sd->u.s.diffuse.dwStride)); > + if (diffuse) { > + DWORD *ptrToCoords = (DWORD *)(diffuse + (SkipnStrides * sd->u.s.diffuse.dwStride)); > diffuseColor = ptrToCoords[0]; > VTRACE(("diffuseColor=%lx\n", diffuseColor)); > > @@ -813,8 +840,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Specular ------------------------------- */ > - if (sd->u.s.specular.lpData != NULL) { > - DWORD *ptrToCoords = (DWORD *)(sd->u.s.specular.lpData + (SkipnStrides * sd->u.s.specular.dwStride)); > + if (specular) { > + DWORD *ptrToCoords = (DWORD *)(specular + (SkipnStrides * sd->u.s.specular.dwStride)); > specularColor = ptrToCoords[0]; > VTRACE(("specularColor=%lx\n", specularColor)); > > @@ -850,16 +877,16 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Normal -------------------------------- */ > - if (sd->u.s.normal.lpData != NULL) { > - float *ptrToCoords = (float *)(sd->u.s.normal.lpData + (SkipnStrides * sd->u.s.normal.dwStride)); > + if (normal != NULL) { > + float *ptrToCoords = (float *)(normal + (SkipnStrides * sd->u.s.normal.dwStride)); > > VTRACE(("glNormal:nx,ny,nz=%f,%f,%f\n", ptrToCoords[0], ptrToCoords[1], ptrToCoords[2])); > glNormal3f(ptrToCoords[0], ptrToCoords[1], ptrToCoords[2]); > } > > /* Position -------------------------------- */ > - if (sd->u.s.position.lpData != NULL) { > - float *ptrToCoords = (float *)(sd->u.s.position.lpData + (SkipnStrides * sd->u.s.position.dwStride)); > + if (position) { > + float *ptrToCoords = (float *)(position + (SkipnStrides * sd->u.s.position.dwStride)); > x = ptrToCoords[0]; > y = ptrToCoords[1]; > z = ptrToCoords[2]; > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index bc2686f..8d74006 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -2112,6 +2112,7 @@ static inline void unloadNumberedArrays(IWineD3DStateBlockImpl *stateblock) { > static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertexStridedData *strided) { > GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; > int i; > + UINT *offset = stateblock->streamOffset; > > for (i = 0; i < MAX_ATTRIBS; i++) { > > @@ -2130,7 +2131,7 @@ static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDi > WINED3D_ATR_GLTYPE(strided->u.input[i].dwType), > WINED3D_ATR_NORMALIZED(strided->u.input[i].dwType), > strided->u.input[i].dwStride, > - strided->u.input[i].lpData + stateblock->loadBaseVertexIndex * strided->u.input[i].dwStride)); > + strided->u.input[i].lpData + stateblock->loadBaseVertexIndex * strided->u.input[i].dwStride + offset[strided->u.input[i].streamNo]) ); > GL_EXTCALL(glEnableVertexAttribArrayARB(i)); > } > } > @@ -2139,6 +2140,7 @@ static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDi > static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertexStridedData *sd) { > unsigned int textureNo = 0; > unsigned int texture_idx = 0; > + UINT *offset = stateblock->streamOffset; > GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; > > TRACE("Using fast vertex array code\n"); > @@ -2155,7 +2157,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > #endif > > TRACE("Blend %d %p %d\n", WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType), > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride, sd->u.s.blendWeights.dwStride); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride, sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo]); > /* FIXME("TODO\n");*/ > /* Note dwType == float3 or float4 == 2 or 3 */ > > @@ -2170,7 +2172,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > VTRACE(("glWeightPointerARB(%d, GL_FLOAT, %d, %p)\n", > WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType) , > sd->u.s.blendWeights.dwStride, > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride)); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo])); > > if(curVBO != sd->u.s.blendWeights.VBO) { > GL_EXTCALL(glBindBufferARB(GL_ARRAY_BUFFER_ARB, sd->u.s.blendWeights.VBO)); > @@ -2182,7 +2184,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType), > WINED3D_ATR_GLTYPE(sd->u.s.blendWeights.dwType), > sd->u.s.blendWeights.dwStride, > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo]); > > checkGLcall("glWeightPointerARB"); > > @@ -2320,12 +2322,12 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > if(sd->u.s.position.VBO == 0) { > glVertexPointer(3 /* min(WINED3D_ATR_SIZE(sd->u.s.position.dwType),3) */, > WINED3D_ATR_GLTYPE(sd->u.s.position.dwType), > - sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride); > + sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride + offset[sd->u.s.position.streamNo]); > } else { > glVertexPointer( > WINED3D_ATR_SIZE(sd->u.s.position.dwType), > WINED3D_ATR_GLTYPE(sd->u.s.position.dwType), > - sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride); > + sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride + offset[sd->u.s.position.streamNo]); > } > checkGLcall("glVertexPointer(...)"); > glEnableClientState(GL_VERTEX_ARRAY); > @@ -2350,7 +2352,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > glNormalPointer( > WINED3D_ATR_GLTYPE(sd->u.s.normal.dwType), > sd->u.s.normal.dwStride, > - sd->u.s.normal.lpData + stateblock->loadBaseVertexIndex * sd->u.s.normal.dwStride); > + sd->u.s.normal.lpData + stateblock->loadBaseVertexIndex * sd->u.s.normal.dwStride + offset[sd->u.s.normal.streamNo]); > checkGLcall("glNormalPointer(...)"); > glEnableClientState(GL_NORMAL_ARRAY); > checkGLcall("glEnableClientState(GL_NORMAL_ARRAY)"); > @@ -2384,7 +2386,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > } > glColorPointer(4, GL_UNSIGNED_BYTE, > sd->u.s.diffuse.dwStride, > - sd->u.s.diffuse.lpData + stateblock->loadBaseVertexIndex * sd->u.s.diffuse.dwStride); > + sd->u.s.diffuse.lpData + stateblock->loadBaseVertexIndex * sd->u.s.diffuse.dwStride + offset[sd->u.s.diffuse.streamNo]); > checkGLcall("glColorPointer(4, GL_UNSIGNED_BYTE, ...)"); > glEnableClientState(GL_COLOR_ARRAY); > checkGLcall("glEnableClientState(GL_COLOR_ARRAY)"); > @@ -2411,7 +2413,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > } > GL_EXTCALL(glSecondaryColorPointerEXT)(4, GL_UNSIGNED_BYTE, > sd->u.s.specular.dwStride, > - sd->u.s.specular.lpData + stateblock->loadBaseVertexIndex * sd->u.s.specular.dwStride); > + sd->u.s.specular.lpData + stateblock->loadBaseVertexIndex * sd->u.s.specular.dwStride + offset[sd->u.s.specular.streamNo]); > vcheckGLcall("glSecondaryColorPointerEXT(4, GL_UNSIGNED_BYTE, ...)"); > glEnableClientState(GL_SECONDARY_COLOR_ARRAY_EXT); > vcheckGLcall("glEnableClientState(GL_SECONDARY_COLOR_ARRAY_EXT)"); > @@ -2476,7 +2478,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > WINED3D_ATR_SIZE(sd->u.s.texCoords[coordIdx].dwType), > WINED3D_ATR_GLTYPE(sd->u.s.texCoords[coordIdx].dwType), > sd->u.s.texCoords[coordIdx].dwStride, > - sd->u.s.texCoords[coordIdx].lpData + stateblock->loadBaseVertexIndex * sd->u.s.texCoords[coordIdx].dwStride); > + sd->u.s.texCoords[coordIdx].lpData + stateblock->loadBaseVertexIndex * sd->u.s.texCoords[coordIdx].dwStride + offset[sd->u.s.texCoords[coordIdx].streamNo]); > glEnableClientState(GL_TEXTURE_COORD_ARRAY); > } > } else if (!GL_SUPPORT(NV_REGISTER_COMBINERS)) { > > > ------------------------------------------------------------------------ > >

1 0

Re: comctl32: center calendar in monthcal
by Lei Zhang Jan. 17, 2007

Jan. 17, 2007

Hi, Can we get this patch committed? It's a trivial fix to the calendar positioning, as seen here: http://linux.ucla.edu/~leiz/software/wine/screenshots/monthcal.png - Lei On 12/29/06, Lei Zhang <thestig(a)google.com> wrote: > The month calendar currently puts the calendar in the top-right corner > of the control window, it should be centered. > > --- > monthcal.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > >

1 0

The real DLL-Hell ("sfc.dll"), created by MS
by Detlef Riekenberg Jan. 16, 2007

Jan. 16, 2007

I verify my work on winspool.drv and localspl.dll with the native versions of "localspl.dll" in wine. To my surprise, localspl.dll/XP needs a native "sfc_os.dll", while localspl.dll/W2K is happy with our buildin "sfc.dll" Please remember: - "sfc.dll" was not present before w2k. - The "System File Checker" API was introduced in win98 (with a different API in "sfcdll.dll") MS produced the ugliest case of the DLL-Hell on ther own! Two total different DLL's with a different API, but the same name: http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=sfc.dll&S=1&x… --- cut -- SFC.DLL (13.Nov.1998) in MS Office 2000 Prof (Starfighter Foundation Classes v1.0 DLL) http://support.microsoft.com/dllhelp/default.aspx?l=55&fid=115535 sfc.dll (07.Dec.1999) in Windows 2000 Prof (Windows File Protection) http://support.microsoft.com/dllhelp/?fid=72785&l=55&det=1 -- cut --- And to make the things even worse, the "sfc.dll" from office has the Version "1998.*" Congratulations -- By by ... Detlef

1 0

WineD3D: ProcessVertices
by Christoph Bumiller Jan. 16, 2007

Jan. 16, 2007

Henri Verbeet wrote: > Well, you can't set a VBO as rendertarget directly, but you can copy > the FBO data into a PBO, which you can bind as a VBO. That's pretty > legitimate in OpenGL. But I was wondering how hard it would be to use > something like that for ProcessVertices. Well, you would get the rendered pixels' data written to the VBO then, right? To use this for ProcessVertices one would have to have a bijective relation between pixel's and processed vertices; p.e. pass the transformed vertex coordinates in varying variables and use'em as the color components and have the pixels stored in the order the vertices are so we can tell afterwards from what vertex they originate, in passing the vertex index as an attribute and so generate appropriate vertex coords ... theoretically. I don't think its easy or even possible to have exactly one pixel per vertex at sequential positions in the pixel buffer, or is it (using points and knowing the resolution etc.) ?

2 1

Time for wine-mono or wine-dotnet11 component in Bugzilla?
by Dan Kegel Jan. 16, 2007

Jan. 16, 2007

While filing http://bugs.winehq.org/show_bug.cgi?id=7098 I realized that I'm starting to see lots of apps that require dot net, and there are two ways we could go to support them: 1) get msft's dotnetfx.exe to install (see http://bugs.winehq.org/show_bug.cgi?id=5358) and work 2) whip our mono integration into shape (see http://kegel.com/wine/fakedotnet.sh ) The question is, how should we tag bugs in bugzilla that fail because neither of these approaches really work yet? Should we make them depend on bug 5358, or should we create a new bug component, wine-dotnet11 or wine-mono, and put them in there? Filing these bugs as wine-misc seems wrong, so I'm leaning towards a new bugzilla component. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 8

Getting GTK/W32 applications to run
by Peter Gerwinski Jan. 16, 2007

Jan. 16, 2007

Hello, WINE developers! While working on a cross-platform project, I tried to run some self-compiled GTK/W32 applications on a Debian GNU/Linux Sarge system using WINE 0.9.29, compiled from source. They crashed immediately. After some long, but unsuccessful Google sessions and some long, but successful RTFS/debugging sessions, I am now able to run and test my cross-compiled GTK/W32 applications in WINE. :-) Furthermore, I can start the W32 version of The GIMP up to the moment where it tries to load its plug-ins. (Without the plug-ins, the remaining parts of The GIMP even seem to work flawlessly.) Since Google told me that running GTK/W32 applications in WiNE - in particular: The GIMP - was an unsolved problem, I am hereby telling you what I observed and what I did. * Out of the box, pango (GTK's font renderer) does not find any suitable font. OTOH a non-GTK program, opening a MessageBox, works flawlessly, so the fonts are there. * When I tell pango to use a TrueType font *and* place the .ttf file in c:/windows/fonts/, I can start GTK's "Hello, world!" program, but the text is >300 pixels high, and thus unusable. (Real-world programs used to crash with a message similar to "memory exhausted", but trying to reproduce the exact message now results in *running* programs with a giant font. Sorry.) I conclude that (at least in my installation) pango does not find WINE's pixel fonts (even if I place them in c:/windows/fonts/), and sees the TTFs only with a wrong scaling factor. * When I tell pango to use the font "Sans 0.1", I get satisfying results. (In concrete, I got it working with the following gtkrc: style "wine-default-style" { font_name = "Sans 0.1" } widget "*" style "wine-default-style" ) I cannot fine-tune the font size. Using "Sans 0.2" or "Sans 0.01" yields exactly the same as "Sans 0.1". There seems to be one more intermediate size at "Sans 0.5"; after that the "normal" font sizes start with "Sans 1". Since both WINE and pango/GTK are free software, I am confident that these problems will be solved in the long run. I hope that you can use my observations. BTW, let me thank you for over 10 years of WINE by hacking Tom Payne's famous quote on Unix: Ten years ago mainstream users were choosing WABI over WINE. Now they are choosing $PROPRIETARY_FORK_OF_WINE over WINE. What part of that message aren't they getting? Keep on your excellent work! Cheers, Peter -- Dr. rer. nat. Peter Gerwinski - http://www.peter.gerwinski.de German pages for GNU & free software - http://www.gnu.de G-N-U GmbH - EDV-Dienstleistungen - http://www.g-n-u.de Essener Linux User Group - http://www.elug.de

3 4

Re: Alexandre Julliard : ntdll: Implemented NtLockVirtualMemory and NtUnlockVirtualMemory.
by Robert Shearman Jan. 16, 2007

Jan. 16, 2007

Alexandre Julliard wrote: > dlls/ntdll/virtual.c | 56 ++++++++++++++++++++++++++++++++++----- > include/wine/server_protocol.h | 32 +++++++++++++++++++++- > server/protocol.def | 30 ++++++++++++++++++++- > server/thread.c | 2 + > server/trace.c | 18 +++++++++++++ > 5 files changed, 127 insertions(+), 11 deletions(-) > It looks like the part of the commit to handle APC_VIRTUAL_LOCK/UNLOCK in call_apcs in dlls/ntdll/sync.c has been omitted. -- Rob Shearman

1 0

Re: iphlpapi - MacOS / BSD support
by Stefan Dösinger Jan. 16, 2007

Jan. 16, 2007

Am Dienstag 16 Januar 2007 03:17 schrieb Gavriel State: > Author: Mark Adams <mark(a)transgaming.com> > > ChangeLog: > - Clarify interface counting > - Filter out no-ip addresses when building ip address table > - Add error messages when unimplemented functions are called on > non-linux platforms (ie: platforms without routing info in /proc) > - Implement retrieving the interface list on MacOS X (and other > platforms that use NET_RT_DUMP) I don't know the iphlpapi code, but the changelog suggests to me that the changes should be split up into seperate patches.

1 0

Re: iphlpapi - MacOS / BSD support
by Francois Gouget Jan. 16, 2007

Jan. 16, 2007

--- iphlpapi/ifenum.c 21 Dec 2006 16:37:51 -0000 1.25 +++ iphlpapi/ifenum.c 15 Jan 2007 23:16:54 -0000 @@ -22,7 +22,7 @@ [...] - * - using the sysctl interface (FreeBSD and Mac OS X) + * - using the sysctl interface (FreeBSD and MacOS X) Just a small note; based on the Apple website I think the original spelling was correct. But don't worry about it, my 'typos' script should pick it up once your patch is committed and I will send a fix for it then. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

1 0

Re: [dinput 4/5] Add a config for the axes
by Vitaliy Margolen Jan. 16, 2007

Jan. 16, 2007

Christoph Frick wrote: > Add a config for the axes like we do for the buttons > > This adds a mapping from the linux input id of the axis to the instance id > we assigned the axis. > --- > df->rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(axis++) | DIDFT_ABSAXIS; > } > - for (i = 0; i < 4; i++) > + > + idx = WINE_JOYSTICK_MAX_AXES; Why are you creating a gap? This is exactly the point here to skip all the objects that we do not have. And they all need to be sequential in godf - no gaps. Otherwise you braking EnumObjects. Vitaliy.

2 2