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

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Henri Verbeet

On 8 January 2014 14:30, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2014-01-08 13:13, schrieb Stefan Dösinger: >> I’ll test Prince of Persia 3D once I’m back on Linux with your >> patches. This game uses color keys, and I am fairly sure it uses >> mipmapped textures. I don’t know if it combines those two though. > Patch 1 breaks Prince of Persia 3D (Wine appdb id 3743). It doesn't > break quite in the way I expected though. Instead of gates with broken > transparency it draws a mostly black screen, with only torch flames > visible. > It's probably best to hold of on at least the first two patches in this series then.

Jan. 8, 2014

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-08 13:13, schrieb Stefan Dösinger: > I’ll test Prince of Persia 3D once I’m back on Linux with your > patches. This game uses color keys, and I am fairly sure it uses > mipmapped textures. I don’t know if it combines those two though. Patch 1 breaks Prince of Persia 3D (Wine appdb id 3743). It doesn't break quite in the way I expected though. Instead of gates with broken transparency it draws a mostly black screen, with only torch flames visible. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzVLpAAoJEN0/YqbEcdMw+noP/0TSK10PmzDd8NSARH6K7itd C664s6XuAhokmFSrAVD5chis3o2gvjoay949Iz59w2N8DIXFnqNdPsNy+8zbfbWz fwPDQRJX8+3ueBXiz34E2c3ocM/iyZ7VGB+2jkMZFh5y8GSNdwR5BjbKH3Hzx1W+ gpcg/LD/YLFtE3yDH0Mwp5rknQfzBuBEqfGidUCg7/oUsDneomDd6j0FTj4I44j3 hkKHufSrO3phmTL9XEwG47s2acvWbMhq1s3aCl53iBTvRfxh8fT/lpGGipu0XKE5 fexxM9aqCAcopctaZZcFiycLgOvhJOJcnckv7an2m4j0kdZnq0Y/ZWlMjaDi/7Tn wbddfkmig73+TQ72uavkkpaUvNZLZorXULK3PNcorAlMaQ3BmHgRZVHQua/kp4Ku 1OUkCM/GpianKZKanP0b0gVWrloW0rgBvcz4jOUTsLkZ1Rrf2qqdIt2KFzXO8a2E 2pTNhu3tdMCahYUQGYj5asCWmJMweSV5T61rLPl+QSUm6ZSIq4xulOd++vTp38xU 5qNDHJ81oROuoMEqE1T4xNrRtPWZKibsRx9SRnzcCj/+e+ePTCxMjIs/kA7uMODr KB/FcRuy/ByNpWl3g9RXqFh5oVPWELBO+XZrRg/fsnjqsYeL3YR9sP6gn4vHwsc4 QrrV7isa0jsR/MtIYAiW =vbGu -----END PGP SIGNATURE-----

Jan. 8, 2014

Re: dpnet: Add stubbed interface IDirectPlay8Server

by Michael Stefaniuc

Hello Alistair, On 01/08/2014 06:26 AM, Alistair Leslie-Hughes wrote: > Changelog: > dpnet: Add stubbed interface IDirectPlay8Server > diff --git a/dlls/dpnet/dpnet_private.h b/dlls/dpnet/dpnet_private.h > index 72012cd..5195d51 100644 > --- a/dlls/dpnet/dpnet_private.h > +++ b/dlls/dpnet/dpnet_private.h > @@ -37,6 +37,7 @@ typedef struct IDirectPlay8AddressImpl IDirectPlay8AddressImpl; > typedef struct IDirectPlay8LobbiedApplicationImpl IDirectPlay8LobbiedApplicationImpl; > typedef struct IDirectPlay8PeerImpl IDirectPlay8PeerImpl; > typedef struct IDirectPlay8ThreadPoolImpl IDirectPlay8ThreadPoolImpl; > +typedef struct IDirectPlay8ServerImpl IDirectPlay8ServerImpl; please add the struct directly to server.c as it is used only there. > +static ULONG WINAPI IDirectPlay8ServerImpl_AddRef(IDirectPlay8Server *iface) > +{ > + IDirectPlay8ServerImpl *This = impl_from_IDirectPlay8Server(iface); > + ULONG refCount = InterlockedIncrement(&This->ref); > + > + TRACE("(%p)->(ref before=%u)\n", This, refCount - 1); The standard to which Wine moves is to print the current refcount. See http://wiki.winehq.org/COMGuideline under "COM aggregation" for sample AddRef / Release functions. > +HRESULT DPNET_CreateDirectPlay8Server(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) IClassFactory* and IUnknown* are much nicer. > +{ > + IDirectPlay8ServerImpl *server; > + > + TRACE("(%p, %s, %p)\n", punkOuter, debugstr_guid(riid), ppobj); > + > + server = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8ServerImpl)); > + if (!server) > + { > + *ppobj = NULL; > + return E_OUTOFMEMORY; > + } > + server->IDirectPlay8Server_iface.lpVtbl = &DirectPlay8ServerVtbl; > + server->ref = 1; > + > + *ppobj = (LPVOID*)&server->IDirectPlay8Server_iface; This will fail to fail for an unsupported riid. I have added the correct way to the COMGuideline wiki page. thanks bye michael

Jan. 8, 2014

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Stefan Dösinger

Am 08.01.2014 um 13:04 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 8 January 2014 12:40, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >>> I somewhat suspect it'll use the root >>> color key for 3D rendering and the key from individual surfaces for >>> blits. The current code is just wrong either way though. >> Did you test if it is possible to set a color key on a mipmap sublevel? >> > I just did, looks like it returns DDERR_NOTONMIPMAPSUBLEVEL. I guess that answers where the color keys for draws and blits involving mipmaps come from - assuming those operations even have a defined result. I’ll test Prince of Persia 3D once I’m back on Linux with your patches. This game uses color keys, and I am fairly sure it uses mipmapped textures. I don’t know if it combines those two though.

Jan. 8, 2014

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Henri Verbeet

On 8 January 2014 12:40, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: >> I somewhat suspect it'll use the root >> color key for 3D rendering and the key from individual surfaces for >> blits. The current code is just wrong either way though. > Did you test if it is possible to set a color key on a mipmap sublevel? > I just did, looks like it returns DDERR_NOTONMIPMAPSUBLEVEL.

Jan. 8, 2014

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Stefan Dösinger

Am 08.01.2014 um 12:01 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > I don't really know, but I suspect I'll find out soon enough if this > patch breaks something there. Ok, your call. > I somewhat suspect it'll use the root > color key for 3D rendering and the key from individual surfaces for > blits. The current code is just wrong either way though. Did you test if it is possible to set a color key on a mipmap sublevel?

Jan. 8, 2014

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Henri Verbeet

On 8 January 2014 11:46, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > What is the 3D rendering and blitting behavior of the mipmap sublevels? Does an application have to set the color key on all surfaces to get proper color keying on a mipmapped texture, or do the sublevels use the color key from the root surface? > I don't really know, but I suspect I'll find out soon enough if this patch breaks something there. I somewhat suspect it'll use the root color key for 3D rendering and the key from individual surfaces for blits. The current code is just wrong either way though.

Jan. 8, 2014

Re: dssenh/tests: Added Cylink Mek algorithm definition and crypto provider algorithm tests for dssenh.

by Alexandre Julliard

Marek Chmiel <kcmark(a)gmail.com> writes: > + while(GetLastError() != ERROR_NO_MORE_ITEMS) > + { > + SetLastError(0xdeadbeef); > + dataLen = sizeof(dataBuffer); > + > + result = CryptGetProvParam(hProv, PP_ENUMALGS_EX, dataBuffer, &dataLen, flag); > + ok(result || (!result && GetLastError() == ERROR_NO_MORE_ITEMS), > + "Failed to get parameter, got %x\n", GetLastError()); > + > + pointer = dataBuffer; > + algid = *(ALG_ID *)pointer; pointer += sizeof(ALG_ID); > + defaultLen = *(DWORD *)pointer; pointer += dwIncrement; It doesn't make sense to test last error before the first call, or to test the buffer contents on failure. -- Alexandre Julliard julliard(a)winehq.org

Jan. 8, 2014

Re: [PATCH 2/5] ddraw/tests: Add some color key tests for complex surfaces.

by Stefan Dösinger

Am 08.01.2014 um 10:56 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>: > + for (i = 0; i < 7; ++i) > + { > + hr = IDirectDrawSurface_GetAttachedSurface(mipmap, &caps, &tmp); > + ok(SUCCEEDED(hr), "Failed to get attached surface, i %u, hr %#x.\n", i, hr); > + hr = IDirectDrawSurface_GetColorKey(tmp, DDCKEY_SRCBLT, &color_key); > + ok(hr == DDERR_NOCOLORKEY, "Got unexpected hr %#x, i %u.\n", hr, i); > + IDirectDrawSurface_Release(mipmap); > + mipmap = tmp; > + } What is the 3D rendering and blitting behavior of the mipmap sublevels? Does an application have to set the color key on all surfaces to get proper color keying on a mipmapped texture, or do the sublevels use the color key from the root surface?

Jan. 8, 2014

Re: shell32/tests: Add test for SHGetPathFromIDListA (try 3)

by Nikolay Sivov

On 1/8/2014 12:47, Zhenbo Li wrote: > try 3: > Add 'static' in my code > I forgot to call test_SHGetPathFromIDListA() in try2 > Check GetLastError() as well > try 2: > Move code to string.c to avoid creating a new file. > Avoid malloc() and free(). > > I'm working on Bug 33750, so I'll add test cases for > SHGetPathFromIDListA gradually. > --- > dlls/shell32/tests/string.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > +static void test_SHGetPathFromIDListA(void) > +{ > + BOOL ret; > + char pszPath[MAX_PATH]; > + > + ret = SHGetPathFromIDListA(NULL, pszPath); > + ok(!ret, "SHGetPathFromIDListA should fail.\n"); > + ok(GetLastError() == ERROR_PROC_NOT_FOUND, > + "Bad GetLastError = %d\n", GetLastError()); > +} > + You need to set last error to something like 0xdeadbeef, your test suggest that this call doesn't set it. I guess you're trying to test return value only, but it could be interesting to test what happens to path buffer too. P.S. please avoid psz* style prefixes in names.

Jan. 8, 2014