July 2008 - Wine-Devel - list.winehq.org

Re: [WineHQ][WWN] WWN 349
by Ivan Gyurdiev July 14, 2008

July 14, 2008

> Zachary Goldberg wrote: ... but did not spell check :) Granted, the movie quote is pretty funny, even if isn't spelled right. Ivan

5 4

Re: [PATCH 1/2] user32: Add more tests for SetWindowPos.
by Alexandre Julliard July 14, 2008

July 14, 2008

"Lei Zhang" <thestig(a)google.com> writes: > +static UINT sequence_contains(UINT msg) > +{ > + static const struct message end_of_sequence = { 0, 0, 0, 0 }; > + const struct message *actual; > + UINT num = 0; > + > + add_message(&end_of_sequence); > + actual = sequence; > + > + while (actual->message) > + { > + if (actual->message == msg) num++; > + actual++; > + } > + return num; > +} The fix looks good now, but you should really test the message sequences instead of just counting a single message. We have already all the necessary mechanisms for this. -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: wined3d: Enable filtering for D3DFMT_A4R4G4B4.
by Stefan Dösinger July 14, 2008

July 14, 2008

Looks ok to me > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Philip Nilsson > Sent: Monday, July 14, 2008 11:20 AM > To: wine-patches(a)winehq.org > Subject: wined3d: Enable filtering for D3DFMT_A4R4G4B4. > > This patch enables texture filtering for textures using the A4R4G4B4 > format, I can see no reason why it shouldn't be filtered (especially > considering X4R4G4B4 has it). > > Works for me, in any case. Writing a test case may be hard. > > Probably solves bug 13256 (I can't think of any other format that would > be used instead).

1 0

new valgrind warnings in IWineD3DImpl_CreateDevice, IDirectDrawImpl_CreateSurface
by Dan Kegel July 14, 2008

July 14, 2008

Lots of tests are showing new valgrind warnings involving IWineD3DImpl_CreateDevice, e.g. http://kegel.com/wine/valgrind/logs/2008-07-14-06.13/vg-ddraw_dsurface-diff… + Invalid free() / delete / delete[] + at notify_free (heap.c:199) + by RtlFreeHeap (heap.c:1284) + by compile_state_table (state.c:4557) + by IWineD3DImpl_CreateDevice (directx.c:3472) + by DDRAW_Create (main.c:235) + by DirectDrawCreate (main.c:373) + by CreateDirectDraw (dsurface.c:36) + by func_dsurface (dsurface.c:2616) + by run_test (test.h:488) + by main (test.h:537) http://kegel.com/wine/valgrind/logs/2008-07-14-06.13/vg-d3d9_query-diff.txt + Invalid free() / delete / delete[] + at notify_free (heap.c:199) + by RtlFreeHeap (heap.c:1284) + by compile_state_table (state.c:4557) + by IWineD3DImpl_CreateDevice (directx.c:3472) + by IDirect3D9Impl_CreateDevice (directx.c:493) + by test_query_support (query.c:96) + by func_query (query.c:266) + by run_test (test.h:488) + by main (test.h:537) Plus, http://kegel.com/wine/valgrind/logs/2008-07-14-06.13/vg-ddraw_dsurface-diff… has the additional new warning: + Conditional jump or move depends on uninitialised value(s) + at IDirectDrawImpl_CreateSurface (ddraw_thunks.c:403) + by MipMapCreationTest (dsurface.c:198) + by func_dsurface (dsurface.c:2618) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at IDirectDrawImpl_CreateSurface (ddraw_thunks.c:384) Stefan, could you have a look? Thanks... - Dan

1 0

RE: wined3d: universal surface convertor function for unsigned integer color formats
by Stefan Dösinger July 14, 2008

July 14, 2008

There's a pixelformat table that describes bitmasks and sizes in utils.c, you can access it with a function that is next to it. I think you can infer the shifting information from this table, if not please add it there instead of creating your own table. Also please do not use C++ comments("//"), and watch out regarding tabs and spaces Your patch still adds the x8r8g8b8_to_x5r6g5 function, and I think it is a bit ugly to bypass the existing format conversion table entirely and add the convert_unsigned_pixels function. I think it would be better to access this function using the conversion table. One reason is that we could use the table in directx.c in CheckDeviceFormatConversion, so the information is all in one place. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Victor Eremin > Sent: Sunday, July 13, 2008 5:52 PM > To: wine-patches(a)winehq.org > Subject: wined3d: universal surface convertor function for unsigned > integer color formats > > > Converter function supports conversion between most of "unsigned color" > argb/xrgb surface formats (like D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, and > so on), and between "luminosity" color formats (D3DFMT_L8, etc), > excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, > D3DFMT_P8 and D3DFMT_A1. > > Conversion from rgba to luminosity (and vice versa) is not currently > implemented. > > The patch removes "Cannot find coverter" FIXMEs from "Ancient Evil" and > "Stranded 2" games. > > Patch also fixes water glitches in "Stranded 2" game. > --- > dlls/wined3d/surface_base.c | 215 > +++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 209 insertions(+), 6 deletions(-)

2 1

Re: wined3d: universal surface convertor function for unsigned integer color formats
by Philip Nilsson July 14, 2008

July 14, 2008

On Mon, Jul 14, 2008 at 02:51:42AM +0400, Victor Eremin wrote: > > Converter function supports conversion between most of > "unsigned color" argb/xrgb surface formats (like D3DFMT_A8R8G8B8, > D3DFMT_A8R3G3B2, and so on), and between "luminosity" color formats > (D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, > D3DFMT_P8 and D3DFMT_A1. > > Conversion from rgba to luminosity (and vice versa) is not currently > implemented. > > The patch removes "Cannot find coverter" FIXMEs from "Ancient Evil" and > "Stranded 2" games. > > Patch also fixes water glitches in "Stranded 2" game. I've attached my pixel conversion function which uses the table in utils.c. Hope you find it useful although I haven't really polished it.

1 0

Re: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture
by H. Verbeet July 14, 2008

July 14, 2008

2008/7/14 Tobias Jakobi <liquid.acid(a)gmx.net>: > Hi there, > > this patchset fixes conformance of volumes/volumetextures creation (plus > locking) in d3d8 and d3d9. Currently creating volumes/volumetextures > always succeeds regardless of the usage and pool type specified. > > A testcase for both d3d8 and d3d9 is included in the last two patches. > The test was verified on Vista and XP systems. > > Further fixes to volume/volumetexture locking are planned (the behaviour > is still not quite correct) and some of the fixes in this patchset could > be moved over to wined3d. That's also something that can be done when > the hardest work is over. > > Cheers, > Tobias Jakobi > As you note in your comment, most of this should go into wined3d. I also think this should for the most part use the same code that is used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would probably be able to help you best there, but he's currently away.

2 2

Allow running conformance tests in parallel
by Dan Kegel July 14, 2008

July 14, 2008

The attached patch lets you run Wine's conformance tests in parallel. On my relatively fast dual core machine (e7200): "make -k test" takes 3 minutes 55 seconds "make -k -j2 test" takes 2 minutes 15 seconds "make -k -j4 test" takes 1 minute 45 seconds "make -k -j10 test" takes 1 minute 27 seconds About the same number of tests fail regardless of -j value. How it works: this patch adds a new function, winetest_exclusive(), that waits until it can acquire an exclusive lock. It should be called near the top of the START_TEST body for any test that needs exclusive access to the system. (In tests that exec themselves, the call has to be placed carefully to avoid having the child call it.) I did this for all tests that call CreateWindow, and a few more that seemed like they might need it. The list of tests marked exclusive is somewhat rough; probably a few tests should be added or removed, but it's pretty good for a first cut. I've been wanting to do this for ages. Turned out to be easier than I'd feared.

2 2

re: Illegal attachment in bug 14461
by Dan Kegel July 14, 2008

July 14, 2008

Vitaliy wrote: > Bugzilla admin(s) please remove the illegal attachment from the > http://bugs.winehq.org/show_bug.cgi?id=14461 Deleted.

1 0

user32: Problem using SetClassLongW to subclass built-in control (Edit)
by Hongbo Ni July 14, 2008

July 14, 2008

Hi, Summary: SetClassLongW(hEdit, GCL_WNDPROC,(DWORD)NewEditWndProc) in Wine differs from Windows. Background: when a standard built-in window class (such as Edit for example) is registered initially, the window system register the class with two Procedures (procA and ProcW) and assign a handle as WNDPROC to the class. If a Edit window is created using CreateWindowExA, it will be an Ansi Window. If a Edit window is created using CreateWindowExW, it will be an Unicode Window. This fine in Wine. Problem: I globally subclass the Edit class using SetClassLongW using following code ------------------------------------------------------------------------------------------------------------ HWND hEdit = CreateWindowExA(0,"Edit", "E1",WS_POPUP,0, 0, 1,1,NULL,NULL,NULL,NULL); OldEditWndProc =(WNDPROC)SetClassLongW(hEdit, GCL_WNDPROC,(DWORD)NewEditWndProc); ------------------------------------------------------------------------------------------------------------ After this subclass, Wine behaves different from Windows In Windows: a new Edit windows created by CreateWindowsExA((0,"Edit",...) is a Still an Ansi Windows a new Edit windows created by CreateWindowsExW((0,"Edit",...) is a Unicode Windows But in Wine, new Edit windows created by CreateWindowsExA or CreateWindowsExW are all Unicode Windows. I checked wine 1.1 source code , basically the call to SetClassLongW(hEdit, GCL_WNDPROC,(DWORD)NewEditWndProc) has set the Edit class proc to Unicode Only. So regardless how you create the Edit window, it will be Unicode window. This is understandable but it's different form windows. causing my application to mis-behave. More problem, the OldEditWndProc returned above is only the procW of Edit class, if we try to undo the subclass with SetClassLongW(hEdit, GCL_WNDPROC,(DWORD)OldEditWndProc ); the Edit class also lost it's procA. Discussion: How wine could do the same as windows? SetClassLongW(hEdit, GCL_WNDPROC,(DWORD)NewEditWndProc) should 1. return the proc handle of the class, instead of procW. 2. set both ProcA and ProcW of Edit class to NewEditWndProc. so NewEditWndProc need to handle both messages from Ansi and Unicode Edit control. I don't know what is the best way to fix this. Please help. I have posted a Test application on Bugzilla #14350, please try. Regards Hongbo _________________________________________________________________ Are you paid what you're worth? Find out: SEEK Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2…

4 8