May 2011 - Wine-Devel - list.winehq.org

Re: [8/15]usp10/tests: Hebrew shaping test
by Alexandre Julliard May 24, 2011

May 24, 2011

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/tests/usp10.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:438: Test failed: 0: Glyph not present when it should be usp10.c:438: Test failed: 1: Glyph not present when it should be usp10.c:438: Test failed: 2: Glyph not present when it should be usp10.c:438: Test failed: 3: Glyph not present when it should be make[1]: *** [usp10.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

performance regression or not?
by Joerg-Cyril.Hoehle＠t-systems.com May 24, 2011

May 24, 2011

Hi, please consider the following WINEDEBUG=+fps numbers. 1.1.24 24-19 fps, depending on orientation 1.3.16 14-7 fps 1.3.18-291-g9da9240 14-6 fps 1.3.18-342-gab199f5 13-5 fps 1.3.19-46-g3025f7f 8 fps 1.3.20 7-4 fps The low fps results in jerky character movement. This looks like a serious performance degradation over time, isn't it? Actually, the situation is much subtler and so confusing that I don't know what to think about it. - Disabling audio in winecfg yields 25 fps. Audio seems to play a major role, although both CPU% of the dual core machine are mostly near 33%. - Once and only once, while running 1.3.19-27-gf912e55, I observed 25 fps (with sound!) instead of 13. So new Wine *can* still play fast, it just almost never does it. Why? - After much bisecting, I've learnt that while newer versions of Wine typically produce low fps initially, I can go to the app's options -> graphics -> effects settings during game, change some of them, revert them to their original values, then observe 25 fps -- with sound! What's this weird relationship between sound and 3D? - git bisect lead to a change about mmdevapi.dll that the app does not even use. My hypothesis so far is that Wine or the app seems extremely sensitive to the random location of some stuff in memory. - I don't believe the machine is overloaded. I can start 2 side by side, e.g. demo and retail, in different versions of Wine. - I'm now wondering whether thread affinity may play a role. Alas, I don't know how to disable one core with Mac OS X 10.5.8 The app uses mono internally (windows' version). It's named 2weistein http://www.2weistein.de/ There exists a demo of the first 2 levels, but the level 'Lyrias Zauberbann' where fps varies much is not part of the demo. How to make sense of these observations? Thanks for your help, Jörg Höhle Testing using an "early 2009" NVidia Mac Mini with OS X 10.5.8 and XQuartz 2.6.1

3 2

Wine's implementation of d3dtypes.h does not work with ISO C++
by Daniel Scharrer May 24, 2011

May 24, 2011

Hi all, I am working on porting the d3d 7 game Arx Fatalis [1] to linux/OpenGL and we are currently compiling as a winelib application to do so. Because the game is written in c++ and defines D3D_OVERLOADS, I get the following errors in d3dtypes.h (reported as wine bug [2]): /usr/include/wine/windows/d3dtypes.h: In member function ‘D3DVALUE& _D3DMATRIX::operator()(int, int)’: /usr/include/wine/windows/d3dtypes.h:339:30: error: ISO C++ forbids casting to an array type ‘D3DVALUE [4][4]’ /usr/include/wine/windows/d3dtypes.h: In member function ‘const D3DVALUE& _D3DMATRIX::operator()(int, int) const’: /usr/include/wine/windows/d3dtypes.h:341:36: error: ISO C++ forbids casting to an array type ‘const D3DVALUE [4][4]’ Notice that is is a fatal error and not just a warning unless -fpermissive is passed to wineg++. While we can work around this when using gcc (using pragmas to enable -fpermissive just for wine's d3d headers), there is no portable way (across compilers) to use Direct3D's overloaded operators from wine's implementation. The bug report [2] hasn't gotten any real responses and I'd really like to get this fixed, but don't know what the best solution would be that follows wine coding conventions. Wine's current implementation of D3DMATRIX is typedef struct _D3DMATRIX { D3DVALUE _11, _12, _13, _14; D3DVALUE _21, _22, _23, _24; D3DVALUE _31, _32, _33, _34; D3DVALUE _41, _42, _43, _44; #if defined(__cplusplus) && defined(D3D_OVERLOADS) _D3DMATRIX() { } /* This is different from MS, but avoids anonymous structs. */ D3DVALUE &operator () (int r, int c) { return ((D3DVALUE [4][4])&_11)[r][c]; } const D3DVALUE &operator() (int r, int c) const { return ((const D3DVALUE [4][4])&_11)[r][c]; } #endif } D3DMATRIX, *LPD3DMATRIX; MSDN doesn't seem to have a documentation for anything older than d3d 9 anymore, so I have no idea what the original definition looks like. The comment indicates that anonymous structs aren't allowed -- is this correct? An alternative solution would be to calculate the 2D array offsets manually, something like this: D3DVALUE &operator () (int r, int c) { return ((D3DVALUE*)&_11)[r*4 + c]; } Would that implementation be acceptable? Also, if D3D_OVERLOADS has been defined, wine's d3dtypes.h (and also d3d.h) expect <math.h> to have already been included: In file included from /usr/include/wine/windows/d3dtypes.h:346:0, from /usr/include/wine/windows/d3d.h:26, from test.cpp:4: /usr/include/wine/windows/d3dvec.inl: In function ‘D3DVALUE Magnitude(const _D3DVECTOR&)’: /usr/include/wine/windows/d3dvec.inl:118:33: error: ‘sqrt’ was not declared in this scope As I don't have a copy of the d3d 7 SDK I can't check if this is normal or another bug in the wine headers. [1] https://github.com/lubosz/ArxFatalis [2] http://bugs.winehq.org/show_bug.cgi?id=25942 -- Daniel Scharrer

2 1

Question about the fSources argument to SHChangeNotifyRegister
by Jay Yang May 24, 2011

May 24, 2011

Hi, Could someone who understands the fSources argument to SHChangeNotifyRegister explain it to me? MSDN says it can take some combination of SHCNRF_InterruptLevel, SHCNRF_ShellLevel, SHCNRF_RecursiveInterrupt, and SHCNRF_NewDelivery. I've looked at the source and it seems that the only one wine handles differently is SHCNRF_NewDelivery, so what do the others mean? MSDN says something about it but quite frankly I don't know what the difference between interrupt level and shell level notifications are. Also the the only place in the tree where wine uses this function, in dlls/shell32/shlview.c, it gets passed SHCNF_IDLIST, which isn't even one of the values. SHCNF_IDLIST happens to be defined as 0, but I think that's irrelevant. Thanks -- Jay Yang

1 0

Re: [1/5] d3d: Make the INTZ test more reliable
by Henri Verbeet May 23, 2011

May 23, 2011

On 23 May 2011 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This eliminates the precision issues caused by the projected texture by > setting the .w coordinate to a constant value. I decided to keep the > projected sampling itself around to demonstrate that d3d doesn't do anything > special with the 3rd and 4th value like it does with other shadow formats The 3rd and 4th coordinate are going to be the same for the locations you're sampling now.

2 1

Re: [PATCH 3/5] d3d9/tests: Fix the depth clamping test.
by Marvin May 23, 2011

May 23, 2011

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=11124 Your paranoid android. === WXPPROSP3 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W2K3R2SESP2 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === WVISTAADM (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W2K8SE (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PRO (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PROX64 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PROX64 (64 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c

1 0

Re: dbghelp: Implement SymEnumSourceFilesW.
by Alexandre Julliard May 23, 2011

May 23, 2011

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > This fixes bug 27222. > > --- > dlls/dbghelp/dbghelp.spec | 2 +- > dlls/dbghelp/source.c | 102 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 103 insertions(+), 1 deletions(-) The A version should call the W one, not the other way around. -- Alexandre Julliard julliard(a)winehq.org

2 2

no line numbers in backtraces on Mac OS X?
by Joerg-Cyril.Hoehle＠t-systems.com May 23, 2011

May 23, 2011

Hi, Is it normal that there are no source line numbers in backtraces on Mac OS? Despite many patches to winedbg etc., the backtraces I get are no better that those from 1.1.24 times. 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) I'm using configure + make to build. On Linux, the line numbers help a lot in locating bogus code. Thank for your help, Jörg Höhle.

4 4

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 7 resend)
by Alexandre Julliard May 23, 2011

May 23, 2011

Charles Davis <cdavis(a)mymail.mines.edu> writes: > Rebased against Marcus Meissner's DECLSPEC_HIDDEN patches. (I hate you, Marcus...) > Try 7: Fix getting the device name for IDE devices. > Try 6: Fix some problems noticed by Vitaliy Margolen. > Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. > Try 4: Fix unused variable warning. > Try 3: Add support for IDE drives. > Try 2: Don't depend on the SCSI generic driver on Linux. The unix device name is not being set properly here. I would consider not setting the key a feature (we don't really need it), but it means the DMA flag isn't set either. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Partially implement FlashWindowEx with tests (try 2)
by Alexandre Julliard May 23, 2011

May 23, 2011

André Hentschel <nerv(a)dawncrow.de> writes: > + for (i=0; i<pfwi->uCount + 1; i++) > + { > + FlashWindow(pfwi->hwnd, TRUE); > + Sleep(msecs); > + FlashWindow(pfwi->hwnd, FALSE); > + Sleep(msecs); > + } I don't think you want to hang the app that way. -- Alexandre Julliard julliard(a)winehq.org

1 0