March 2015 - Wine-Devel - list.winehq.org

Re: [PATCH] vbscript: Implemented Asc(try 2)

by Nikolay Sivov

On 03.03.2015 18:00, Shuai Meng wrote: > > > 2015-03-03 18:09 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com > <mailto:bunglehead(a)gmail.com>>: > > You're still leaking memory. > > > Thanks for commenting~ But I would be appreciated if you can explain > this more explicitly, I am not quite familiar with the string functions. Take a look at what to_string() does - you're supposed to free what it returns.

March 3, 2015

GSOC 2015 Applicant

by Balkrishna Srivastava

Hi, I am Balkrishna Srivastava, a 3rd year dual degree undergraduate from BITS Pilani, Pilani Campus, India. I completed my computer programming course in C. I have also been doing extensive competitive coding on codechef.com in c ( profile: http://www.codechef.com/users/bali161616 ). I wish to contribute to your organisation this GSOC. I know c, java, python and c++. Please guide me how to go about contributing to your organization. -- *Regards* *BALKRISHNA SRIVASTAVA* *Undergraduate Student* *B.E.(Hons.) Computer Science* *M.Sc.(Hons.) Physics* *▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄* *Birla Institute of Technology & Science,* *Pilani*

March 3, 2015

Re: rpcrt4: Fix argument check in MesEncodeFixedBufferHandleCreate()

by Nikolay Sivov

On 03.03.2015 15:38, Dmitry Timoshkov wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > >> + if (((ULONG_PTR)Buffer % 8) != 0) >> + return RPC_X_INVALID_BUFFER; > Shouldn't this be 'if ((ULONG_PTR)Buffer & 7)' instead? > Result would be the same. If you mean that it's faster I have to admit that I didn't check if generated code is different.

March 3, 2015

Re: include: add initial d3dx10core.h

by Matteo Bruni

2015-03-03 13:21 GMT+01:00 Matteo Bruni <matteo.mystral(a)gmail.com>: > Can you replace the names of the methods arguments with some > non-Hungarian alternatives? If nothing else, just to avoid having > those declarations match those in the MS header character by > character. > > Also please avoid tabs. Nikolay suggested on IRC to write this header in IDL for Wine. That would be a better option if it works (it should).

March 3, 2015

Re: rpcrt4: Fix argument check in MesEncodeFixedBufferHandleCreate()

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + if (((ULONG_PTR)Buffer % 8) != 0) > + return RPC_X_INVALID_BUFFER; Shouldn't this be 'if ((ULONG_PTR)Buffer & 7)' instead? -- Dmitry.

March 3, 2015

Re: rpcrt4: Fix argument check in MesEncodeFixedBufferHandleCreate()

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://testbot.winehq.org/JobDetails.pl?Key=11860 Your paranoid android. === build (build) === Patch failed to apply

March 3, 2015

Re: include: add initial d3dx10core.h

by Matteo Bruni

Can you replace the names of the methods arguments with some non-Hungarian alternatives? If nothing else, just to avoid having those declarations match those in the MS header character by character. Also please avoid tabs.

March 3, 2015

Re: [PATCH 3/4] d3d9/tests: Add a test for signed formats.

by Stefan Dösinger

2015-03-03 12:22 GMT+01:00 Matteo Bruni <matteo.mystral(a)gmail.com>: > For the 8-bit format you mean that 1 is not representable in the > signed u/v components, correct? > Also "singed" typo, but otherwise good to me. 1 and -1 (the signed input value, not the post-scaled -1.0 and 1.0) are missing from U and V, yeah. The reason is that this way I can reuse the expected color array. Q in D3DFMT_Q8W8V8U8 tests some 8 bit specific values. I'll see if I can clarify that comment a bit. >> + {0x4067, 0x53b9, 0x0421, 0xffff}, /* 0x4067, 0x53b9, 0x0421, 0xffff */ >> + {0x8108, 0x0318, 0xc28c, 0x909c}, /* 0x8108, 0x0318, 0xc28c, 0x909c */ >> + }; > > What did you mean to put in the comments here? Those currently there > match the actual content of the array. I thought I removed those comments. It was a sort of backup of the values while I experimented with the problem Geforce 7 cards have. > This is clearly my brain failing right now, but why is blue expected > to be 0xff when the texture component is missing? All formats return 1.0 for channels that aren't defined by the format. E.g. D3DFMT_G32R32F returns R, G, 1.0, 1.0. That differs from GL, which returns 1.0 for alpha and 0.0 for color channels. > Cool additional test for UpdateSurface, thank you for that. > Here and in the previous test I guess you might want to put the > slop_broken check into a broken(), unless that also fails on Linux. I also think I fixed that before sending. I wonder if I forgot a git commit --amend...

March 3, 2015

Re: [PATCH 3/4] d3d9/tests: Add a test for signed formats.

by Matteo Bruni

2015-03-02 22:29 GMT+01:00 Stefan Dösinger <stefan(a)codeweavers.com>: > + /* The input data was designed for D3DFMT_L6V5U5 and then transfered > + * to the other formats because L6V5U5 is the lowest precision format. > + * It tests the extreme values -1.0 (-16) and 1.0 (15) for U/V and > + * 0.0 (0) and 1.0 (63) for L, the neutral point 0 as well as -1 and 1. > + * Some other intermediate values are tested too. For the 8 bit formats > + * the equivalents of -1 and 1 are -8 and 8, that's why there is no > + * 0xffff input for these formats. The input value -15 (min + 1) is > + * tested as well. Unlike what OpenGL 4.4 says in section 2.3.4.1, this > + * value does not represent -1.0. For 8 bit singed data -127 is tested > + * in the Q channel of D3DFMT_Q8W8V8U8. Here d3d seems to follow the > + * rules from the GL spec. AMD's r200 is broken though and returns a > + * value < -1.0 for -128. The difference between using -127 or -128 as > + * the lowest possible value gets lost in the slop of 1 though. */ For the 8-bit format you mean that 1 is not representable in the signed u/v components, correct? Also "singed" typo, but otherwise good to me. > + static const USHORT content_v8u8[4][4] = > + { > + {0x0000, 0x7f7f, 0x8880, 0x0000}, > + {0x0080, 0x8000, 0x7f00, 0x007f}, > + {0x193b, 0xe8c8, 0x0808, 0xf8f8}, > + {0x4444, 0xc0c0, 0xa066, 0x22e0}, > + }; > + static const DWORD content_v16u16[4][4] = > + { > + {0x00000000, 0x7fff7fff, 0x88008000, 0x00000000}, > + {0x00008000, 0x80000000, 0x7fff0000, 0x00007fff}, > + {0x19993bbb, 0xe800c800, 0x08880888, 0xf800f800}, > + {0x44444444, 0xc000c000, 0xa0006666, 0x2222e000}, > + }; > + static const DWORD content_q8w8v8u8[4][4] = > + { > + {0x00000000, 0xff7f7f7f, 0x7f008880, 0x817f0000}, > + {0x10000080, 0x20008000, 0x30007f00, 0x4000007f}, > + {0x5020193b, 0x6028e8c8, 0x70020808, 0x807ff8f8}, > + {0x90414444, 0xa000c0c0, 0x8261a066, 0x834922e0}, > + }; > + static const DWORD content_x8l8v8u8[4][4] = > + { > + {0x00000000, 0x00ff7f7f, 0x00008880, 0x00ff0000}, > + {0x00000080, 0x00008000, 0x00007f00, 0x0000007f}, > + {0x0041193b, 0x0051e8c8, 0x00040808, 0x00fff8f8}, > + {0x00824444, 0x0000c0c0, 0x00c2a066, 0x009222e0}, > + }; > + /* D3DFMT_L6V5U5 has poor precision on some GPUs. On a GeForce 7 the highest U and V value (15) > + * results in the output color 0xfb, which is 4 steps away from the correct value 0xff. It is > + * not the ~0xf0 you'd get if you blindly left-shifted the 5 bit values to form an 8 bit value > + * though. > + * > + * There may also be an off-by-one bug involved: The value -7 should result in the output 0x47, > + * but ends up as 0x4d. Likewise, -3 becomes 0x6e instead of 0x67. Those values are close to > + * the proper results of -6 and -2. */ > + static const USHORT content_l6v5u5[4][4] = > + { > + {0x0000, 0xfdef, 0x0230, 0xfc00}, > + {0x0010, 0x0200, 0x01e0, 0x000f}, > + {0x4067, 0x53b9, 0x0421, 0xffff}, /* 0x4067, 0x53b9, 0x0421, 0xffff */ > + {0x8108, 0x0318, 0xc28c, 0x909c}, /* 0x8108, 0x0318, 0xc28c, 0x909c */ > + }; What did you mean to put in the comments here? Those currently there match the actual content of the array. > + for (y = 0; y < 4; y++) > + { > + for (x = 0; x < tests[j].width; x++) > + { > + expected_color = expected_colors[y][x]; > + if (!formats[i].blue) > + expected_color |= 0x000000ff; This is clearly my brain failing right now, but why is blue expected to be 0xff when the texture component is missing? > + hr = IDirect3DTexture9_GetSurfaceLevel(texture, 0, &dst_surface); > + ok(SUCCEEDED(hr), "Failed to get surface, hr %#x.\n", hr); > + IDirect3DTexture9_GetSurfaceLevel(texture_sysmem, 0, &src_surface); > + ok(SUCCEEDED(hr), "Failed to get surface, hr %#x.\n", hr); > + > + hr = IDirect3DDevice9_UpdateSurface(device, src_surface, > + &tests[j].src_rect, dst_surface, &tests[j].dst_point); > + ok(SUCCEEDED(hr), "Failed to update surface, hr %#x.\n", hr); > + > + IDirect3DSurface9_Release(dst_surface); > + IDirect3DSurface9_Release(src_surface); > + > + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0x00003300, 0.0f, 0); > + ok(SUCCEEDED(hr), "Failed to clear, hr %#x.\n", hr); > + hr = IDirect3DDevice9_BeginScene(device); > + ok(SUCCEEDED(hr), "Failed to begin scene, hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, &quad[0], sizeof(*quad)); > + ok(SUCCEEDED(hr), "Failed to draw, hr %#x.\n", hr); > + hr = IDirect3DDevice9_EndScene(device); > + ok(SUCCEEDED(hr), "Failed to end scene, hr %#x.\n", hr); > + > + for (y = 0; y < 4; y++) > + { > + for (x = 0; x < tests[j].width; x++) > + { > + if (tests[j].width == 4) > + expected_color = expected_colors2[y][x]; > + else > + expected_color = expected_colors3[y]; > + > + if (!formats[i].blue) > + expected_color |= 0x000000ff; > + > + color = getPixelColor(device, 80 + 160 * x, 60 + 120 * y); > + ok(color_match(color, expected_color, 1) > + || color_match(color, expected_color, formats[i].slop_broken), > + "Expected color 0x%08x, got 0x%08x, format %s, location %ux%u.\n", > + expected_color, color, formats[i].name, x, y); > + } > + } Cool additional test for UpdateSurface, thank you for that. Here and in the previous test I guess you might want to put the slop_broken check into a broken(), unless that also fails on Linux.

March 3, 2015

Re: [PATCH 1/4] wined3d: Properly up-scale WINED3DFMT_R5G5_SNORM_L6_UNORM.

by Matteo Bruni

2015-03-02 22:29 GMT+01:00 Stefan Dösinger <stefan(a)codeweavers.com>: > Simply left-shifting is not enough in positive ranges. 0xff / 255 != > 0xff00 / 65535. > > Using the compiler to read 5 bit signed values seems a lot easier than > operating with masks. > --- > dlls/wined3d/utils.c | 44 +++++++++++++++++++++++++------------------- > 1 file changed, 25 insertions(+), 19 deletions(-) > > diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c > index 1ce23ac..67457d5 100644 > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -290,6 +290,15 @@ static void convert_l4a4_unorm(const BYTE *src, BYTE *dst, UINT src_row_pitch, U > } > } > > +#include <pshpack1.h> > +struct r5g5l6 > +{ > + signed r : 5; > + signed g : 5; > + unsigned l : 6; > +}; > +#include <poppack.h> > + AFAIK C doesn't give any guarantee on a specific allocation of bitfields in memory. I'm sure this works in practice with GCC and maybe also with the other compilers we care about, but if it doesn't get too ugly I'd prefer explicit shifts and masks and be safe. In any case, this should use signed / unsigned short at least.

March 3, 2015