wine-devel March 2015

wine-devel@winehq.org

71 participants
270 discussions

Re: comctl32/tests: Fix couple of metrics tests that fail on some systems
by Marvin 31 Mar '15

31 Mar '15

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=12538 Your paranoid android. === w2003std (32 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:3914: Test failed: got right 112, bottom 19 listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5151: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5156: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests. The Dragon4 algorithm implementation is based on http://www.ryanjuckett.com/programming/printing-floating-point-numbers/.
by YongHao Hu 31 Mar '15

31 Mar '15

Excuse me, Is there anything to do to improve this patch? Thanks. On 2015年03月25日 15:46, YongHao Hu wrote: > Try 3: > - Superseded Patch 109456. > - Use appropriate win32 types instead of typedef. > (Thanks Dmitry Timoshkov) > > Try 2: > - Superseded Patch 109432 > - Use typedef instead of C99 types > - Delete useless #ifndef > - Add memset to test > > Try1: > - Fix bug https://bugs.winehq.org/show_bug.cgi?id=37913 . > - The Dragon4 algorithm implementation is based on > http://www.ryanjuckett.com/programming/printing-floating-point-numbers/. > > --- > dlls/msvcrt/dragon4.h | 668 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/printf.h | 43 +-- > dlls/msvcrt/tests/printf.c | 96 ++++++ > dlls/msvcrt/wine_printfloat.h | 246 ++++++++++++++++ > 4 files changed, 1036 insertions(+), 17 deletions(-) > create mode 100644 dlls/msvcrt/dragon4.h > create mode 100644 dlls/msvcrt/wine_printfloat.h > >

2 2

Re: [7/8] server: Implement waiting for job objects.
by Marvin 31 Mar '15

31 Mar '15

1 0

Re: [1/8] server: Basic implementation of job objects. (rev 2)
by Marvin 30 Mar '15

30 Mar '15

1 0

Re: [PATCH 3/3] comctl32/listview: Always forward HDM_SETORDERARRAY to a header
by Marvin 30 Mar '15

30 Mar '15

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=12515 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2003std (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: [PATCH 7/7] ddraw/tests: Port the lighting test to the previous d3d versions.
by Marvin 30 Mar '15

30 Mar '15

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=12513 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2498: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2500: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2506: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2537: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2545: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2572: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2592: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2616: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2643: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2660: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2697: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2708: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2735: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2755: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2772: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2799: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2816: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2854: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. === w8 (32 bit ddraw1) === ddraw1.c:1376: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1400: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00.

1 0

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting tests.
by Marvin 30 Mar '15

30 Mar '15

1 0

Re: [PATCH 3/7] ddraw: Make sure to activate / deactivate the light on D3DLIGHT_ACTIVE flag changes.
by Sergey Isakov 30 Mar '15

30 Mar '15

Sorry, but seems current revision has no “flags” variable On 30 марта 2015 г., at 21:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/ddraw/light.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/dlls/ddraw/light.c b/dlls/ddraw/light.c > index baaf6a3..c632c32 100644 > --- a/dlls/ddraw/light.c > +++ b/dlls/ddraw/light.c > @@ -201,7 +201,11 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > > wined3d_mutex_lock(); > memcpy(&light->light, data, sizeof(D3DLIGHT)); > - if (flags & D3DLIGHT_ACTIVE) > + if (!(light->light.dwFlags & D3DLIGHT_ACTIVE) && flags & D3DLIGHT_ACTIVE) > + light_activate(light); > + else if (light->light.dwFlags & D3DLIGHT_ACTIVE && !(flags & D3DLIGHT_ACTIVE)) > + light_deactivate(light); > + else if (flags & D3DLIGHT_ACTIVE) > light_update(light); > light->light.dwFlags = flags; > wined3d_mutex_unlock(); > -- > 2.0.5 > > >

1 0

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.
by Henri Verbeet 30 Mar '15

30 Mar '15

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -179,7 +179,7 @@ static void surface_get_blt_info(GLenum target, const RECT *rect, GLsizei w, GLs > case GL_TEXTURE_2D: > info->binding = GL_TEXTURE_BINDING_2D; > info->bind_target = GL_TEXTURE_2D; > - info->tex_type = tex_2d; > + info->tex_type = WINED3D_FFP_TEXTURE_TYPE_2D; > coords[0][0] = (float)rect->left / w; > coords[0][1] = (float)rect->top / h; > coords[0][2] = 0.0f; Note that there isn't anything particularly fixed-function about blits. That currently doesn't matter a whole lot since this is effectively only used for onscreen/offscreen depth blits, but I get the impression your intention is to use this for the blitter interface in general. In that case, something like wined3d_shader_resource_type may be more appropriate, since eventually we'll have to deal with e.g. buffers and array textures as well (for ID3D10Device::CopySubresourceRegion() in particular.) > +enum wined3d_ffp_texture_type > { > - tex_1d = 0, > - tex_2d = 1, > - tex_3d = 2, > - tex_cube = 3, > - tex_rect = 4, > - tex_type_count = 5, > + WINED3D_FFP_TEXTURE_TYPE_1D = 0, > + WINED3D_FFP_TEXTURE_TYPE_2D = 1, > + WINED3D_FFP_TEXTURE_TYPE_3D = 2, > + WINED3D_FFP_TEXTURE_TYPE_CUBE = 3, > + WINED3D_FFP_TEXTURE_TYPE_RECT = 4, > + WINED3D_FFP_TEXTURE_TYPE_COUNT = 5, > }; Somewhat related to above, if this is supposed to be fixed-function we don't need WINED3D_FFP_TEXTURE_TYPE_1D. If it's supposed to be for blits we do, but the "FFP" in the name would be inappropriate. > -/* Similar to tex_types, except that it doesn't have 1d textures > - * (can't be bound), rect textures (handled via np2_fixup) and > - * none / unknown (treated as 2d and handled via dummy textures). */ > +/* Similar to wined3d_ffp_texture_type, except that it doesn't > + * have 1d textures (can't be bound), rect textures (handled via > + * np2_fixup) and none / unknown (treated as 2d and handled via > + * dummy textures). */ wined3d_ffp_texture_type doesn't have a none/unknown element either.

2 2

Re: [PATCH 3/5] wined3d: Use bitfields in struct arbfp_blit_type.
by Henri Verbeet 30 Mar '15

30 Mar '15

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > struct arbfp_blit_type > { > - enum complex_fixup fixup; > - GLenum textype; > + enum complex_fixup fixup : 4; > + enum wined3d_ffp_texture_type textype : 3; > + unsigned padding : 1; > }; > I don't keep a very close eye on arb_program_shader.c, but I suspect this doesn't quite do what you think it does. The structure is going to get aligned to the alignment of the largest scalar field (which would be 32 bits in this case because of enum/unsigned), so you'll have another 24 bits of padding after the "padding" field.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2015