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

Re: msvcrt: remove errno EDOM from atan, exp and tanh
by Piotr Caban March 24, 2015

March 24, 2015

Hi, On 03/22/15 14:50, Kevin Chan wrote: > double CDECL MSVCRT_atan( double x ) > { > - if (!isfinite(x)) *MSVCRT__errno() = MSVCRT_EDOM; > return atan(x); > } I've done a little more testing. The function is not setting errno in INF and -INF case. It does set errno to EDOM when argument is NAN. Thanks, Piotr

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 4)
by Nikolay Sivov March 24, 2015

March 24, 2015

Looks good, thanks.

1 0

submitting report
by Shubham kumar March 24, 2015

March 24, 2015

I ran winetest.exe on my pc and it generated a output file resDD89.tmp. How can i view this report? On which website i have to upload this file to generate the log? Thank you

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 3)
by Nikolay Sivov March 23, 2015

March 23, 2015

On 03/23/2015 10:44 PM, Mark Harmstone wrote: Hey, looks much better, thanks. One minor thing left, and I'm sorry that I missed it last time: > + if (theme) { > + DrawThemeText(theme, hdc, HP_HEADERITEM, state, phdi->pszText, > + lstrlenW(phdi->pszText), DT_LEFT|DT_END_ELLIPSIS|DT_VCENTER|DT_SINGLELINE, > + 0, &r); > + } else { > + Will it work as docs claim if you simply pass -1 as a text length? Otherwise looks good to me.

1 0

Re: [PATCH 1/5] wined3d: Only set TEXTURE_COMPARE_FUNC when ARB_depth_texture is supported.
by Henri Verbeet March 23, 2015

March 23, 2015

On 23 March 2015 at 18:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - if (desc->compare) > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > - wined3d_gl_compare_func(desc->comparison_func))); > + if (gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + if (desc->compare) > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > + wined3d_gl_compare_func(desc->comparison_func))); > + } Does the driver generate GL errors without this? The way I read the ARB_sampler_objects spec that would a driver bug. (Specifically, it states that TEXTURE_COMPARE_MODE/TEXTURE_COMPARE_FUNC are accepted by SamplerParameter(), without qualifying that with a dependency on ARB_depth_texture. I guess a driver that doesn't support depth textures can essentially just ignore the texture compare mode/function, since it would never encounter a texture it would apply to.)

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Stefan Dösinger March 23, 2015

March 23, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/23/15 15:50, Sebastian Lackner wrote: > + format = D3DFMT_DXT5; > + width = 5; height = 5; > ... > + ok(mipmaps == 1, "Returned mipmaps %d, expected %d\n", mipmaps, 1); I'm curious, why does it report 1 mipmap level? Maybe because width / 2 is smaller than the block size, even though the block-size aligned width would allow a second level. What does d3dx9 return when you have width = height = 10 for example? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVEDcbAAoJEN0/YqbEcdMwVyAQAIusV1Z29v1LQQGKJtBdZk9C g+KRkCEcHalFEjwSHL4689U+GtQVigN1OSIJAtsSvrHBpslwtwsA+q7Crgamuk2X zQ+sxYOHE3QIoD2yy/uQElKxfLZWzBQjeUjZGMdYPLv4Bc2NRp4tMexPMKsHVeDx WubraUfiG40uWwcuFTfODuwuybZjWBUk89PIy865PS++/24wO12WB5vP+dK4XEB4 Mrv4Vzv+8f2zVO+tIWtXgr439f4skF4o5peOwe8qN7KxNSkqKduIWf/5dLfgZhgt lqUrziNNcWaVy5poM/cVeo7P4KKMJLjlT9ehItGee1S7gUUiatyGAKyttN5zauiV SRqJSq8sKWSGCDb/779aTonPVkLnHZVWHblJAihrCBuyE3tZVJpgg9xE3rWMyM8d IstQxbGEgDgQmrXxkeox6M3FnkBp3NL8ALzL5NHHoUxPJMg1yz5cGWuiqdBGYPM1 LmqynuRlXERLBMen/Rn69f/KFdGgqitPhzPupZ3nIGAi1Cku4Vjwd92nUS9ruZS9 uTT0t+wAjCvfKMBCfj0nnmQ4y7W9bmCxDVZs/Md83Ed4G49crTo7XTtrZnWDH4GU gFoGbn+BjcU7uankhoC5tq+XatHr6oRkWIrO5jJg2Oyk9Wns5cyanuvfGdwYrQT8 T+IYcghTfBRrDRNKHrqg =YJRY -----END PGP SIGNATURE-----

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Henri Verbeet March 23, 2015

March 23, 2015

On 23 March 2015 at 15:50, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > + if (w % fmt->block_width) > + w += fmt->block_width - w % fmt->block_width; > + if (h % fmt->block_height) > + h += fmt->block_height - h % fmt->block_height; Could you please just use the conventional way to align something?

1 0

Counting bits set in a 32 bit value
by Bruno Jesus March 23, 2015

March 23, 2015

Hi all, after some manual testing I noticed that the joystick structure member dwButtonNumber is not the last button pressed but instead the count of pressed buttons. There is a bit field of buttons set in the structure member dwButton, to fix the number in dwButtonNumber I guess the easiest way is to count the bits set. I think that keeping a counter with ++/-- operations could lead to out of sync situations if the joystick is not polled fast enough. Is there any precedent need for this in wine? Is there an accepted solution for it? Internet searching shows different ways like bit counting with shift, using cpu instructions or internal compiler functions. Best wishes, Bruno

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum March 23, 2015

March 23, 2015

This seems sane to me, but I never had a good grasp on this to begin with. Does it look OK to you, Mark? Andrew On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > This patch fixes incorrect sound positioning in dsound. > As of now, angle to sound source is calculated as angle between > vDistance and vOrientFront. > This leads to incorrect results for all sources that are not in the > same plane as speakers. > In extreme case: for sources directly above or below origin, angle is > calculated to -90 degrees, and they are played in the left speaker. > > This patch changes angle calculation: angle to sound source is > calculated as angle between vDistance and plane given by vectors > vOrientFront and vOrientTop. > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > From: Stas Cymbalov <dummyunit(a)gmail.com> > Date: Sun, 22 Mar 2015 18:22:49 +0300 > Subject: dsound: Fix angle to sound source calculation. > > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > index 9a0226a..ffd4d45 100644 > --- a/dlls/dsound/sound3d.c > +++ b/dlls/dsound/sound3d.c > @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > > cos = product/(la*lb); > angle = acos(cos); > - if (cos < 0.0f) { angle -= M_PI; } > TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > b->y, b->z, angle, RadToDeg(angle)); > return angle; > @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > else > { > vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > - > - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > - * this whether the sound is to our left or to our right. We have to perform another dot > - * product, with a vector at right angles to the initial one, to get the correct angle. > - * The angle should be between -180 degrees and 180 degrees. */ > - if (flAngle < 0.0f) { flAngle += M_PI; } > - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > + /* To calculate angle to sound source we need to: > + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > + * and vOrientFront. > + */ > + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > + if (flAngle2 > M_PI_2) > + flAngle = -flAngle; > + flAngle -= M_PI_2; > + if (flAngle < -M_PI) > + flAngle += 2*M_PI; > } > TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > > -- > 2.0.5 > >

1 0

Re: [PATCH 4/4] ddraw/tests: Port test_color_fill to earlier versions.
by Henri Verbeet March 23, 2015

March 23, 2015

On 20 March 2015 at 12:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (tests[i].caps & DDSCAPS_ZBUFFER) > + { > + surface_desc.dwFlags &= ~DDSD_PIXELFORMAT; > + surface_desc.dwFlags |= DDSD_ZBUFFERBITDEPTH; > + U2(surface_desc).dwZBufferBitDepth = get_device_z_depth(device); > + } > + > + hr = IDirectDraw2_CreateSurface(ddraw, &surface_desc, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x, surface %s.\n", hr, tests[i].name); > + This crashes for me: ddraw2.c:7654: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw2.c:7654: this is the last test seen before the exception ddraw2: unhandled exception c0000005 at 00437C9D And similarly for ddraw1: ddraw1.c:6636: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw1.c:6636: this is the last test seen before the exception ddraw1: unhandled exception c0000005 at 004167BD

1 0