wine-devel March 2016

wine-devel@winehq.org

66 participants
239 discussions

wine 1.9.5 shared wow64 compile error
by Olivier F. R. Dierick 06 Mar '16

06 Mar '16

Hello, I've updated my git tree with 1.9.5 and now I have this error while compiling 32bit Wine with the --with-wine64 option (in a shared wow64 setup): ---begin make output--- ... rm -f fonts && ln -s ../1.9.5_wow_64/fonts fonts rm: impossible de supprimer « fonts »: est un dossier make: *** [fonts] Erreur 1 ... ---end make output--- It says fonts is a directory and can't be removed. I do out-of-tree builds. The 32bit directory doesn't exists when I run configure. After running configure, the 32bit build tree is there and contains a fonts directory with a single Makefile in it. I had no such error with Wine 1.9.4 and I don't have it when compiling stand-alone 32bit Wine or the 64bit shared wow part. I did a regression test and found this commit to be the culprit: ---begin git bisect output--- dcc16c7cac1cbf93096b072fe2f7b32ad08d1fa5 is the first bad commit commit dcc16c7cac1cbf93096b072fe2f7b32ad08d1fa5 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Feb 29 15:06:42 2016 +0900 makefiles: Don't generate global rules in disabled directories. Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> ... ---end git bisect output--- I look forward to hearing from you soon -- Olivier F. R. Dierick o.dierick(a)piezo-forte.be

2 2

Wine-1.9.5 source code Cppcheck 1.69 scanning
by Игорь Чебаненко 04 Mar '16

04 Mar '16

Source code scanned with Cppcheck 1.69. Yes,I know that in this scanning report I have messages called "noise messages",but I hope,that you will see real bugs,and will ingnore this type of messages.

1 0

Re: [PATCH 07/10] d3d10_1: Implement D3D10CreateDeviceAndSwapChain1().
by Henri Verbeet 04 Mar '16

04 Mar '16

On 4 March 2016 at 11:43, Józef Kucia <jkucia(a)codeweavers.com> wrote: > It doesn't seem to be easy to declare D3D10CreateDeviceAndSwapChain1() > without using cpp_quote() because D3D10_DRIVER_TYPE is unknown to idl > (it's declared in d3d10misc.h). My knowledge about idl is limited > so maybe someone knows better. The easiest thing to do would be to use "enum D3D10_DRIVER_TYPE" instead of "D3D10_DRIVER_TYPE". I wouldn't be opposed to just using idl for d3d10misc.h either though. > +cpp_quote("HRESULT WINAPI D3D10CreateDeviceAndSwapChain1(IDXGIAdapter *,") > +cpp_quote(" D3D10_DRIVER_TYPE, HMODULE, UINT, D3D10_FEATURE_LEVEL1,") > +cpp_quote(" UINT, DXGI_SWAP_CHAIN_DESC *, IDXGISwapChain **, ID3D10Device1 **);") I'd prefer this with parameter names either way.

1 0

Re: [PATCH 1/2] user32: Store pointer to timer callback in SetTimer function instead of treating it as window procedure
by Alexandre Julliard 04 Mar '16

04 Mar '16

Piotr Caban <piotr(a)codeweavers.com> writes: > I decided to leave 16-bit version of SetTimer as is for now. I haven't > seen any application running out of window procedures in this > case. This patch will change behavior of following 16-bit application: > SetTimer(hWnd, TIMER_ID, 1, tfunc); > GetMessage32(&msg, 0, 0, 0, TRUE); //get's WM_TIMER message > DispatchMessage32(&msg, TRUE); > Now this code will no longer call tfunc callback. According to my test > new behavior is correct. The more likely case is a 16-bit app retrieving a 32-bit timer and calling it through DispatchMessage16. How is this going to work with your proposed changes? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 2/2 v2] d3drm: Implement AddDestroyCallback/DeleteDestroyCallback for a viewport
by Henri Verbeet 04 Mar '16

04 Mar '16

On 3 March 2016 at 09:10, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +HRESULT d3drm_object_delete_destroy_callback(struct d3drm_object *object, D3DRMOBJECTCALLBACK cb, void *ctx) > +{ > + struct destroy_callback *callback, *callback2; > + > + if (!cb) > + return D3DRMERR_BADVALUE; > + > + LIST_FOR_EACH_ENTRY_SAFE(callback, callback2, &object->destroy_callbacks, struct destroy_callback, entry) > + { > + if (callback->cb == cb && callback->ctx == ctx) > + { > + list_remove(&callback->entry); > + HeapFree(GetProcessHeap(), 0, callback); > + } > + } > + > + return D3DRM_OK; > +} I won't hold it against the patch (much), but is that correct? E.g. suppose you do something like the following: add cb1 add cb2 add cb3 add cb2 delete cb2 What would the sequence be that ends up getting called?

2 1

Re: [v3 6/7] d3dx9: implement state save and restore in effect.
by Matteo Bruni 03 Mar '16

03 Mar '16

2016-03-03 13:22 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- For your next submissions, can you please write a short changelog of the differences with the previous version(s) of the same patch? Ideally that goes after the '---'. > @@ -3493,18 +3501,34 @@ static HRESULT WINAPI ID3DXEffectImpl_Begin(ID3DXEffect *iface, UINT *passes, DW > if (flags & ~(D3DXFX_DONOTSAVESTATE | D3DXFX_DONOTSAVESAMPLERSTATE | D3DXFX_DONOTSAVESHADERSTATE)) > WARN("Invalid flags (%#x) specified.\n", flags); > > - if (This->manager || flags & D3DXFX_DONOTSAVESTATE) > + if (effect->manager || flags & D3DXFX_DONOTSAVESTATE) > { > TRACE("State capturing disabled.\n"); > } > else > { > - FIXME("State capturing not supported, yet!\n"); > + HRESULT hr; > + unsigned int i; > + > + if (!technique->saved_state) > + { > + hr = IDirect3DDevice9_BeginStateBlock(effect->device); > + if (FAILED(hr)) > + ERR("BeginStateBlock failed, hr %#x.\n", hr); > + for (i = 0; i < technique->pass_count; i++) > + d3dx9_apply_pass_states(effect, &technique->passes[i]); This is likely correct but testing it with a technique with at least 2 passes would be nice.

1 0

Re: [v3 5/7] d3dx9: implement sampler and texture effect states application.
by Matteo Bruni 03 Mar '16

03 Mar '16

2016-03-03 13:22 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > dlls/d3dx9_36/effect.c | 41 +++++++++++++++++++++++++++++++++++++++-- > dlls/d3dx9_36/tests/effect.c | 2 +- > 2 files changed, 40 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index e1f01f2..6813c79 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -2681,7 +2681,8 @@ HRESULT d3dx_set_shader_const_state(IDirect3DDevice9 *device, enum SHADER_CONSTA > return D3D_OK; > } > > -static HRESULT d3dx9_apply_state(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, struct d3dx_state *state) > +static HRESULT d3dx9_apply_state(struct ID3DXEffectImpl *effect, struct d3dx_pass *pass, > + struct d3dx_state *state, int parent_index) I would have used an unsigned int here, flagging "none" with ~0u.

1 0

Re: [v3 4/7] d3dx9: implement shader constants effect states application.
by Matteo Bruni 03 Mar '16

03 Mar '16

2016-03-03 13:22 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > + UINT nelem; "unsigned int element_count;" would be better.

1 0

Re: [v3 3/7] d3dx9: implement light and material effect states application.
by Matteo Bruni 03 Mar '16

03 Mar '16

2016-03-03 13:22 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > + light_tbl[] = > + { > + {FIELD_OFFSET(D3DLIGHT9, Type), "LC_TYPE"}, > + {FIELD_OFFSET(D3DLIGHT9, Diffuse), "LT_DIFFUSE"}, > + {FIELD_OFFSET(D3DLIGHT9, Specular), "LT_SPECULAR"}, > + {FIELD_OFFSET(D3DLIGHT9, Ambient), "LT_AMBIENT"}, > + {FIELD_OFFSET(D3DLIGHT9, Position), "LT_POSITION"}, > + {FIELD_OFFSET(D3DLIGHT9, Direction), "LT_DIRECTION"}, > + {FIELD_OFFSET(D3DLIGHT9, Range), "LT_RANGE"}, > + {FIELD_OFFSET(D3DLIGHT9, Falloff), "LT_FALLOFF"}, > + {FIELD_OFFSET(D3DLIGHT9, Attenuation0), "LT_ATTENUATION0"}, > + {FIELD_OFFSET(D3DLIGHT9, Attenuation1), "LT_ATTENUATION1"}, > + {FIELD_OFFSET(D3DLIGHT9, Attenuation2), "LT_ATTENUATION2"}, > + {FIELD_OFFSET(D3DLIGHT9, Theta), "LT_THETA"}, > + {FIELD_OFFSET(D3DLIGHT9, Phi), "LT_PHI"} > + }; This is misindented. > + switch (op) > + { > + case LT_TYPE: > + TRACE("LT_TYPE %u.\n", *(D3DLIGHTTYPE *)value); > + light->Type = *(D3DLIGHTTYPE *)value; > + break; > + case LT_DIFFUSE: > + case LT_SPECULAR: > + case LT_AMBIENT: > + { > + D3DCOLORVALUE c = *(D3DCOLORVALUE *)value; > + > + TRACE("%s (%f %f %f %f).\n", light_tbl[op].name, c.r, c.g, c.b, c.a); > + *(D3DCOLORVALUE *)((char *)light + light_tbl[op].offset) = c; It's probably a bit nicer to cast to (BYTE *) instead of (char *). > diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c > index 81a7d12..3bcba72 100644 > --- a/dlls/d3dx9_36/tests/effect.c > +++ b/dlls/d3dx9_36/tests/effect.c > @@ -2910,11 +2910,11 @@ static void test_effect_states(IDirect3DDevice9 *device) > } > > hr = IDirect3DDevice9_GetLightEnable(device, 2, &bval); > - todo_wine ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > if (hr == D3D_OK) > ok(bval, "Got result %u, expected TRUE.\n", bval); > hr = IDirect3DDevice9_GetLight(device, 2, &light); > - todo_wine ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > if (hr == D3D_OK) > ok(light.Position.x == 4.0f && light.Position.y == 5.0f && light.Position.z == 6.0f, > "Got unexpected light position (%f, %f, %f).\n", light.Position.x, light.Position.y, light.Position.z); > @@ -2950,9 +2950,9 @@ static void test_effect_states(IDirect3DDevice9 *device) > todo_wine ok(!memcmp(mat.m, test_mat.m, sizeof(mat)), "World matrix not restored.\n"); > > hr = IDirect3DDevice9_GetLightEnable(device, 2, &bval); > - todo_wine ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > + ok(hr == D3D_OK, "Got result %x, expected 0 (D3D_OK).\n", hr); > if (hr == D3D_OK) > - ok(!bval, "Got result %u, expected 0.\n", bval); > + todo_wine ok(!bval, "Got result %u, expected 0.\n", bval); It would be nice if the test also checked the material.

1 0

Re: [v3 1/7] d3dx9: add test for basic effect state management.
by Matteo Bruni 03 Mar '16

03 Mar '16

2016-03-03 13:22 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>: > + > + if (effect) > + effect->lpVtbl->Release(effect); > +} The if is unnecessary, the effect creation should never fail (and if it failed you would have already crashed long before that).

1 0

← Newer
1
...
17
18
19
20
21
22
23
24
Older →

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 2016