September 2012 - Wine-Devel

Re: d3dx9_36: Implement D3DXSHRotate

by Rico Schüller

I had another look and like to give some suggestion. On 02.09.2012 22:28, Nozomi Kodama wrote: + sinb = sqrt( 1.0f - matrix->u.m[2][2] * matrix->u.m[2][2] ); I'd prefer to declare the variables as locally as possible. + D3DXSHRotateZ(temp5, order, alpha, temp4); + memcpy(out, temp5, sizeof(float) * order * order); + + return out; You probably may avoid the memcpy. What do you think about something like: return D3DXSHRotateZ(out, order, alpha, temp4); + FLOAT alpha, beta, gamma, sinb, temp1[36], temp2[36], temp3[36], temp4[36], temp5[36]; Do we really need that much temps? I think one is enough, but definitively 2 (I think you are able to use out as one "temp"). If you don't like the usage of out, you may use temp2 instead, but I think it could be avoided. D3DXSHRotateZ(out, order, gamma, in); RotateX(temp, order, 1, out); D3DXSHRotateZ(out, order, beta, temp); RotateX(temp, order, 0, out); D3DXSHRotateZ(out, order, alpha, temp); +static FLOAT* RotateX(FLOAT *out, UINT order, UINT pm, FLOAT *in) The return value is never used. Probably you may return void or you'd like to stack the function calls above a bit and reuse the returned pointer. You also may use "BOOL pm" since it uses only 0 and 1 or you may pass the "FLOAT a" directly to the function. Whatever pm stands for... Cheers Rico

Sept. 3, 2012

Re: [PATCH 1/3] kernel32: Support UTF-7 in MultiByteToWideChar.

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > I was asked to split this patch up, so I did. The complaint about the > last version was "You are still overflowing the source." I have not > been able to find any test case that my implementation handled > incorrectly, however, I did find that (*src == 0 && srclen < 0) will > never evaluate to true, so I removed this if statement from the code. I > also changed example #2 in the tests to be slightly more stringent, but > the last patch would also have passed. > > If this patch series is rejected, please show me a test case that > demonstrates what I am doing wrong. You don't have a single test with an explicit source length, so obviously you are not going to find problems in that area. Like I said, you need a lot more tests. -- Alexandre Julliard julliard(a)winehq.org

Sept. 3, 2012

Re: [PATCH] kernel32: add condition variables prototypes and tests (2nd try)

by Francois Gouget

On Sun, 2 Sep 2012, Vincent Povirk wrote: > >> Probably this should be a win_slip(). > > > > The function exists only since Windows 7/Vista (not XP) and is not yet > > in Wine (and might take a while, as my time is limited currently > > and my knowledge of this specific function same). > > > > So I think "skip" is currently the right thing ;) > > I think a "todo_wine win_skip" is appropriate for cases where Wine > should have an implementation but doesn't yet. Absolutely. With a plain 'skip' we won't know that we have to change the test when the implementation is added to Wine whereas the 'todo win_skip' will make that clear. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

Sept. 3, 2012

Re: d3dx9_36: Implement D3DXSHRotate

by Rico Schüller

On 02.09.2012 23:46, Nozomi Kodama wrote: > For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So > we must check whether it is acceptable for other D3DXSH functions to > give such an order. If it is not acceptable, then we must know what the > function returns. Yes, they do and I agree with you. But why do you chose to try from 0 to 9 (<10) instead of 0-7 (<8) - which I think is enough and nothing more changes? (It includes the first round of not touched values.) Asking the other way around, why don't you try lets say till 1000? I guess the easy answer is, because the output values won't be touched for orders >6. The test results show the same for the tests 7-9 (and would til 1000) and thus testing for 7 is enough, testing 8 and 9 brings no new information, beside you would miss to test from 10 to open end. > > For the out of bound problem, I agree that we reach an out of bound. But > it is not a problem, since for such an index, expected is defined by an > other value. > If there is a complaining compiler about this, I can modify the tests > though. I'm not sure if the compiler is complaining, but I think it's much better to set it in the else case. You may get an unhandled exception and this is not what the software should do in the first place, it should run and not produce exceptions! :-) The same is done in test_D3DXSHRotateZ, which I'm not happy about it. Cheers Rico

Sept. 3, 2012

Re: wined3d: Use backup swapchain DC for devices created with desktop window.

by Henri Verbeet

On 3 September 2012 00:51, Adam Jakubek <ajakubek(a)gmail.com> wrote: > Hi, > > This patch causes wined3d to use backup swapchain DC when > IDirect3DDevice9 is created using the desktop window. > Windows allows to create such device as long its type is > D3DDEVTYPE_REF or D3DDEVTYPE_NULLREF. > > Unpatched Wine will fail in IDirect3D9_CreateDevice method, since it > incorrectly uses the X root window. > > Relevant d3d test case is included. > Patch closes bug #18490. > How is actual rendering to the desktop window supposed to work?

Sept. 3, 2012

Re: Building winetest-latest.exe?

by Vincent Povirk

As I understand it, you need to set up a mingw build as in http://wiki.winehq.org/CompilingDLLsUsingMingw

Sept. 3, 2012

Building winetest-latest.exe?

by Dan Kegel

Hi folks, how does one build the native version of winetest.exe? I looked around a bit, and didn't see any obvious instructions. http://www.winehq.org/pipermail/wine-devel/2011-July/091144.html touches on it, but doesn't say much. I ask because I'm interested in tracking down why testbot doesn't think vcomp.dll is installed. ( cf. http://www.winehq.org/pipermail/wine-devel/2012-August/096642.html ) - Dan

Sept. 3, 2012

Re: wined3d: Use backup swapchain DC for devices created with desktop window.

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 http://testbot.winehq.org/JobDetails.pl?Key=21350 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PRO (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === W7PROX64 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a. === TEST64_W7SP1 (64 bit device) === device.c:3541: Test failed: Failed to create REF device using desktop window, hr 0x8876086a.

Sept. 2, 2012

Re : d3dx9_36: Implement D3DXSHRotate

by Nozomi Kodama

For instance, D3DXSHAdd and D3DXSHDot accept order>D3DXSH_MAXORDER. So we must check whether it is acceptable for other D3DXSH functions to give such an order. If it is not acceptable, then we must know what the function returns. For the out of bound problem, I agree that we reach an out of bound. But it is not a problem, since for such an index, expected is defined by an other value. If there is a complaining compiler about this, I can modify the tests though. Nozomi

Sept. 2, 2012

Re: d3dx9_36: Implement D3DXSHRotate

by Rico Schüller

On 02.09.2012 22:28, Nozomi Kodama wrote: > > + for (order = 0; order < 10; order++) > Is there a reason why we'd want to test til 9? D3DXSH_MAXORDER is 6, so 7 Should be enough? I know the other test do this, but technically I see no reason for that. Specifically the if (.. order > D3DXSH_MAXORDER) says exactly that, so no need to further than 7, since the parameters or did I miss something? I guess you'd also out of bounds? table[36 * j + i]; (for j=3 and i=99 => 207) since the table only has 4*36 => 144 elements. Cheers Rico

Sept. 2, 2012