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

Re: [1/10] WineD3D: Call glFlush outside the GL lock
by H. Verbeet Aug. 4, 2008

Aug. 4, 2008

2008/8/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + /* No checkGLcall here to avoid locking the lock just for checking a call that hardly ever > + * fails > + */ I think explaining why there's no ENTER_GL()/LEAVE_GL() is more important there.

2 1

What to do with tests that run for ages (examples dplayx and msi/install)
by Paul Vriens Aug. 4, 2008

Aug. 4, 2008

Hi, The recent additions to the dplayx tests make these tests run very slow (or there is just a lot tested?). Is there a way to either split up these tests so they don't timeout or better yet find out if we can run them faster. This issue can be seen on W2K upwards. The same can be said about the msi/install tests. This however only seems to be an issue on XP and Vista. -- Cheers, Paul.

5 5

Re: [9/10] WineD3D: Test formats for surface support
by H. Verbeet Aug. 4, 2008

Aug. 4, 2008

2008/8/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + if(CheckDepthStencilCapability(Adapter, AdapterFormat, CheckFormat)) return TRUE; This is redundant, the depthstencil formats should already be caught by the CheckTextureCapability() call. I think you should set this up the same way as WINED3DRTYPE_TEXTURE, if only for maintainability.

1 0

Re: d3dx9: Implementation of D3DXMatrixDecompose and tests
by H. Verbeet Aug. 4, 2008

Aug. 4, 2008

2008/8/4 Luis Busquets <luis.busquets(a)ilidium.com>: > +#include "d3d9.h" ... > +#define module(vx,vy,vz) sqrt((vx)*(vx)+(vy)*(vy)+(vz)*(vz)) ... > +#include "stdio.h" You don't really need those.

1 0

RE: [3/3] wined3d: Handle CTXUSAGE_BLIT with offscreen targets and FBO ORM
by Stefan Dösinger Aug. 4, 2008

Aug. 4, 2008

> This is mostly for correctness, in practice we should always be able to > avoid using CTXUSAGE_BLIT for offscreen targets when FBO ORM is used. Not always actually. With my upcoming patches to perform YUV conversion in Blt I'll have to avoid the fbo_blit codepath in some situations even if fbo_blit is available and fbos are used

2 1

Re: dinput: the DIK_ keycode is not the same as the scancode.
by Vitaliy Margolen Aug. 4, 2008

Aug. 4, 2008

Aric Stewart wrote: > > It is mapped with the keyboard mapping to the resulting character. so > the key 'A' is DIK_A nomatter what its scancode or vkey would be. This > is relevent to Japanese keymapping where the '@' key is in the '[' > location the scancode for both is 0x22 but dinput generates DIK_AT in > japanese and DIK_LBRACKET in us_qwerty > > reworked to remove the giant case statement and hopefully be more clear. > remove japan specific stuff as with the proper keyboard scancodes it > works out. I'm still not clear why do you need to translate the v_key into char? This involves a round trip to the X server for each key press. Besides this will depend on the state of the num-lock, shift, etc. Which should not be the case for dinput. It should always return the same code for the key regardless of anything else. Vitaliy.

4 12

problem loading wine test projects windows vista
by Hongbo Ni Aug. 4, 2008

Aug. 4, 2008

Hi, I want to build and test wine test suite on window, I did ./tools/winapi/msvcmaker --no-wine that is ok, but when I try to open the fille winetest.dsw, 1. with Developer Studio 6.0, it compaints that all *.dsp files (such as dlls\advapi32\tests\advapi32_test.dsp) have been modified and can not be loaded as Developer Studio Project. 2. with Developer Studio 2008, half of the *.dsp files (such as dlls\user32\tests\user32_test.dsp) was reported corrupted after been converted into the current Visual C++ project format. Does anyone know what is the problem? Please help me. I really need to compile and run existing tests on window before I can write any test case for wine. Regards Hongbo Ni _________________________________________________________________ It's simple! Sell your car for just $40 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%…

2 3

RE: [wined3d] Remove arb_tex_npot for NV FX series in fixup_extensions
by Stefan Dösinger Aug. 4, 2008

Aug. 4, 2008

> this patch fixes performance regressions in Max Payne 2, Morrowind and > HL2 on nVidia GeforceFx based hardware. > It has been approved by Stefan Dösinger and verified by test > application (see source). Just to add this here as well, I think this patch is fine. I could not find any way to use the NP2 emulation for conditional NP2 textures like on ATI cards

1 0

Patch checking robot coming
by Dan Kegel Aug. 4, 2008

Aug. 4, 2008

After some discussion with Jeremy and Alexandre about how nice it would be to have some automated way to check patches before Alexandre commits them, I decided to have a go at creating one. What I have so far is a script that watches wine-patches and applies each patch to current git, then builds, and sends email with a subject line saying whether it worked, and a body containing a short "I'm a build robot" note, the patch, and the build log. You can see the code at http://code.google.com/p/winezeug/source/browse/#svn/trunk/patchwatcher Its main failing is that it doesn't understand patch series yet, but I should be able to get that going by rewriting get-next-patch.pl to take a bit more context into account. Right now it only emails the results to me, but it's probably nearly good enough to show results to other people. Question: where should the results go? I could put them up on a web site and/or email them to the patch's author and/or email them to a dedicated mailing list (e.g. wine-patches-buildlogs(a)winehq.org?) and/or email them to wine-devel. - Dan

4 5

re: [PATCH] AcceptEx Impelementation
by Dan Kegel Aug. 4, 2008

Aug. 4, 2008

Hi Scott! Three suggestions: 1) send one patch per email; use 1/2 and 2/2 in the subject line to make it clear they're related 2) port some existing accept() conformance tests from ws2_32/tests/sock.c to use AcceptEx(), add a bit to check the special new features, and make sure they pass on Windows. 3) Submit the acceptance tests first as a separate patch Thanks, Dan

1 0