November 2019 - Wine-Devel - list.winehq.org

Wine staging 4.21 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 4.21 (833 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * none Added: * [47668] kernelbase: Improve stub for ReOpenFile and add small test * [48138] League of Legends 9.23: Crash after champ select * [47970] Legends of Runeterra crashes at launch * [40334] AION - Wine /Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x0000000000000000). * [48175] AION (64 bit) - crashes in crysystem.dll.CryFree() due to high memory pointers allocated * [46568] 64-bit msxml6.dll from Microsoft Core XML Services 6.0 redist package fails to load (Wine doesn't respect 44-bit user-mode VA limitation from Windows < 8.1) Updated: * d3d9-Direct3DShaderValidatorCreate9 * winecfg-Staging Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

Nov. 30, 2019

Re: Install issue with 32-bit Wine on 64-bit Ubuntu

by Thales

Sveinar, "A working wine is then put in the /home/myname/wine/wine-git folder with both 64/32 bit binaries." Both are in the same folder? The Biarch had been working for up until now, but, I confess, dealing with 32 and 64 bit binaries is a bit confusing, especially when the project is so massive. "If you have further problems with this, i recommend posting on the forums https://forum.winehq.org/ rather than posting on the developer mailing list, as the chances are a lot higher for proper help there :) Good luck!" Good idea! Thanks for your help! Regards,...John Alway On Friday, November 29, 2019, 09:16:34 AM CST, Sveinar Søpler <cybermax(a)dexter.no> wrote: Ubuntu "Biarch" is a "Biach" :P I do not know how this would work as a system install following that guide (honestly i would NOT recommend that), as installing i386 wine IN THE lxc container would NOT install 32-bit wine in your live system... thus running "sudo make install" after going back to your live system (outside of lxc), the 32-bit installed binaries is not available and thus it might not work as intended. Afaik building a working biarch wine in Ubuntu you need to either do as the guide describes - using --prefix=/home/youruser/install/dir - or using the ubuntu build system (debuild) or similar. I just tested doing my usual install with wine-git, and that worked fine. I run the configure with "--prefix=/home/myname/wine/wine-git" (on all 3.. wine64, wine32-tools and wine32 just like the guide describe using lxc container), and just run the "make install" without sudo. A working wine is then put in the /home/myname/wine/wine-git folder with both 64/32 bit binaries. If you have further problems with this, i recommend posting on the forums https://forum.winehq.org/ rather than posting on the developer mailing list, as the chances are a lot higher for proper help there :) Good luck! Sveinar On 28.11.2019 23:24, Thales wrote: > Hello, > > I've gone through the compile and install process for Wine > successfully several times, but this time when attempting to install > the 32-bit wine ("~/wine32$ sudo make install"), the installer throws > errors. It's mixing up 32 and 64 bit. On my 64-bit Ubuntu 16.04. > > For example... > "/usr/bin/ld: i386 architecture of input file `config.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: i386 architecture of input file `debug.o' is incompatible > with i386:x86-64 output > /usr/bin/ld: i386 architecture of input file `ldt.o' is incompatible > with i386:x86-64 output > /usr/bin/ld: i386 architecture of input file `loader.o' is > incompatible with i386:x86-64 output > /usr/bin/ld: i386 architecture of input file `mmap.o' is incompatible > with i386:x86-64 output > /usr/bin/ld: i386 architecture of input file `port.o' is incompatible > with i386:x86-64 output > ..." > > Somehow it broke. I tried to uninstall using "~/wine32$ sudo make > uninstall" and that failed also. > > I guess I need to figure out how to uninstall this. > > These are the directions I've been using for compiling and installing: > https://wiki.winehq.org/Building_Biarch_Wine_On_Ubuntu > > > > Any ideas? :-) > > Thanks, > ...John Alway > > > > > >

Nov. 29, 2019

Re: [PATCH] dmband: Stop corruption of output string

by Michael Stefaniuc

On 11/29/19 9:47 PM, Michael Stefaniuc wrote: > /home/michi/work/wine/dlls/dmband/dmutils.c: In function > 'debugstr_DMUS_OBJECTDESC': > /home/michi/work/wine/dlls/dmband/dmutils.c:144:10: warning: returning > 'int' from a function with return type 'const char *' makes pointer from > integer without a cast [-Wint-conversion] > return wine_dbg_printf("%s", buffer); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > One for each DLL for both 32 and 64 bit. > > Wonder why the testbot didn't complain about this. I'm using mingw too: > $ i686-w64-mingw32-gcc --version > i686-w64-mingw32-gcc (GCC) 8.3.0 20190222 (Fedora MinGW 8.3.0-2.fc29) Now I see the compiler warnings in the WTB mingw output too. So it isn't mingw that isn't complaining. bye michael > > On 11/29/19 2:07 AM, Alistair Leslie-Hughes wrote: >> Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> >> --- >> dlls/dmband/dmutils.c | 2 +- >> dlls/dmcompos/dmcompos_main.c | 2 +- >> dlls/dmloader/debug.c | 4 ++-- >> dlls/dmscript/dmscript_main.c | 2 +- >> 4 files changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/dlls/dmband/dmutils.c b/dlls/dmband/dmutils.c >> index c76bde1146..5d38d06d1d 100644 >> --- a/dlls/dmband/dmutils.c >> +++ b/dlls/dmband/dmutils.c >> @@ -141,7 +141,7 @@ static const char *debugstr_DMUS_OBJECTDESC (LPDMUS_OBJECTDESC pDesc) { >> wine_dbgstr_longlong(pDesc->llMemLength), pDesc->pbMemData); >> if (pDesc->dwValidData & DMUS_OBJ_STREAM) ptr += sprintf(ptr, " - pStream = %p\n", pDesc->pStream); >> >> - return wine_dbg_sprintf("%s", buffer); >> + return wine_dbg_printf("%s", buffer); >> } else { >> return "(NULL)"; >> } >> diff --git a/dlls/dmcompos/dmcompos_main.c b/dlls/dmcompos/dmcompos_main.c >> index 21e896cc3e..1580e215bb 100644 >> --- a/dlls/dmcompos/dmcompos_main.c >> +++ b/dlls/dmcompos/dmcompos_main.c >> @@ -472,7 +472,7 @@ const char *debugstr_DMUS_OBJECTDESC (LPDMUS_OBJECTDESC pDesc) { >> wine_dbgstr_longlong(pDesc->llMemLength), pDesc->pbMemData); >> if (pDesc->dwValidData & DMUS_OBJ_STREAM) ptr += sprintf(ptr, " - pStream = %p", pDesc->pStream); >> >> - return wine_dbg_sprintf("%s", buffer); >> + return wine_dbg_printf("%s", buffer); >> } else { >> return wine_dbg_sprintf("(NULL)"); >> } >> diff --git a/dlls/dmloader/debug.c b/dlls/dmloader/debug.c >> index 30b23c2ade..af76404b57 100644 >> --- a/dlls/dmloader/debug.c >> +++ b/dlls/dmloader/debug.c >> @@ -503,7 +503,7 @@ const char *debugstr_DMUS_IO_CONTAINER_HEADER (LPDMUS_IO_CONTAINER_HEADER pHeade >> ptr += sprintf(ptr, "DMUS_IO_CONTAINER_HEADER (%p):", pHeader); >> ptr += sprintf(ptr, "\n - dwFlags = %s", debugstr_DMUS_CONTAINER_FLAGS(pHeader->dwFlags)); >> >> - return wine_dbg_sprintf("%s", buffer); >> + return wine_dbg_printf("%s", buffer); >> } else { >> return wine_dbg_sprintf("(NULL)"); >> } >> @@ -519,7 +519,7 @@ const char *debugstr_DMUS_IO_CONTAINED_OBJECT_HEADER (LPDMUS_IO_CONTAINED_OBJECT >> ptr += sprintf(ptr, "\n - ckid = %s", debugstr_fourcc (pHeader->ckid)); >> ptr += sprintf(ptr, "\n - fccType = %s", debugstr_fourcc (pHeader->fccType)); >> >> - return wine_dbg_sprintf("%s", buffer); >> + return wine_dbg_printf("%s", buffer); >> } else { >> return wine_dbg_sprintf("(NULL)"); >> } >> diff --git a/dlls/dmscript/dmscript_main.c b/dlls/dmscript/dmscript_main.c >> index 7a96679302..4055ea6a93 100644 >> --- a/dlls/dmscript/dmscript_main.c >> +++ b/dlls/dmscript/dmscript_main.c >> @@ -502,7 +502,7 @@ const char *debugstr_DMUS_OBJECTDESC (LPDMUS_OBJECTDESC pDesc) { >> wine_dbgstr_longlong(pDesc->llMemLength), pDesc->pbMemData); >> if (pDesc->dwValidData & DMUS_OBJ_STREAM) ptr += sprintf(ptr, " - pStream = %p", pDesc->pStream); >> >> - return wine_dbg_sprintf("%s", buffer); >> + return wine_dbg_printf("%s", buffer); >> } else { >> return wine_dbg_sprintf("(NULL)"); >> } >> > >

Nov. 29, 2019

Re: [PATCH] dmband: Stop corruption of output string

by Michael Stefaniuc

/home/michi/work/wine/dlls/dmband/dmutils.c: In function 'debugstr_DMUS_OBJECTDESC': /home/michi/work/wine/dlls/dmband/dmutils.c:144:10: warning: returning 'int' from a function with return type 'const char *' makes pointer from integer without a cast [-Wint-conversion] return wine_dbg_printf("%s", buffer); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One for each DLL for both 32 and 64 bit. Wonder why the testbot didn't complain about this. I'm using mingw too: $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 8.3.0 20190222 (Fedora MinGW 8.3.0-2.fc29) bye michael On 11/29/19 2:07 AM, Alistair Leslie-Hughes wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/dmband/dmutils.c | 2 +- > dlls/dmcompos/dmcompos_main.c | 2 +- > dlls/dmloader/debug.c | 4 ++-- > dlls/dmscript/dmscript_main.c | 2 +- > 4 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/dlls/dmband/dmutils.c b/dlls/dmband/dmutils.c > index c76bde1146..5d38d06d1d 100644 > --- a/dlls/dmband/dmutils.c > +++ b/dlls/dmband/dmutils.c > @@ -141,7 +141,7 @@ static const char *debugstr_DMUS_OBJECTDESC (LPDMUS_OBJECTDESC pDesc) { > wine_dbgstr_longlong(pDesc->llMemLength), pDesc->pbMemData); > if (pDesc->dwValidData & DMUS_OBJ_STREAM) ptr += sprintf(ptr, " - pStream = %p\n", pDesc->pStream); > > - return wine_dbg_sprintf("%s", buffer); > + return wine_dbg_printf("%s", buffer); > } else { > return "(NULL)"; > } > diff --git a/dlls/dmcompos/dmcompos_main.c b/dlls/dmcompos/dmcompos_main.c > index 21e896cc3e..1580e215bb 100644 > --- a/dlls/dmcompos/dmcompos_main.c > +++ b/dlls/dmcompos/dmcompos_main.c > @@ -472,7 +472,7 @@ const char *debugstr_DMUS_OBJECTDESC (LPDMUS_OBJECTDESC pDesc) { > wine_dbgstr_longlong(pDesc->llMemLength), pDesc->pbMemData); > if (pDesc->dwValidData & DMUS_OBJ_STREAM) ptr += sprintf(ptr, " - pStream = %p", pDesc->pStream); > > - return wine_dbg_sprintf("%s", buffer); > + return wine_dbg_printf("%s", buffer); > } else { > return wine_dbg_sprintf("(NULL)"); > } > diff --git a/dlls/dmloader/debug.c b/dlls/dmloader/debug.c > index 30b23c2ade..af76404b57 100644 > --- a/dlls/dmloader/debug.c > +++ b/dlls/dmloader/debug.c > @@ -503,7 +503,7 @@ const char *debugstr_DMUS_IO_CONTAINER_HEADER (LPDMUS_IO_CONTAINER_HEADER pHeade > ptr += sprintf(ptr, "DMUS_IO_CONTAINER_HEADER (%p):", pHeader); > ptr += sprintf(ptr, "\n - dwFlags = %s", debugstr_DMUS_CONTAINER_FLAGS(pHeader->dwFlags)); > > - return wine_dbg_sprintf("%s", buffer); > + return wine_dbg_printf("%s", buffer); > } else { > return wine_dbg_sprintf("(NULL)"); > } > @@ -519,7 +519,7 @@ const char *debugstr_DMUS_IO_CONTAINED_OBJECT_HEADER (LPDMUS_IO_CONTAINED_OBJECT > ptr += sprintf(ptr, "\n - ckid = %s", debugstr_fourcc (pHeader->ckid)); > ptr += sprintf(ptr, "\n - fccType = %s", debugstr_fourcc (pHeader->fccType)); > > - return wine_dbg_sprintf("%s", buffer); > + return wine_dbg_printf("%s", buffer); > } else { > return wine_dbg_sprintf("(NULL)"); > } > diff --git a/dlls/dmscript/dmscript_main.c b/dlls/dmscript/dmscript_main.c > index 7a96679302..4055ea6a93 100644 > --- a/dlls/dmscript/dmscript_main.c > +++ b/dlls/dmscript/dmscript_main.c > @@ -502,7 +502,7 @@ const char *debugstr_DMUS_OBJECTDESC (LPDMUS_OBJECTDESC pDesc) { > wine_dbgstr_longlong(pDesc->llMemLength), pDesc->pbMemData); > if (pDesc->dwValidData & DMUS_OBJ_STREAM) ptr += sprintf(ptr, " - pStream = %p", pDesc->pStream); > > - return wine_dbg_sprintf("%s", buffer); > + return wine_dbg_printf("%s", buffer); > } else { > return wine_dbg_sprintf("(NULL)"); > } >

Nov. 29, 2019

Re: [PATCH 2/2] d3dcompiler/tests: Fix parameter desc test on d3d10.

by Matteo Bruni

On Fri, Nov 29, 2019 at 2:07 PM Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > On Fri, Nov 29, 2019, 13:05 Sven Baars <sven.wine(a)gmail.com> wrote: > > > > On 29-11-2019 11:57, Matteo Bruni wrote: > > > + else > > > + ok(!desc.Stream,·"(%u):·got·unexpected·Stream·%u.\n",·i,·desc.Stream); > > > > > > > Hi Matteo, > > > > This is not true according to the tests: > > > > https://test.winehq.org/data/tests/d3d10:reflection.html > > Oh indeed, there is something weird going on (e.g. > https://test.winehq.org/data/ec9eddf86b144cc0fcf975a9cc864cf08ba84eaf/win10…) > That suggests that somehow the "missing" field is changed by the > implementation? AFAICS the local variable is supposed to be completely > initialized to 0 by the test. Also of note, it looks like only the > 64-bit tests are affected. Okay, as it turns out on 64-bit sizeof(D3D10_SIGNATURE_PARAMETER_DESC) == sizeof(D3D11_SIGNATURE_PARAMETER_DESC) == 32 i.e. the structs have actually the same size, the d3d10 version has just more padding at the end. I thought that the d3d10 version would always end before the offset of the Stream field in the d3d11 structure so testing that the implementation (especially our implementation) doesn't write out of the struct would be a useful test. But that's clearly not the case and checking the contents of the padding isn't a particularly sensible thing to do. I'll drop those checks from the d3d10 tests; Sven, thanks again for the patch and keep looking after the fix in case I still miss something :D P.S.: It's mildly annoying that pahole doesn't work with PE files, it would have been useful in this case.

Nov. 29, 2019

Re: [PATCH v2 2/6] wined3d: Introduce wined3d_stateblock_get_state().

by Henri Verbeet

On Fri, 29 Nov 2019 at 18:47, Zebediah Figura <z.figura12(a)gmail.com> wrote: > On 11/29/19 1:25 AM, Henri Verbeet wrote: > > On Thu, 28 Nov 2019 at 09:24, Zebediah Figura <z.figura12(a)gmail.com> wrote: > >> +#define LIGHTMAP_SIZE 43 > >> +#define LIGHTMAP_HASHFUNC(x) ((x) % LIGHTMAP_SIZE) > > > > Although wined3d is an internal Wine interface, it still seems > > unfortunate to expose this particular implementation detail in the > > public wined3d interface. > > > > Understandable, though I'm not immediately sure what do about it. > > We could introduce individual wined3d_stateblock_get_*() helpers, though > at the last point of conversation regarding stateblocks, I recall you > seemed to prefer allowing direct access to struct wined3d_stateblock_state. > Generally yes. > I guess another option is to hold a pointer to wined3d_light_state > instead of exposing it directly. > I don't necessarily have a clear solution either, but I'm thinking along those lines, yes.

Nov. 29, 2019

Re: [PATCH] ddraw/tests: Skip test_colorkey_precision() test on WARP.

by Marvin

Hi, While running your changed tests, 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://testbot.winehq.org/JobDetails.pl?Key=61126 Your paranoid android. === w8 (32 bit report) === ddraw: ddraw7.c:3122: Test failed: Failed to create surface, hr 0x887601c2. 0fcc:ddraw7: unhandled exception c0000005 at 00512EB5 === w8adm (32 bit report) === ddraw: ddraw7.c:3140: Test failed: Got unexpected hr 0x887601c2.

Nov. 29, 2019

[PATCH] wined3d: Add Intel HD 615 PCI id and device description.

by elee＠codeweavers.com

From: Ethan Lee <elee(a)codeweavers.com> Signed-off-by: Ethan Lee <elee(a)codeweavers.com> --- dlls/wined3d/directx.c | 1 + dlls/wined3d/wined3d_private.h | 1 + 2 files changed, 2 insertions(+) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 902cc444ce..12b53f7577 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -565,6 +565,7 @@ static const struct wined3d_gpu_description gpu_description_table[] = {HW_VENDOR_INTEL, CARD_INTEL_IPP580_2, "Intel(R) Iris(TM) Pro Graphics P580", DRIVER_INTEL_HD4000, 2048}, {HW_VENDOR_INTEL, CARD_INTEL_UHD617, "Intel(R) UHD Graphics 617", DRIVER_INTEL_HD4000, 2048}, {HW_VENDOR_INTEL, CARD_INTEL_UHD620, "Intel(R) UHD Graphics 620", DRIVER_INTEL_HD4000, 3072}, + {HW_VENDOR_INTEL, CARD_INTEL_HD615, "Intel(R) HD Graphics 615", DRIVER_INTEL_HD4000, 2048}, {HW_VENDOR_INTEL, CARD_INTEL_HD620, "Intel(R) HD Graphics 620", DRIVER_INTEL_HD4000, 3072}, {HW_VENDOR_INTEL, CARD_INTEL_HD630_1, "Intel(R) HD Graphics 630", DRIVER_INTEL_HD4000, 3072}, {HW_VENDOR_INTEL, CARD_INTEL_HD630_2, "Intel(R) HD Graphics 630", DRIVER_INTEL_HD4000, 3072}, diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index f86853e9c9..b08a843f7f 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -2640,6 +2640,7 @@ enum wined3d_pci_device CARD_INTEL_IPP580_2 = 0x193d, CARD_INTEL_UHD617 = 0x87c0, CARD_INTEL_UHD620 = 0x3ea0, + CARD_INTEL_HD615 = 0x591e, CARD_INTEL_HD620 = 0x5916, CARD_INTEL_HD630_1 = 0x5912, CARD_INTEL_HD630_2 = 0x591b, -- 2.21.0

Nov. 29, 2019

[PATCH] ddraw/tests: Skip test_colorkey_precision() test on WARP.

by Paul Gofman

Fixes ddraw7 test crashes in Testbow(w10). Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> --- The test was already mostly marked broken on WARP due to Win8 WARP failures. dlls/ddraw/tests/ddraw7.c | 111 +++++++++++++++++++------------------- 1 file changed, 56 insertions(+), 55 deletions(-) diff --git a/dlls/ddraw/tests/ddraw7.c b/dlls/ddraw/tests/ddraw7.c index be59c7d3ac..ee77474f74 100644 --- a/dlls/ddraw/tests/ddraw7.c +++ b/dlls/ddraw/tests/ddraw7.c @@ -11040,21 +11040,7 @@ static void test_colorkey_precision(void) {{ 1.0f, -1.0f, 0.0f}, {1.0f, 1.0f}}, {{ 1.0f, 1.0f, 0.0f}, {1.0f, 0.0f}}, }; - IDirect3DDevice7 *device; - IDirect3D7 *d3d; - IDirectDraw7 *ddraw; - IDirectDrawSurface7 *rt; - HWND window; - HRESULT hr; - IDirectDrawSurface7 *src, *dst, *texture; - DDSURFACEDESC2 surface_desc, lock_desc; - ULONG refcount; - D3DCOLOR color; - unsigned int t, c; - DDCOLORKEY ckey; - DDBLTFX fx; - DWORD data[4] = {0}, color_mask; - BOOL is_nvidia, is_warp; + static const struct { unsigned int max, shift, bpp, clear; @@ -11097,6 +11083,22 @@ static void test_colorkey_precision(void) }, }; + IDirectDrawSurface7 *src, *dst, *texture; + DDSURFACEDESC2 surface_desc, lock_desc; + DWORD data[4] = {0}, color_mask; + IDirect3DDevice7 *device; + IDirectDrawSurface7 *rt; + IDirectDraw7 *ddraw; + unsigned int t, c; + DDCOLORKEY ckey; + IDirect3D7 *d3d; + BOOL is_nvidia; + ULONG refcount; + D3DCOLOR color; + HWND window; + HRESULT hr; + DDBLTFX fx; + window = create_window(); if (!(device = create_device(window, DDSCL_NORMAL))) { @@ -11106,40 +11108,43 @@ static void test_colorkey_precision(void) } hr = IDirect3DDevice7_GetDirect3D(device, &d3d); - ok(SUCCEEDED(hr), "Failed to get Direct3D7 interface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3D7_QueryInterface(d3d, &IID_IDirectDraw7, (void **)&ddraw); - ok(SUCCEEDED(hr), "Failed to get DirectDraw7 interface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); IDirect3D7_Release(d3d); hr = IDirect3DDevice7_GetRenderTarget(device, &rt); - ok(SUCCEEDED(hr), "Failed to get render target, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); is_nvidia = ddraw_is_nvidia(ddraw); /* The Windows 8 WARP driver has plenty of false negatives in X8R8G8B8 * (color key doesn't match although the values are equal), and a false * positive when the color key is 0 and the texture contains the value 1. - * I don't want to mark this broken unconditionally since this would - * essentially disable the test on Windows. Also on random occasions - * 254 == 255 and 255 != 255.*/ - is_warp = ddraw_is_warp(ddraw); + * Also on random occasions 254 == 255 and 255 != 255. + * Crashes on Windows 10 WARP. */ + if (ddraw_is_warp(ddraw)) + { + win_skip("Skipping test on WARP driver.\n"); + goto done; + } hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_LIGHTING, FALSE); - ok(SUCCEEDED(hr), "Failed to disable lighting, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_ZENABLE, D3DZB_FALSE); - ok(SUCCEEDED(hr), "Failed to disable z-buffering, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_COLORKEYENABLE, TRUE); - ok(SUCCEEDED(hr), "Failed to enable color keying, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); /* Multiply the texture read result with 0, that way the result color if the key doesn't * match is constant. In theory color keying works without reading the texture result * (meaning we could just op=arg1, arg1=tfactor), but the Geforce7 Windows driver begs * to differ. */ hr = IDirect3DDevice7_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_MODULATE); - ok(SUCCEEDED(hr), "Failed to set color op, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_SetTextureStageState(device, 0, D3DTSS_COLORARG1, D3DTA_TEXTURE); - ok(SUCCEEDED(hr), "Failed to set color arg, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_SetTextureStageState(device, 0, D3DTSS_COLORARG2, D3DTA_TFACTOR); - ok(SUCCEEDED(hr), "Failed to set color arg, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_TEXTUREFACTOR, 0x00000000); - ok(SUCCEEDED(hr), "Failed to set render state, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); memset(&fx, 0, sizeof(fx)); fx.dwSize = sizeof(fx); @@ -11164,9 +11169,9 @@ static void test_colorkey_precision(void) /* Windows XP (at least with the r200 driver, other drivers untested) produces * garbage when doing color keyed texture->texture blits. */ hr = IDirectDraw7_CreateSurface(ddraw, &surface_desc, &src, NULL); - ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirectDraw7_CreateSurface(ddraw, &surface_desc, &dst, NULL); - ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); U5(fx).dwFillColor = tests[t].clear; /* On the w8 testbot (WARP driver) the blit result has different values in the @@ -11184,15 +11189,15 @@ static void test_colorkey_precision(void) surface_desc.ddckCKSrcBlt.dwColorSpaceLowValue = c << tests[t].shift; surface_desc.ddckCKSrcBlt.dwColorSpaceHighValue = c << tests[t].shift; hr = IDirectDraw7_CreateSurface(ddraw, &surface_desc, &texture, NULL); - ok(SUCCEEDED(hr), "Failed to create surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_SetTexture(device, 0, texture); - ok(SUCCEEDED(hr), "Failed to set texture, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirectDrawSurface7_Blt(dst, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &fx); - ok(SUCCEEDED(hr), "Failed to clear destination surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirectDrawSurface7_Lock(src, NULL, &lock_desc, DDLOCK_WAIT, NULL); - ok(SUCCEEDED(hr), "Failed to lock surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); switch (tests[t].bpp) { case 4: @@ -11210,21 +11215,21 @@ static void test_colorkey_precision(void) break; } hr = IDirectDrawSurface7_Unlock(src, 0); - ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirectDrawSurface7_Blt(texture, NULL, src, NULL, DDBLT_WAIT, NULL); - ok(SUCCEEDED(hr), "Failed to blit, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); ckey.dwColorSpaceLowValue = c << tests[t].shift; ckey.dwColorSpaceHighValue = c << tests[t].shift; hr = IDirectDrawSurface7_SetColorKey(src, DDCKEY_SRCBLT, &ckey); - ok(SUCCEEDED(hr), "Failed to set color key, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirectDrawSurface7_Blt(dst, NULL, src, NULL, DDBLT_KEYSRC | DDBLT_WAIT, NULL); - ok(SUCCEEDED(hr), "Failed to blit, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); /* Don't make this read only, it somehow breaks the detection of the Nvidia bug below. */ hr = IDirectDrawSurface7_Lock(dst, NULL, &lock_desc, DDLOCK_WAIT, NULL); - ok(SUCCEEDED(hr), "Failed to lock surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); switch (tests[t].bpp) { case 4: @@ -11242,7 +11247,7 @@ static void test_colorkey_precision(void) break; } hr = IDirectDrawSurface7_Unlock(dst, 0); - ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); if (!c) { @@ -11284,38 +11289,34 @@ static void test_colorkey_precision(void) (c + 1) << tests[t].shift, data[2], tests[t].name, c); hr = IDirect3DDevice7_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0x0000ff00, 1.0f, 0); - ok(SUCCEEDED(hr), "Failed to clear, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_BeginScene(device); - ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_DrawPrimitive(device, D3DPT_TRIANGLESTRIP, D3DFVF_XYZ | D3DFVF_TEX1, quad, 4, 0); - ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); hr = IDirect3DDevice7_EndScene(device); - ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); + ok(hr == DD_OK, "Got unexpected hr %#x.\n", hr); color = get_surface_color(rt, 80, 240); + if (!c) - ok(compare_color(color, 0x0000ff00, 1) || broken(is_warp && compare_color(color, 0x00000000, 1)), - "Got unexpected color 0x%08x, format %s, c=%u.\n", + ok(compare_color(color, 0x0000ff00, 1), "Got unexpected color 0x%08x, format %s, c=%u.\n", color, tests[t].name, c); else - ok(compare_color(color, 0x00000000, 1) || broken(is_warp && compare_color(color, 0x0000ff00, 1)), - "Got unexpected color 0x%08x, format %s, c=%u.\n", + ok(compare_color(color, 0x00000000, 1), "Got unexpected color 0x%08x, format %s, c=%u.\n", color, tests[t].name, c); color = get_surface_color(rt, 240, 240); - ok(compare_color(color, 0x0000ff00, 1) || broken(is_warp && compare_color(color, 0x00000000, 1)), - "Got unexpected color 0x%08x, format %s, c=%u.\n", + ok(compare_color(color, 0x0000ff00, 1), "Got unexpected color 0x%08x, format %s, c=%u.\n", color, tests[t].name, c); color = get_surface_color(rt, 400, 240); if (c == tests[t].max) - ok(compare_color(color, 0x0000ff00, 1) || broken(is_warp && compare_color(color, 0x00000000, 1)), - "Got unexpected color 0x%08x, format %s, c=%u.\n", + ok(compare_color(color, 0x0000ff00, 1), "Got unexpected color 0x%08x, format %s, c=%u.\n", color, tests[t].name, c); else - ok(compare_color(color, 0x00000000, 1) || broken(is_warp && compare_color(color, 0x0000ff00, 1)), - "Got unexpected color 0x%08x, format %s, c=%u.\n", + ok(compare_color(color, 0x00000000, 1), "Got unexpected color 0x%08x, format %s, c=%u.\n", color, tests[t].name, c); IDirectDrawSurface7_Release(texture); -- 2.23.0

Nov. 29, 2019

Re: [PATCH v2 2/6] wined3d: Introduce wined3d_stateblock_get_state().

by Zebediah Figura

On 11/29/19 1:25 AM, Henri Verbeet wrote: > On Thu, 28 Nov 2019 at 09:24, Zebediah Figura <z.figura12(a)gmail.com> wrote: >> +#define LIGHTMAP_SIZE 43 >> +#define LIGHTMAP_HASHFUNC(x) ((x) % LIGHTMAP_SIZE) > > Although wined3d is an internal Wine interface, it still seems > unfortunate to expose this particular implementation detail in the > public wined3d interface. > Understandable, though I'm not immediately sure what do about it. We could introduce individual wined3d_stateblock_get_*() helpers, though at the last point of conversation regarding stateblocks, I recall you seemed to prefer allowing direct access to struct wined3d_stateblock_state. I guess another option is to hold a pointer to wined3d_light_state instead of exposing it directly.

Nov. 29, 2019