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

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting 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=12512 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

March 30, 2015

Re: [3/3] kernel32: force 4096 byte page alignment (resend)

by David Naylor

On Tuesday, 24 March 2015 14:09:48 Alexandre Julliard wrote: > David Naylor <dbn(a)freebsd.org> writes: > > FreeBSD prefers to use a 0x200000 (super) page alignment however this > > causes the image base to be displaced from the requested 0x7b800000. > > Forcing a smaller page size ensures FreeBSD can place the image startin > > at 0x7b800000. > This would have to be done in winegcc, with appropriate configure > checks. It's probably easier to change the address to leave more room. Alexandre, this is very far out of my area of expertise. The suggestion of max-page-size came from Tijl (CCed). If I understand what you are suggesting is: 1) Change winegcc to include the max-page-size fix for all dlls on amd64?, or 2) Change the image base so that it works on both i386 and amd64 (with super pages)? If (1) then could you please point me in the right direction. I have no idea where to start. If (2), I though the image base was prescribed by Microsoft and couldn't be changed (and if it could then the other layouts also need to be taken into account). Either way I also have no idea where to start. I know enough to know I know very little. Regards

March 30, 2015

Re: [PATCH 3/7] ddraw: Make sure to activate / deactivate the light on D3DLIGHT_ACTIVE flag changes.

by Sergey Isakov

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 > > >

March 30, 2015

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

by Shuai Meng

Hi, anyone who comment on this patch to improve it will be greatly appreciated. 2015-03-28 17:50 GMT+08: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=12481 > > Your paranoid android. > > > === w2000pro (32 bit) === > No test summary line found > > === wxppro (32 bit) === > No test summary line found > > === w2003std (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 >

March 30, 2015

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-30 um 12:20 schrieb Stefan Dösinger: > I don't plan to use it for the interface, this will continue to > use struct wined3d_surface for now. I only intend to use this in > the internal structures in the blitter implementation. Actually, for fixing bugs 38178 and 21708 we'll need some sort of resource type enumeration that includes renderbuffers as well. While it's not exactly the same thing as the texture types we use for fixed function draws I think it's better to merge them than to have 3 very similar but not quite the same enumerations. So don't apply this series for now, I'll change the name to something that works better for separating opengl resource types in a more general way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVGUjPAAoJEN0/YqbEcdMwBfcP/jcFwFkWQhWr/JbLPN/4TWSo D4LHtvuUrh1KiKpd9HkEoq6EiXuFPxJKB3XSmk/paLX4C8T620zgVit3OmCRmxRM Qu8PUphnw14h+I7BpbWnyXsEPvzTYlJTXXnBcPCXwptygZwhVBNFAtR+Vk4WYGcX u6RLL2ey57tJ9TxBTOn/yoeAuDLsxC2mTWQvMW/KShPBw0fncekSoS0qNMHWUNsD qE1O+0QDhJvVSpda0fA/OTK2hpMiuglMO58Gm5IYlXujsKP/MvJnez5CKgqW12Mv sUZbXgu1OgD5K5kDGJIMZYv4Q/PNZSJVwDPPvPOeHLuxTdRkuuwUBcOJRdqcl3K5 nvVV65H4gwyt03CY1rvTdxu9CleGSmDJlHWjDb66QlaqaVldu6B4T/MVBmDOcalc lM7UBofsFBKX0DfY8x8nsQGo4oY1csJk59Kr2c+WWV73Nlt36ftyq3U4Xaqu8MWE 2XpMNgZUOnMrDwObP8gt8m24Lb1Jeh3EW00cQQ0sYwcknWuWt9LkyHuN6QEeRIJ5 S7hboeY0v7ZGz9vCpKRd8QcfJLRyR6QfCSB/1JxnVH/Aem+JafBOm3bipHbEoRLv A63Etk87ZsbkSXEwS7u37vLsGWqbhaaq5H4N1DNuj7Lxe9QnxGnAEb4wlzHtJtMQ x+f0yvP3+dCxcxn3Ygdo =hhyq -----END PGP SIGNATURE-----

March 30, 2015

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 Piotr Caban

Hi, On 03/30/15 10:28, YongHao Hu wrote: > Excuse me, > Is there anything to do to improve this patch? I'm simply not sure what to think about this patch. Printf with this patch is not always producing the same output as native dll. You can see the difference calling printf with big precision (as far as I remember native never displays more than 18 digits and fills the rest with '0'). Because of that I'm not sure if this algorithm is really needed here. The bug with different rounding can be probably fixed by printing the double with bigger precision and doing the rounding our self. On the other hand there are some advantages of making it not depending on host system standard library. Thanks, Piotr

March 30, 2015

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-30 um 11:09 schrieb Henri Verbeet: > but I get the impression your intention is to use this for the > blitter interface in general I don't plan to use it for the interface, this will continue to use struct wined3d_surface for now. I only intend to use this in the internal structures in the blitter implementation. My short term goal is to handle color keying in shaders (blit and fixed function draws) so we can remove the offscreen -> render target blit code in surface_blt_special. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVGSNtAAoJEN0/YqbEcdMw1+QP/3RHJoWfWf/3Nari+TtHleLG i+OBNASMnRk96YaeqX/MMUQhPdCb4RkJ/y2CUn7q7D3a9RUtKv/6hbY+cNIcPFef pZDRvWfCLLyD1Sha6iiWN0d4WZ54gAmxdIkkTV1ZTtQSMxAmBoPgSiu07+MaXvRx KnJovthe/CUYLOhNNfXgTNrwiebwG3GBJJaEVpSMlmc35D7WVljeohGxmyuyRUrI zEpEV4CNrSDfzjf5HpPN5/XU15QDzWgLaoglalR9WSZQEY9EY45263ojJsw0fpvw 5324Cb5sbr7DvLjuUHADX+U5+wTiW/xOSn01soNWkXBv5IDnIVlpyAJChSL89GtD /dxpn8G3fXzC55j1BYzAQBAsDFF6dsUXN5izLF2Dk1I3LFkhvuHJTi03OIHvrNAt vc34qsaMo2HTKKFXeeX2Tst3swZ2JBWCLtxm/2JE1a+lCNq3Eq29belDrOizNzEm 38veuMlH9YpLg8KdbfQIkN7Kph8g5HoKp4ay1g2TKOGl4Rd/uSW9v+pvAEkLIEEd 85ih5Tll0oLGwQSAMzG0sUh1cKFLRVwy/ZD3lxNybnSBR507QbQY5a0YOjSSu1tj LG2djSGlVaaYXNZJDl6hmsV9konxcCW4fo2pqjsfJ29z03/c3Yqu8MpnTeZCswAt El23c1p0qxUszIHjwzq/ =bKGc -----END PGP SIGNATURE-----

March 30, 2015

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.

by Henri Verbeet

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.

March 30, 2015

Re: [PATCH 3/5] wined3d: Use bitfields in struct arbfp_blit_type.

by Henri Verbeet

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.

March 30, 2015

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

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 > >

March 30, 2015