Re: Have there been any problems with Wine on GCC 4.7?
> > > http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191eae3879fc422e2d > > -- > -Austin > the trouble with this patch is that it enables debug info whatever the default configuration is... A+ -- Eric Pouech
Re: Have there been any problems with Wine on GCC 4.7?
On Mon, Aug 13, 2012 at 4:46 PM, Scott Ritchie wrote: > On 8/13/12 12:55 PM, Eric Pouech wrote: >> >> >>> diff --git a/configure.ac b/configure.ac >>> index 4bd43d1..c80fd8a 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -1746,6 +1746,8 @@ then >>> WINE_TRY_CFLAGS([-Wtype-limits]) >>> WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) >>> WINE_TRY_CFLAGS([-Wwrite-strings]) >>> + WINE_TRY_CFLAGS([-gdwarf-2]) >>> + WINE_TRY_CFLAGS([-gstrict-dwarf]) >>> >>> dnl gcc-4.6+ omits frame pointers by default, breaking some copy >>> protections >>> case $host_cpu in >>> >>> would be simpler, unless I'm missing something. >>> >> would work too (even if this would be preferable) >> >> + WINE_TRY_CFLAGS([-gdwarf-2 -gstrict-dwarf]) >> > > Or I could not patch Wine itself and instead patch it's build instructions > in the package rules file. > > But if Wine indeed doesn't work with GCC's new default settings then it > should probably be a Wine page (for every distro) http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191eae3879fc422e2d -- -Austin
Re: [PATCH 4/4] wined3d: Improve post-pixelshader blending test. (Try 2)
2012/8/20 Lucas Zawacki : > Hello, this patch caused a regression with Rayman 2, all the text in > the menus is rendered wrong now. > > Should I open a bug or is this email enough? A demo of the game can be > downloaded here ftp://ftp.ubisoft.com/Rayman2/rayman2high.zip > > Screenshot: http://dl.dropbox.com/u/2701879/images/rayman2.png > > Regression test: > a488e574497d674631b4036d4b179ce349ddb764 is the first bad commit > commit a488e574497d674631b4036d4b179ce349ddb764 > Author: Matteo Bruni > Date: Wed Aug 15 00:38:26 2012 +0200 > > wined3d: Improve post-pixelshader blending test. > > :04 04 1a61c91a146de3e7a5206ccde1cc239fa0771e40 > a9759ba603b3b52f2feccc716daff3d875a90b74 M dlls > > That's probably bug 31490, the patch from that bug (which I sent to wine-patches as http://www.winehq.org/pipermail/wine-patches/2012-August/117143.html) should fix it. Sorry for the inconvenience...
Re: [PATCH 4/4] wined3d: Improve post-pixelshader blending test. (Try 2)
Hello, this patch caused a regression with Rayman 2, all the text in the menus is rendered wrong now. Should I open a bug or is this email enough? A demo of the game can be downloaded here ftp://ftp.ubisoft.com/Rayman2/rayman2high.zip Screenshot: http://dl.dropbox.com/u/2701879/images/rayman2.png Regression test: a488e574497d674631b4036d4b179ce349ddb764 is the first bad commit commit a488e574497d674631b4036d4b179ce349ddb764 Author: Matteo Bruni Date: Wed Aug 15 00:38:26 2012 +0200 wined3d: Improve post-pixelshader blending test. :04 04 1a61c91a146de3e7a5206ccde1cc239fa0771e40 a9759ba603b3b52f2feccc716daff3d875a90b74 M dlls
Re: [6/7] d3dx9: Implement ID3DXConstantTable::SetMatrixPointerArray.
On 20.08.2012 17:10, Józef Kucia wrote:
+if (desc.Class == D3DXPC_MATRIX_ROWS || desc.Class ==
D3DXPC_MATRIX_COLUMNS)
+{
...
+}
+else if (desc.Class == D3DXPC_SCALAR)
Could you also set D3DXPC_VECTOR variables with this call? It should be
easy to add a test for a scalar and a vector. But that may also be a
separate patch. In general I think it would be fine to try to set all
variable class and see which work / fail. That way you would also
verify, that the non common way works too, which has no test, yet, but a
implementation. This holds true for all the Set(Matrix/Vector/...)
functions. That way you'd ensure that the setting is correct for the
specific class.
ID3DXConstantTable_SetMatrixPointerArray(ctable, device, "c2x3",
matrix_pointer, 1);
ID3DXConstantTable_SetMatrixPointerArray(ctable, device, "r2x3",
matrix_pointer, 1);
ID3DXConstantTable_SetMatrixPointerArray(ctable, device, "vec3",
matrix_pointer, 1);
ID3DXConstantTable_SetMatrixPointerArray(ctable, device, "scalar",
matrix_pointer, 1);
Cheers
Rico
Re: [3/7] d3dx9: ID3DXConstantTable::SetFloat shouldn't change the value of matrix and vector constants.
On 20.08.2012 17:10, Józef Kucia wrote: @@ -665,6 +666,31 @@ static void test_setting_basic_table(IDirect3DDevice9 *device) out[8], out[9], out[10], out[11], out[12], out[13], out[14], out[15]); +ID3DXConstantTable_SetFloat(ctable, device, "mvp", f); +ok(res == D3D_OK, "ID3DXConstantTable_SetFloat failed on variable mvp: 0x%08x\n", res); You probably may save res (= ID3DXConstantTable_SetFloat) before checking it. Otherwise you are checking the same res value multiple times. +ID3DXConstantTable_SetFloat(ctable, device, "f4", f); +ok(res == D3D_OK, "ID3DXConstantTable_SetFloat failed on variable f4: 0x%08x\n", res); Cheers Rico
Re: [PATCH 1/2] oleaut32: Ensure that the right interface is passed to the callee in ITypeInfo::Invoke
Jacek Caban writes:
> @@ -6509,6 +6510,38 @@ static HRESULT WINAPI ITypeInfo_fnInvoke(
> {
> prgpvarg[i] = src_arg;
> }
> +
> +if((tdesc->vt == VT_USERDEFINED || (tdesc->vt == VT_PTR
> && tdesc->u.lptdesc->vt == VT_USERDEFINED))
> + && (V_VT(prgpvarg[i]) == VT_DISPATCH ||
> V_VT(prgpvarg[i]) == VT_UNKNOWN)) {
> +const TYPEDESC *userdefined_tdesc = tdesc;
> +IUnknown *userdefined_iface;
> +ITypeInfo *tinfo2;
> +TYPEATTR *tattr;
> +
> +if(tdesc->vt == VT_PTR)
> +userdefined_tdesc = tdesc->u.lptdesc;
typelib.c: In function ‘ITypeInfo_fnInvoke’:
typelib.c:6516:41: error: variable ‘userdefined_tdesc’ set but not used
[-Werror=unused-but-set-variable]
make[1]: *** [typelib.o] Error 1
--
Alexandre Julliard
julli...@winehq.org
Re: Microsecond unit
Francois Gouget writes: > The microsecond unit is 'µs' and yet, in dlls/sane.ds/sane.rc, we define > it as 'us' and then rely on the British and American English PO files to > convert it to 'µs'. > > Why not put the right unit directly in the RC file? > It's UTF-8 anyway... wrc requires msgids to be ASCII only, to avoid encoding issues. It could possibly be improved now that all RC files are utf-8. IIRC there may also be some restrictions in libgettextpo itself. -- Alexandre Julliard julli...@winehq.org
