August 2012 - Wine-Devel - list.winehq.org

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 22.08.2012 12:23, Józef Kucia wrote: > On Tue, Aug 21, 2012 at 10:52 PM, gurketsky <gurketsky(a)googlemail.com > <mailto:gurketsky(a)googlemail.com>> wrote: > > I just like to present the state of the ID3DXConstantTable > implementation, so that possibly no work is done twice. This goes > specifically to Józef. I'm not sure what's the plan on this. There > are two problems which arise and I did not had time to sort those > out, yet. > > > Thanks for notifying me. I was about to write some tests for structures > in constant tables. I see that you've already written such tests. > > Cheers, > Józef Kucia Well, I just had a closer look again. My speed test triggers a problem, so it's not really comparable. But it looks like native only allocates handles, if it really needs them. So I'm not sure we like to go the same approach or if it is fine allocating them all like I've done that. I fixed the test and native speed advantage was blown away. Although, if that's fine with your opinion, you could reuse the code or I could clean it up a bit and send it. I haven't send it and improved it, yet, because the problem with solution 1. or 2. isn't solved for me. I'm a little bit against version 1., because I think speed might be an issue and no one had a technical argument against 2. I don't think a extra handle list for handles with "small" values is the way to got, because it may also hit the values where strings could be in memory. The extra handle list would be 3., but I think it needs a lot more memory for just adding a "layer" for checking the handles. Thus 2. is a lot better than 3. (which I haven't explained in detail). To tackle the problem: 1. The handle and table mixing could be worked around by using a global list for all tables and searching the handles in there. That should be easy to add. The problem I see with that, might be speed related, when we have a lot of handles, searching the list will be slow. Through, I'm fine with that solution and would add it. It will show, if it really is so slow... 2. But the other solution isn't dead for me, yet. I had another look at the D3DXHANDLE usage and the question what the hell is D3DXCONSTTABLE_LARGEADDRESSAWARE used for? It was said, it's bad and broken, but I haven't seen why, just that it is ugly, but I couldn't see a technical reason not to do so. What's specifically the problem: The argument is, that D3DXHANDLES are distinguished from strings by using the highest bit (bit #31). Thus with LARGEADDRESSAWARE the usage of stings as D3DXHANDLEs is not allowed anymore (see http://msdn.microsoft.com/en-us/library/windows/desktop/bb943959%28v=vs.85%…) Also this would speed up the detection of a handle dramatically, well it doesn't check for validness, but native doesn't do that, if you pass a garbled handle, it will crash. D3DXHANDLE handle_from_constant(struct ctab_constant *constant) { if (largeadressaware && constant) return (D3DXHANDLE)constant; if (constant) return (D3DXHANDLE)((UINT_PTR)constant | 0x80000000); return NULL; } struct ctab_constant *is_valid_constant(struct ID3DXConstantTableImpl *table, D3DXHANDLE handle) { if (largeadressaware) return (struct ctab_constant *)handle; if ((UINT_PTR)handle >> 31) return (struct ctab_constant *)((UINT_PTR)handle & 0x7fffffff); return get_constant_by_name(table, NULL, handle); } According to http://en.wikipedia.org/wiki/Virtual_address_space: 32bit on 32bit without LARGEADDRESSAWARE: has only 2gb (default 32bit) 32bit on 64bit without LARGEADDRESSAWARE: has only 2gb (default 32bit) 64bit on 64bit without LARGEADDRESSAWARE: has only 2gb 32bit on 32bit with LARGEADDRESSAWARE: has 3gb 32bit on 64bit with LARGEADDRESSAWARE: has 4gb 64bit on 64bit with LARGEADDRESSAWARE: has 8tb (default 64bit) So in cases, where the exe is linked with LARGEADDRESSAWARE, d3dx9 would have to be used with D3DXCONSTTABLE_LARGEADDRESSAWARE. That way it's the same for os with 32bit and 64bit. The only problem I see, nowhere is said, that the 2gb will always be the lowest 2gb. But my tests showed, that I always get the lower 31bit of addresses in my test runs when allocating memory. Thus I'm very unlucky by not getting a higher address or this might be the way it works on windows. Has anyone a technical argument against this solution? I hope this helps you to make the correct decisions. Cheers Rico

Aug. 22, 2012

Re: d3dx9: ID3DXConstantTable

by Józef Kucia

On Tue, Aug 21, 2012 at 10:52 PM, gurketsky <gurketsky(a)googlemail.com>wrote: > I just like to present the state of the ID3DXConstantTable implementation, > so that possibly no work is done twice. This goes specifically to Józef. > I'm not sure what's the plan on this. There are two problems which arise > and I did not had time to sort those out, yet. > Thanks for notifying me. I was about to write some tests for structures in constant tables. I see that you've already written such tests. Cheers, Józef Kucia

Aug. 22, 2012

Re: configure.ac: provide a --disable-dwarf2 configure option

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > This should address the concerns from > http://bugs.winehq.org/show_bug.cgi?id=31501 I don't think that justifies adding a configure option, people shouldn't have to worry about that kind of detail. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2012

Re: wine/server: removed obsolete one-iteration loop from request forming macro

by Sergey Guralnik

On 2012-08-22 6:26, Архад wrote: > #define SERVER_START_REQ(type) \ > - do { \ > - struct __server_request_info __req; \ ... > - (void)reply; \ > - do > - > -#define SERVER_END_REQ \ > - while(0); \ > - } while(0) > + struct __server_request_info __req; \ ... > + (void)reply; > + > +#define SERVER_END_REQ Are you try at least to rebuild project with it? -- Sergey

Aug. 22, 2012

Re: opengl32/test: do not pass NULL attrib list to wglCreatePBufferARB

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 http://testbot.winehq.org/JobDetails.pl?Key=21127 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> Shouldn't you be scaling range_size.cx as well? > > > > No, range_size is already in pixels. > > So is bounds. I think you need to scale both of them to world units. You are right, somehow I missed that, thanks. -- Dmitry.

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Vincent Povirk

>> Shouldn't you be scaling range_size.cx as well? > > No, range_size is already in pixels. So is bounds. I think you need to scale both of them to world units.

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > GetTextExtentExPointW(hdc, string + index, range_start - index, > > INT_MAX, NULL, NULL, &range_size); > > - range_rect.X = bounds->X + range_size.cx; > > + range_rect.X = bounds->X / args->rel_width + range_size.cx; > > > > GetTextExtentExPointW(hdc, string + index, range_end - index, > > INT_MAX, NULL, NULL, &range_size); > > - range_rect.Width = (bounds->X + range_size.cx) - range_rect.X; > > + range_rect.Width = (bounds->X / args->rel_width + range_size.cx) - range_rect.X; > > Shouldn't you be scaling range_size.cx as well? No, range_size is already in pixels. -- Dmitry.

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Vincent Povirk

> GetTextExtentExPointW(hdc, string + index, range_start - index, > INT_MAX, NULL, NULL, &range_size); > - range_rect.X = bounds->X + range_size.cx; > + range_rect.X = bounds->X / args->rel_width + range_size.cx; > > GetTextExtentExPointW(hdc, string + index, range_end - index, > INT_MAX, NULL, NULL, &range_size); > - range_rect.Width = (bounds->X + range_size.cx) - range_rect.X; > + range_rect.Width = (bounds->X / args->rel_width + range_size.cx) - range_rect.X; Shouldn't you be scaling range_size.cx as well?

Aug. 22, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Austin English

On Mon, Aug 20, 2012 at 11:55 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > >> >> >> http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191e… >> >> -- >> -Austin > > > the trouble with this patch is that it enables debug info whatever the > default configuration is... > A+ > > -- > Eric Pouech -g was already the default. Most packagers (to my knowledge) provide a separate debug package, which isn't installed by default. -- -Austin

Aug. 21, 2012

Re: user32: Don't limit time needed for WM_DDE_INITIATE processing.

by Piotr Caban

On 08/21/12 17:40, Alexandre Julliard wrote: > Piotr Caban<piotr(a)codeweavers.com> writes: > >> Current timeout is too small for Microsoft Office 2010 in some cases. >> I've checked that DdeConnect succeeds on windows when it needs to wait >> for 10 minutes. > > Are you sure that you want to remove the SMTO_ABORTIFHUNG flag? Does a > hung process really prevent all DDE connections? My bad, it was not my intention. I will send another patch. I was only trying to allow the application to spend more time while processing WM_DDE_INITIATE message.

Aug. 21, 2012

Re: user32: Don't limit time needed for WM_DDE_INITIATE processing.

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > Current timeout is too small for Microsoft Office 2010 in some cases. > I've checked that DdeConnect succeeds on windows when it needs to wait > for 10 minutes. Are you sure that you want to remove the SMTO_ABORTIFHUNG flag? Does a hung process really prevent all DDE connections? -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2012

Re: [1/3] dinput: Disable linuxinput or linux joysticks based on registry key

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > > In the form of "Disable Controllername"="driver" > > Examples: > Disable "Usb Controller"="js" disable linux js driver > Disable "OtherController"="event,js" disable linux js and event drivers That's a fairly complicated way to disable a given joystick. What you probably want is to give them a unique name and have a enable/disable value for each name. -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2012

Re: mountmgr.sys: For loop-mounted devices, use the backing file

by Damjan Jovanovic

On Tue, Aug 21, 2012 at 4:25 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > I thought mounting the ISO should be the same thing than inserting the disc > in the drive. > But you seem to think that the current behaviour is the right one so in this > case, simply ignore my patch. > > Try using cdemu to load that ISO into a virtual CDROM drive. There's an Ubuntu PPA for it at https://launchpad.net/~cdemu/+archive/ppa Damjan

Aug. 21, 2012

Re: mountmgr.sys: For loop-mounted devices, use the backing file

by GOUJON Alexandre

On 08/21/2012 11:49 AM, Alexandre Julliard wrote: > Alexandre Goujon <ale.goujon(a)gmail.com> writes: > >> As part of their copy protection, some games use some ioctl's to check some physical attributes. >> Unfortunately, when using the loop device, some ioctl fail (like IOCTL_SCSI_GET_ADDRESS). >> A simple fix is to use /path/to/the/file.ISO instead of /dev/loopX. > Several places depend on this being a device. Besides, failing to get > the SCSI address of a loop mount seems like correct behavior to me. > I originally wanted this patch in because my game was failing when I mounted the ISO of the disc via the loop device. The game was calling GetVolumeInformation to check its serial and to do so, GetVolumeInformation has to look at some blocks at specific offsets. But seeking (SetFilePointer) and reading (ReadFile) is not the same with the handle of the loop device and the ISO file. So I had to manually change the dosdesices/X:: link to make it point from /dev/loop/X to /path/to/file.iso Moreover, even if it is understandable that IOCTL_SCSI_GET_ADDRESS fails, others like IOCTL_DVD_READ_STRUCTURE, should return valid values, not ERROR_NOT_SUPPORTED. I thought mounting the ISO should be the same thing than inserting the disc in the drive. But you seem to think that the current behaviour is the right one so in this case, simply ignore my patch.

Aug. 21, 2012

Re: [PATCH] kernel32: add basic conditional variables support (try 2)

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > Started with patch from Austin, brought up to a point > where Adobe Lightroom 4.1 starts up. > > The synchronisation is probably not 100% correct and > not sufficiently atomic. Synchronization routines have to be 100% correct, half stubs are worse than no implementation at all. -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2012

Re: mountmgr.sys: For loop-mounted devices, use the backing file

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > As part of their copy protection, some games use some ioctl's to check some physical attributes. > Unfortunately, when using the loop device, some ioctl fail (like IOCTL_SCSI_GET_ADDRESS). > A simple fix is to use /path/to/the/file.ISO instead of /dev/loopX. Several places depend on this being a device. Besides, failing to get the SCSI address of a loop mount seems like correct behavior to me. -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Eric Pouech

> > > http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191e… > > -- > -Austin > the trouble with this patch is that it enables debug info whatever the default configuration is... A+ -- Eric Pouech

Aug. 21, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Austin English

On Mon, Aug 13, 2012 at 4:46 PM, Scott Ritchie <scott(a)open-vote.org> 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/3f1dbaf3df0ae8ec2f0e86191e… -- -Austin

Aug. 21, 2012

Re: [PATCH 4/4] wined3d: Improve post-pixelshader blending test. (Try 2)

by Matteo Bruni

2012/8/20 Lucas Zawacki <lfzawacki(a)gmail.com>: > 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 <mbruni(a)codeweavers.com> > Date: Wed Aug 15 00:38:26 2012 +0200 > > wined3d: Improve post-pixelshader blending test. > > :040000 040000 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...

Aug. 20, 2012

Re: [PATCH 4/4] wined3d: Improve post-pixelshader blending test. (Try 2)

by 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 <mbruni(a)codeweavers.com> Date: Wed Aug 15 00:38:26 2012 +0200 wined3d: Improve post-pixelshader blending test. :040000 040000 1a61c91a146de3e7a5206ccde1cc239fa0771e40 a9759ba603b3b52f2feccc716daff3d875a90b74 M dlls

Aug. 20, 2012

Re: [6/7] d3dx9: Implement ID3DXConstantTable::SetMatrixPointerArray.

by Rico Schüller

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

Aug. 20, 2012

Re: [3/7] d3dx9: ID3DXConstantTable::SetFloat shouldn't change the value of matrix and vector constants.

by Rico Schüller

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

Aug. 20, 2012

Re: [PATCH 1/2] oleaut32: Ensure that the right interface is passed to the callee in ITypeInfo::Invoke

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> 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 julliard(a)winehq.org

Aug. 20, 2012

Re: Microsecond unit

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> 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 julliard(a)winehq.org

Aug. 20, 2012