February 2014 - Wine-Devel - list.winehq.org

Swat4 -too dark shadows maybe solved

by Jarkko Korpi

I downloaded swat4 demo. It has too dark swats and shadows. http://bugs.winehq.org/show_bug.cgi?id=8848 (which is reported here too also with demo) I think I figured out what is causing it. I noticed that setting windows registerykey useGLSL=disabled made swats look like normal (see my sent pics). I debuged the game and there wasn't many different lines. fixme:exec:SHELL_execute flags ignored: 0x00000100 fixme:process:GetProcessWorkingSetSize (0xffffffff,0x33eac4,0x33eac0): stub fixme:win:EnumDisplayDevicesW ((null),0,0x33ed48,0x00000000), stub! fixme:wbemprox:client_security_SetBlanket 0x7cf14558, 0x1396f0, 10, 0, (null), 3, 3, (nil), 0x00000000 fixme:wbemprox:client_security_Release 0x7cf14558 fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x00000030 fixme:win:EnumDisplayDevicesW ((null),0,0x33ec68,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33ef58,0x00000000), stub! fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS) fixme:win:EnumDisplayDevicesW ((null),0,0x33ca58,0x00000000), stub! fixme:d3d:wined3d_swapchain_set_gamma_ramp Ignoring flags 0x1. fixme:d3d:wined3d_swapchain_set_gamma_ramp Ignoring flags 0x1. etc etc But I think wine is missing the next feature, what's causing the black shadows http://msdn.microsoft.com/en-us/library/windows/desktop/bb173461%28v=vs.85%… "You can include the D3DSGR_CALIBRATE value for the first parameter of SetGammaRamp", well its definitely trying to set gamma, but it's IGNORED. Here are the pics, before and setting that useGLSL registery key http://postimg.org/image/kxct6863j/ http://postimg.org/image/n48bm1dk9/ But setting that registery key dosn't help on shadows which are too dark. According to my knowledge reading some part of that Microsoft explanation making this setgammaramp function shoulnt be too hard, it just adjust the amount of RGB.

Feb. 28, 2014

Re: Failing dpnet tests

by Alistair Leslie-Hughes

On 25/02/2014 2:10 AM, Francois Gouget wrote: > On Wed, 19 Feb 2014, Alistair Leslie-Hughes wrote: > [...] >> Would it be possible to test windows 8 without the firewall enabled? >> > > I suspect a simple LoadLibrary() will trigger that dialog too so some > other approach may be needed. Maybe something based on FindExecutable() > would work. > After some testing, LoadLibrary and LoadLibraryEx trigger DLLmain to be called. The dpnet.dll exists in the system32 directory but is a stub dll which causes that dialog to appear. Still working on using LoadLibraryEx to load the DLL as a resources only (Assuming it wont call DLLMain). From there it would be possible to check the Filename or Origial name from the Version properties. Well that's my plan. If anybody else has any ideas, happy to listen. Alistair.

Feb. 28, 2014

Re: dmime: Do not try to query a NULL direct sound buffer

by Aric Stewart

On 2014/02/26 18:11, Nikolay Sivov wrote: > On 2/26/2014 13:03, Aric Stewart wrote: >> --- >> dlls/dmime/audiopath.c | 33 ++++++++++++++++++--------------- >> 1 file changed, 18 insertions(+), 15 deletions(-) > Why is it NULL though? The only place I found that sets it is this: > > --- > hr = IDirectSound8_CreateSoundBuffer ((LPDIRECTSOUND8) This->pDirectSound, &desc, &buffer, NULL); > if (FAILED(hr)) { > HeapFree(GetProcessHeap(), 0, default_path); > *ppNewPath = NULL; > return DSERR_BUFFERLOST; > } > default_path->pDSBuffer = buffer; > --- > > That means CreateSoundBuffer() doesn't return error code properly? > > It is NULL because of Andrew's commit: commit 629e857c2ee0e8816a11ee4ab446c13798362f33 Author: Andrew Eikum <aeikum(a)codeweavers.com> Date: Wed Apr 18 10:14:01 2012 -0500 dmime: Don't try to create a standard audio path if the client didn't ask for one. -aric

Feb. 28, 2014

Re: shell32: Supply a module name to CreateProcess

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -330,9 +332,14 @@ static UINT_PTR SHELL_ExecuteW(const WCHAR *lpCmd, WCHAR *env, BOOL shWait, > /* ShellExecute specifies the command from psei->lpDirectory > * if present. Not from the current dir as CreateProcess does */ > if( lpDirectory ) > + { > if( ( gcdret = GetCurrentDirectoryW( MAX_PATH, curdir))) > if( !SetCurrentDirectoryW( lpDirectory)) > ERR("cannot set directory %s\n", debugstr_w(lpDirectory)); > + > + PathCombineW(module_path, psei->lpDirectory, psei->lpFile); > + path = module_path; > + } We'd want to specify the path in all cases, not only when we have a directory. Also the SetCurrentDirectory shouldn't be needed with a proper path. -- Alexandre Julliard julliard(a)winehq.org

Feb. 27, 2014

Re: [PATCH 2/2] d3dx9/tests: Add a mesh test for D3DXCreateBox() (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5256 Your paranoid android. === w8 (32 bit mesh) === mesh.c:8158: Test failed: Mesh 27: new_num_vertices == 6, expected 4. mesh.c:8172: Test failed: Mesh 27: indices[3] == 3, expected 1 mesh.c:8172: Test failed: Mesh 27: indices[4] == 4, expected 3 mesh.c:8172: Test failed: Mesh 27: indices[5] == 5, expected 2 mesh.c:8213: Test failed: Mesh 27: vertex_remap_ptr[3] == 3, expected 4 mesh.c:8213: Test failed: Mesh 27: vertex_remap_ptr[4] == 4, expected -1 mesh.c:8213: Test failed: Mesh 27: vertex_remap_ptr[5] == 5, expected -1 mesh.c:8228: Test failed: Mesh 27: Got (2.000000, 3.000000, 0.000000) for vertex 3 position, expected (3.000000, 0.000000, 0.000000).

Feb. 27, 2014

Re: [PATCH 2/2] d3dx9/tests: Add a mesh test for D3DXCreateBox()

by Matteo Bruni

u2014-02-27 12:19 GMT+01:00 Marvin <testbot(a)winehq.org>: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=5232 > > Your paranoid android. > > > === w8 (32 bit mesh) === > mesh.c:8156: Test failed: Mesh 27: new_num_vertices == 6, expected 4. > mesh.c:8170: Test failed: Mesh 27: indices[3] == 3, expected 1 > mesh.c:8170: Test failed: Mesh 27: indices[4] == 4, expected 3 > mesh.c:8170: Test failed: Mesh 27: indices[5] == 5, expected 2 > mesh.c:8211: Test failed: Mesh 27: vertex_remap_ptr[3] == 3, expected 4 > mesh.c:8211: Test failed: Mesh 27: vertex_remap_ptr[4] == 4, expected -1 > mesh.c:8211: Test failed: Mesh 27: vertex_remap_ptr[5] == 5, expected -1 > mesh.c:8226: Test failed: Mesh 27: Got (2.000000, 3.000000, 0.000000) for vertex 3 position, expected (3.000000, 0.000000, 0.000000). > FWIW, this test failure is unrelated to the patch. I see it's failing inconsistently on Win8, while e.g. it doesn't fail for me on Win7. As far as I understand, it's the float color vertex data the culprit (i.e. native d3dx9 doesn't really handle that case and the test passes or fails "by luck"). I'm going to send a patch for that.

Feb. 27, 2014

Re: urlmon: Fixed url.c tests on IE11.

by Jacek Caban

On 02/27/14 16:43, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://newtestbot.winehq.org/JobDetails.pl?Key=5243 > > Your paranoid android. > > > === wxppro (32 bit url) === > url.c:1669: Test failed: unexpected call OnProgress_FINDINGRESOURCE > url.c:1878: Test failed: binding failed: 800c0005, expected 00000000 > url.c:1889: Test failed: res = 00002efd, expected 00000000 > url.c:3146: Test failed: expected OnProgress_SENDINGREQUEST > url.c:3152: Test failed: expected OnResponse > url.c:3156: Test failed: expected OnProgress_MIMETYPEAVAILABLE > url.c:3157: Test failed: expected OnProgress_BEGINDOWNLOADDATA > url.c:3158: Test failed: expected OnProgress_ENDDOWNLOADDATA > url.c:3170: Test failed: expected OnDataAvailable Those are existing ones still left to fix. Jacek

Feb. 27, 2014

Re: Use of wined3d_mutex?

by Max Woodbury

On 02/27/2014 03:10 AM, Stefan Dösinger wrote: > > Am 2014-02-26 20:13, schrieb Max TenEyck Woodbury: >> In particular, user call back functions are being called in >> several places with this mutex held. If the callback starts >> another thread to do something graphical where the thread needs the >> mutex, and then waits for the thread to finish, both threads will >> hang until the mutex times out. There are also places where a >> function that takes out the mutex is called with the mutex already >> held. >> > ddraw calls application-provided callback functions. A long time ago I > did some testing on Windows, and it also uses a dll-global lock for > ddraw and keeps it held when calling those callbacks. So we're doing > the right thing here. > Thank you for the information. That means I can ignore that issue. > In case of d3d8/9, there are in theory the Resource's SetPrivateData, > GetPrivateData and FreePrivateData functions that can call application > code, specificly an IUnknown's AddRef and Release function. I have > never tested how those behave wrt the dll lock. This thing can also be > used to write a black-box test to see at which granularity Windows > does d3d8/9 synchronization. > Uh, OK. (More information than I can handle at the moment. Maybe later...) >> Switching to another terminal window and back again sometimes >> breaks these deadlocks. >> > That seems wrong, unless we're accidentally holding those locks while > sending window messages. > With the time-out in place, it is hard to tell if it is still a problem, but it used to happen irregularly. It seemed to be something racy. It showed up with one batch of patches and then disappear after a couple more sets. Whatever it is, it is a really old problem. IIRC it was more of a problem with ddraw4 and ddraw7 than it was with the earlier interfaces... max

Feb. 27, 2014

Re: urlmon: Fixed url.c tests on IE11.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5243 Your paranoid android. === wxppro (32 bit url) === url.c:1669: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1878: Test failed: binding failed: 800c0005, expected 00000000 url.c:1889: Test failed: res = 00002efd, expected 00000000 url.c:3146: Test failed: expected OnProgress_SENDINGREQUEST url.c:3152: Test failed: expected OnResponse url.c:3156: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3157: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3158: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3170: Test failed: expected OnDataAvailable

Feb. 27, 2014

Re: ws2_32/tests: Mark a SIOCATMARK test result as broken

by Bruno Jesus

On Thu, Feb 27, 2014 at 11:43 AM, Marvin <testbot(a)winehq.org> wrote: > === wxppro (32 bit sock) === > sock: unhandled exception c0000005 at 00000000 > > === wvistau64 (32 bit sock) === > sock: unhandled exception c0000005 at 00000000 > > === w2008s64 (64 bit sock) === > sock: unhandled exception c0000005 at 000007FEFE4220C0 > > === w7pro64 (64 bit sock) === > sock.c:622: Test failed: oob_server (98c): not at the OOB mark: 1 There are also these weird crashes when (I guess) WSACleanup is called twice to test the not initialized error. -- Bruno

Feb. 27, 2014