- Wine-Devel - list.winehq.org

Re: [D3D] Some execute buffers rewrites + misc fixes
by Lionel Ulmer May 21, 2003

May 21, 2003

Well, I have a comment... But it's in a part of the code that will be so rarely used that it could be completely thrown away anyway :-) Basically, you are doing the full projection (without doing the clipping though) in software... And this does not go well at all with lighting. This is why I choose in the previous code to only do the world transformation to NOT impact at all lighting (and it worked for Twist AFAIK). So I am wondering why you choose to go all the way and did not do exactly as I did (basically, only do the WORLD transform and set only the PROJ / VIEW one using the D3D7 API and set the WORLD to Identity as we already did the transform). Even better would have been to have reused fully our VertexBuffer code and our (hacky :-) ) TransformVertices code. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: dlls/ntdll/cdrom.c CDROM_ScsiPassThrough on NetBSD
by yorickhardy May 21, 2003

May 21, 2003

Alexandre, My sincerest apologies, I see it is in fact there. I think I missed something when I looked through wine-cvs and the web cvs (I looked at source.winehq.org instead of cvs.winehq.com) Thanks, Yorick. ----- Original Message ----- Date: Wed May 21, 2003 09:22 AM From: Alexandre Julliard <julliard(a)winehq.com> To: yh(a)metroweb.co.za cc: wine-devel(a)winehq.com Subject: Re: dlls/ntdll/cdrom.c CDROM_ScsiPassThrough on NetBSD yh(a)metroweb.co.za writes: > I see this patch was included > http://www.winehq.org/hypermail/wine-patches/2003/05/0258.html > http://www.winehq.org/hypermail/wine-cvs/2003/05/0312.html > > I apologise if it was not clear but the patch > http://www.winehq.org/hypermail/wine-patches/2003/05/0241.html > should be applied first, which includes the neccessary header files. I thought I applied it, what did I do wrong? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dlls/ntdll/cdrom.c CDROM_ScsiPassThrough on NetBSD
by yh＠metroweb.co.za May 21, 2003

May 21, 2003

I see this patch was included http://www.winehq.org/hypermail/wine-patches/2003/05/0258.html http://www.winehq.org/hypermail/wine-cvs/2003/05/0312.html I apologise if it was not clear but the patch http://www.winehq.org/hypermail/wine-patches/2003/05/0241.html should be applied first, which includes the neccessary header files. Regards, Yorick Hardy. ------------------------------------------------------- This message was sent using MetroWEB's WebMail service. http://www.metroweb.co.za/ - full access for only R59

2 1

Re: Fix ListView Bugs
by Dimitrie O. Paun May 21, 2003

May 21, 2003

On May 17, 2003 06:37 am, Robert Shearman wrote: > It is the second one. The 0th subitem always seems to stay in the 0th > column and the other subitems are shifted. (Note that the column headings > are shifted normally, ie. column 0 has a new column heading). Interesting. This seems to mean that we can remove a lot of fancy code from there :) What about this patch: Index: dlls/comctl32/listview.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.351 diff -u -r1.351 listview.c --- dlls/comctl32/listview.c 13 May 2003 00:30:10 -0000 1.351 +++ dlls/comctl32/listview.c 19 May 2003 07:28:54 -0000 @@ -6242,25 +6242,10 @@ /* now we have to actually adjust the data */ if (!(infoPtr->dwStyle & LVS_OWNERDATA) && infoPtr->nItemCount > 0) { - SUBITEM_INFO *lpSubItem, *lpMainItem, **lpNewItems = 0; + SUBITEM_INFO *lpSubItem; HDPA hdpaSubItems; INT nItem, i; - /* preallocate memory, so we can fail gracefully */ - if (nNewColumn == 0) - { - lpNewItems = COMCTL32_Alloc(sizeof(SUBITEM_INFO *) * infoPtr->nItemCount); - if (!lpNewItems) goto fail; - for (i = 0; i < infoPtr->nItemCount; i++) - if (!(lpNewItems[i] = COMCTL32_Alloc(sizeof(SUBITEM_INFO)))) break; - if (i != infoPtr->nItemCount) - { - for(; i >=0; i--) COMCTL32_Free(lpNewItems[i]); - COMCTL32_Free(lpNewItems); - goto fail; - } - } - for (nItem = 0; nItem < infoPtr->nItemCount; nItem++) { hdpaSubItems = (HDPA)DPA_GetPtr(infoPtr->hdpaItems, nItem); @@ -6270,21 +6255,7 @@ if (lpSubItem->iSubItem >= nNewColumn) lpSubItem->iSubItem++; } - - /* for inserting column 0, we have to special-case the main item */ - if (nNewColumn == 0) - { - lpMainItem = (SUBITEM_INFO *)DPA_GetPtr(hdpaSubItems, 0); - lpSubItem = lpNewItems[nItem]; - lpSubItem->hdr = lpMainItem->hdr; - lpSubItem->iSubItem = 1; - ZeroMemory(&lpMainItem->hdr, sizeof(lpMainItem->hdr)); - lpMainItem->iSubItem = 0; - DPA_InsertPtr(hdpaSubItems, 1, lpSubItem); - } } - - COMCTL32_Free(lpNewItems); } /* make space for the new column */ -- Dimi.

2 1

Re: ddraw: load OpenGL at runtime
by Lionel Ulmer May 20, 2003

May 20, 2003

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/

11 30

[FYI] SourceForge stats
by Dimitrie O. Paun May 20, 2003

May 20, 2003

Folks, For the first time we are in the first 30 downloads (position 29 :)) on SourceForge: http://sourceforge.net/top/toplist.php?type=downloads_week We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;) -- Dimi.

4 11

Re: ntdll/kernel32: #25
by Alexandre Julliard May 20, 2003

May 20, 2003

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - access to PROCESS_PARAMETERS from kernel32: currently this is done > by exporting a function pointer from ntdll, but this is not a good > solution IMO. Should we better: 1/ create a real PEB and store it at > its real offset. 2/ store the pointer to PROCESS_PARAMETER in the PDB > (even if it doesn't exist in PDB but in PEB) at an unused offset (I > don't think it's really doable to merge PDB and PEB, or we'll have to > trash PDB.exit_code) PDB and PEB are really the same thing, so they definitely have to be merged. -- Alexandre Julliard julliard(a)winehq.com

2 2

DSound bug in 'DuplicateSoundBuffer'
by Lionel Ulmer May 20, 2003

May 20, 2003

Hi all, One of my test application (which now starts to run with my latest D3D work) fails now due to a bug in DSound. Basically, I have this : trace:dsound:IDirectSoundImpl_DuplicateSoundBuffer (0x4040aa80,0x4861fad0,0x4199cf58) fixme:dsound:IDirectSoundImpl_DuplicateSoundBuffer need to duplicate 3D buffer trace:dsound:IDirectSoundBufferImpl_AddRef (0x4861fad0) ref was 2, thread is 0009 trace:dsound:IDirectSoundImpl_DuplicateSoundBuffer buffer count is now 4 trace:dsound:IDirectSoundBufferImpl_SetVolume (0x40463080,0) And, of course, it crashes as the 'DuplicateSoundBuffer' code sets this : (*ippdsb)->ds3db = NULL; /* FIXME? */ Now I could try to fix this, but well, DSound is not really the same than the last time I looked at it, so I will surely do this the wrong way. Otherwise, I may give it a shot, but do not complain later that it's not the way it should have been done :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: [D3D] Some execute buffers rewrites + misc fixes
by Lionel Ulmer May 20, 2003

May 20, 2003

Some comments on 'small' parts... I will have to commit the patch on my tree to try to understand the resulting code to understand it better :-) > + if ( IsEqualGUID( &IID_IDirectDrawSurface, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface2, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface3, riid ) ) { > + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, IDirectDrawSurface7)); > + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface3); > + TRACE(" Return IDirectDrawSurface3 interface %p\n", *obp); > + return S_OK; > + } > + if ( IsEqualGUID( &IID_IDirectDrawSurface3, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface7, riid ) ) { > + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, IDirectDrawSurface7)); > + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface7); > + TRACE(" Return IDirectDrawSurface7 interface %p\n", *obp); > + return S_OK; > + } Well, it's a bit strange to have 'IID_IDirectDrawSurface3' twice, no :-) ? > /* We only support the BLT with DEPTH_FILL for now */ > - if (This->ddraw_owner->d3d != NULL) { > + if ((dwFlags & DDBLT_DEPTHFILL) && This->ddraw_owner->d3d != NULL) { > if (This->ddraw_owner->d3d->current_device != NULL) { > This->ddraw_owner->d3d->current_device->clear(This->ddraw_owner->d3d->current_device, > 0, NULL, /* Clear the whole screen */ Did you add this check here because some game were actually doing a 'normal' blit on the ZBuffer ? What happens in this case ? Moreover, you could also add here (which I forgot to do in my patch), support for the 'dst locking rectangle' in case an application tries to clear only part of the buffer (see example in the Blt overide function in d3ddevice/mesa.c for the 'Colorfill' case). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Linking errors when crosscompiling tests
by Hans Leidekker May 20, 2003

May 20, 2003

Hi, When I run a 'make crosstest' using MingW I get errors like these: /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:289: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x1814):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:290: undefined reference to `IID_IUnknown' What's happening is that this test references symbols that reside in wine_uuid, which is added to the library search path for the regular Wine build, but left out in the crosscompile build. For good reasons, because wine_uuid is built as a Unix archive, not as an import library, which is what MingW needs. So I created an import library from the Unix archive: nm libwine_uuid.a | egrep -v "^$" | egrep -v "^*.o:$" | cut -d" " -f 3 \ >> wine_uuid.def i386-mingw32-dlltool -l wine_uuid.lib -d ./wine_uuid.def And I had a working executable. But this obviously is not the way Wine does it. Wine generates .def files from .spec files. To use Wine's build system I had to create a new dll -- uuid -- and copy the sources over from libs/uuid. This gave me a Wine generated import library. Next I added uuid as an import library to the Makefile for the oleaut32 test and removed wine_uuid from EXTRALIBS. Did this solve my problem? No it didn't. Because, as it turns out, winebuild does not support importing non-function entry points, such as IID_IUnknown. After googling around a bit I have to conclude that this is quite a fundamental problem. If I understand it correctly, it's because in this case PE style linking can not be emulated using the ELF linker. Then I decided to bypass linking and go with LoadLibraryA and GetProcAddress, which are already used in the tests to find the functions to be tested. This finally gave me a uniform build system for regular and crosscompiled tests. My question is, is this acceptable for integration into Wine? The consequence would be that, to be consistent, all parts of Wine that are now linked with wine_uuid would need to be converted. Or is such consistency maybe considered less important than getting crosscompiled tests going? -Hans

3 4