September 2014 - Wine-Devel

Re: wined3d: Correctly display fog for right-handed projection matrix (try 3)

by Matteo Bruni

2014-09-30 11:33 GMT+02:00 Joachim Priesner <joachim.priesner(a)web.de>: Hi Joachim, > When using a right-handed projection matrix, z coordinates of vertices may be negative. This is not considered in the code generating the GLSL fog shader for fixed-function fog. The patch fixes that and adds a test. > > Tested on openSUSE 13.1 and Windows 8.1. > > Try 3 with tests using pixel shaders and tests for d3d8. I have not included tests using vertex shaders since the bug is in Wine's FFP implementation, so using vertex shaders would not touch the relevant code path. If I understood Henri's comment to the previous iteration of this patch correctly, the point of the additional test is to make sure that the bug is really in the vertex FFP replacement code (as opposed to the pixel pipeline part). You could verify that by writing a negative value into oFog via a vertex shader (see e.g. vertex_shader_code_2 in visual.c) and checking the results of the rendering. For example you could draw a quad setting oFog to -0.5 for the vertices on the left side and 0.5 on the right side. If the pixel pipeline uses the value output by the vertex pipeline with no changes then you should get an horizontal fog gradient. If, on the other hand, it's the pixel pipe that takes the absolute value of the (interpolated) fog coefficient, you would get two mirrored gradients in the two halves of the quad. I'm sure Henri will correct me if I got it wrong. > Also I have not included ddraw tests since I could not even get the unchanged tests to run on either Linux or Windows and I feel I have spent *way* too much time on this one-line fix already, sorry :-) > Sorry you feel like that but we'd really like to have such fixes backed by tests, too many times "obvious" fixes turned out to be wrong when actually tested thoroughly.

Sept. 30, 2014

Re: comctl32: Display icon (if possible) and all supplied texts in TaskDialogIndirect

by Alexandre Julliard

Joachim Priesner <joachim.priesner(a)web.de> writes: > The TaskDialogIndirect function takes three texts: content, main instruction, and footer. The current implementation would only display the main instruction. Now all texts are displayed, concatenated by two newlines if necessary. > > Also, if the requested icon is one that is supported by MessageBoxW (error, warning, question, information), that icon is displayed. This should be made into a proper dialog instead. It's not a good fit for a message box. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2014

Re: [PATCH 1/5] gdi32: Don't overflow the buffer in GetGlyphOutline.

by Alexandre Julliard

Matteo Bruni <mbruni(a)codeweavers.com> writes: > The code already mixes tabs and spaces; since newer stuff seems to be > using spaces I'm using spaces for the new code too. I'm cleaning up the > lines nearby while at it. > It's quite a bit of code motion, hopefully the actual changes are still > readable enough. It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M d3dx9_36.dll -p d3dx9_36_test.exe.so mesh && touch mesh.ok mesh.c:4199: Test failed: Expected: 0, Got: 0.637207 mesh.c:4200: Test failed: Expected: 632928, Got: 0.464355 mesh.c:4201: Test failed: Expected: 0, Got: 0.00195312 mesh.c:4202: Test failed: Expected: 0, Got: 0.464355 mesh.c:4203: Test failed: Expected: 0, Got: 0.645508 mesh.c:4199: Test failed: Expected: 0, Got: 0.0786133 mesh.c:4200: Test failed: Expected: 632928, Got: 0.640625 ... -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2014

Re: [PATCH 3/5] wined3d: Fail to create shaders using more than the supported number of float constants.

by Matteo Bruni

2014-09-30 16:55 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 30 September 2014 14:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> + case WINED3D_SHADER_VERSION(1, 0): >> + case WINED3D_SHADER_VERSION(1, 1): >> + shader->limits.constant_bool = 0; >> + shader->limits.constant_int = 0; >> + shader->limits.packed_output = 12; >> + shader->limits.sampler = 0; >> + /* TODO: vs_1_1 has a minimum of 96 constants. What happens when >> + * a vs_1_1 shader is used on a vs_3_0 capable card that has 256 >> + * constants? */ >> + shader->limits.constant_float = min(256, vs_uniform_count); > Since you touched it... Fair enough ;) > Perhaps at least as interesting as what > happens when trying to create SM3 shaders that use more that 256 > constants is what happens when trying to create e.g. SM1 shaders that > use more than 96 constants. Interesting that I had that comment under my nose and somehow managed to ignore it. Sure, I'm going to add one or more tests for that. > Also note that aside from the somewhat questionable clamping of > "constant_float" to the uniform count, this is all just static const > data, and there's really no reason that every single shader needs its > own copy of it. I don't think there are a lot of users of > "constant_float" that don't already do that kind of clamping > themselves, so we should probably just fix the remaining ones, if any. Good idea. >> + switch (reg_maps->shader_version.type) >> + { >> + case WINED3D_SHADER_TYPE_VERTEX: >> + vertexshader_set_limits(shader); >> + break; >> + case WINED3D_SHADER_TYPE_GEOMETRY: >> + geometryshader_set_limits(shader); >> + break; >> + case WINED3D_SHADER_TYPE_PIXEL: >> + pixelshader_set_limits(shader); >> + break; >> + default: >> + FIXME("Unexpected shader type %u found.\n", reg_maps->shader_version.type); >> + } >> + >> reg_maps->constf = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >> sizeof(*reg_maps->constf) * ((constf_size + 31) / 32)); > But now you can use "shader->limits.constant_float" instead of "constf_size". Good point as well.

Sept. 30, 2014

Re: [PATCH 6/6] jscript: Added @set tests.

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=9140 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

Sept. 30, 2014

Re: [PATCH 3/5] wined3d: Fail to create shaders using more than the supported number of float constants.

by Henri Verbeet

On 30 September 2014 14:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + case WINED3D_SHADER_VERSION(1, 0): > + case WINED3D_SHADER_VERSION(1, 1): > + shader->limits.constant_bool = 0; > + shader->limits.constant_int = 0; > + shader->limits.packed_output = 12; > + shader->limits.sampler = 0; > + /* TODO: vs_1_1 has a minimum of 96 constants. What happens when > + * a vs_1_1 shader is used on a vs_3_0 capable card that has 256 > + * constants? */ > + shader->limits.constant_float = min(256, vs_uniform_count); Since you touched it... Perhaps at least as interesting as what happens when trying to create SM3 shaders that use more that 256 constants is what happens when trying to create e.g. SM1 shaders that use more than 96 constants. Also note that aside from the somewhat questionable clamping of "constant_float" to the uniform count, this is all just static const data, and there's really no reason that every single shader needs its own copy of it. I don't think there are a lot of users of "constant_float" that don't already do that kind of clamping themselves, so we should probably just fix the remaining ones, if any. > + switch (reg_maps->shader_version.type) > + { > + case WINED3D_SHADER_TYPE_VERTEX: > + vertexshader_set_limits(shader); > + break; > + case WINED3D_SHADER_TYPE_GEOMETRY: > + geometryshader_set_limits(shader); > + break; > + case WINED3D_SHADER_TYPE_PIXEL: > + pixelshader_set_limits(shader); > + break; > + default: > + FIXME("Unexpected shader type %u found.\n", reg_maps->shader_version.type); > + } > + > reg_maps->constf = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > sizeof(*reg_maps->constf) * ((constf_size + 31) / 32)); But now you can use "shader->limits.constant_float" instead of "constf_size".

Sept. 30, 2014

Re: [PATCH 2/5] gdi32/tests: Add a test for GetGlyphOutline with an insufficient buffer.

by Matteo Bruni

2014-09-30 15:20 GMT+02: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://testbot.winehq.org/JobDetails.pl?Key=9137 > > Your paranoid android. > > > === wvistau64 (32 bit font) === > The test timed out AFAICS that's really a timeout i.e. the test didn't end in 120 seconds, no crash here. The test introduced by the patch passed fine though.

Sept. 30, 2014

Re: [PATCH 2/5] gdi32/tests: Add a test for GetGlyphOutline with an insufficient buffer.

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=9137 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

Sept. 30, 2014

Re: [PATCH] vbscript: Implemented RGB(try 4)

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=9135 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

Sept. 30, 2014

Re: [PATCH 1/3] user32: Add initial WindowFromPoint tests

by Piotr Caban

On 09/30/14 03:58, Dmitry Timoshkov wrote: > Hi Piotr, > > Piotr Caban <piotr(a)codeweavers.com> wrote: > >> --- >> dlls/user32/tests/win.c | 39 +++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 39 insertions(+) > > There already exist the tests for RealChildWindowFromPoint with a FIXME > about adding new tests for WindowFromPoint, ChildWindowFromPoint and > ChildWindowFromPointEx, is it possible to use existing tests as a base > and extend them as needed? > I've added this tests separately because it's a base for window tree that contains child windows created in different processes. Merging this tests is probably not a good idea because it makes synchronization more complicated and the tests are becoming unreadable.

Sept. 30, 2014