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

Re: New bugzilla components (round 3)

by Jan Zerebecki

I think I will be able to do the changes next weekend. If no one objects until Friday, I'll assume that everyone is fine with the changes as proposed in this thread. I'll furthermore assume that I can modify the descriptions of categories as I see fit (I explained in a previous mail on this topic on how those could be made to convey more exactly which parts of wine they cover). I just saw that there still are overlaping categories in at least one case, but that can be fixed in another step. Jan

Jan. 1, 2008

Re: [5/6] ddraw: fix palette copying when destination palette is NULL

by Stefan Dösinger

Am Mittwoch, 2. Januar 2008 02:16:13 schrieb Alexander Dorofeyev: > OK, thanks a lot. Regarding vertex structure - I'm afraid I can't reuse > struct vertex/nvertex, because I need a very specific format for this test > (D3DFVF_XYZRHW | D3DFVF_DIFFUSE). I could probably reuse sVertexT from > fogtest, but then I'll also have to set specular, that I don't really need. > I looks easier to declare a custom format that has just what I need. Ah, that's ok then. I forgot that the other vertex has a specular color, so a new vertex type is fine. > I've ran into some issues while trying to write a test for the old D3D > TEXTUREMAPBLEND state AVP1 game uses. I hope you can help me a bit with it. Yeah, IDirect3DDevice(1) and IDirect3DExecuteBuffer are a royal pain in the ass. Here's some popular rant about it to ease your pain: http://www.exaflop.org/docs/d3dogl/d3dogl_jc_plan.html I think that a test using execute buffers is a great thing. This interface is terribly obscured and we have only one small test for it. You can add it to visual.c if you want, or a new file(maybe executebuffer.c, or something), I think both places are ok. You can also try to QueryInterface old IDirect3DDevice* versions from IDirect3DDevice7, but I think this doesn't work as the COM theory says on Windows. I haven't yet tested the restrictions and implemented them because I haven't seen a game yet that depends on them.

Jan. 1, 2008

Re: bugs audit volunteers required

by Jan Zerebecki

On Mon, Dec 31, 2007 at 06:49:56PM -0600, Austin English wrote: > On Dec 31, 2007 6:42 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: > > I agree. If you cannot find the application or a demo version to work > > with, how can you fix the > > bug. Logs and other helpers go a long way. Maybe an intro page as to > > what is needed and how > > to get it. This will become more and more critical as the project > > approaches 'release' status (1.0). > > Also, marking bugs as having insufficient information to fix advises the > > reporter that the project > > needs more information to help or troubleshoot. > > Maybe add a resolution of NEEDMOREINFO? We could add flags for "needs more information" and perhaps one for "reproducible bug report with enough initial information". (A flag is something that can be requested to be set and can then be granted or denied by someone who was given the required rights.) > > Clicking on the "NEW BUG" link should take a person to > > a web page with reporting > > criteria. At this point, the reporter will read through a page of what > > should be done to report a > > bug. After clicking a 'I read and understand the reporting > > requirements', then the reporter will be > > able to submit a bug. After a few cycles of this, regular reporters > > will not be subject to this page and > > will be taken instead to the regular bug reporting page. For the > > occasional reporter, this is a good way > > to handle bug reports, IMHO. Our bugzilla is in git, patches are welcome. I think a small and easy explanation on the new-bug form, that refers one to a wiki page for the full guide is a good thing. (I guess it's probably hard to filter bad bug reports automatically and even harder to not inconvenience our good bug reporters at the same time.) Jan

Jan. 1, 2008

Re: bugs audit volunteers required

by Jan Zerebecki

On Mon, Dec 31, 2007 at 05:49:14PM -0700, James McKenzie wrote: > Austin English wrote: > > On Dec 31, 2007 6:10 PM, Maarten Lankhorst <maarten(a)codeweavers.com> wrote: > >> The situation isn't improved by the fact that bugs are reopened by those > >> persons after minimal additions. Perhaps we should have a bug > >> moderation? Only allow bugs that follow the criterion, then have a way > >> for bugzilla admins to accept bug reports and then a new bug report > >> entry is created in bugzilla. > > > > Does bugzilla support this? How about not allowing someone without > > higher bugzilla privileges to reopen bugs? > > > It should. Some of the other projects I work on will only allow a > person with admin level to change > the status of a submitted bug, including re-opening. I would also like > to see this with bugzilla, even > though I am an ordinary 'user'. This would prevent users from closing > a bug report and then opening > it again, even if the problem affects a different module. IMHO, these > are two separate bugs. If you know how to configure bugzilla to prevent the bug creator from reopening it, I'd like to hear about it (AFAIK it's not possible). As far as I remember regular users who are not the creator are already disallowed from changing the resolution. Jan

Jan. 1, 2008

Re: [5/6] ddraw: fix palette copying when destination palette is NULL

by Stefan Dösinger

Am Dienstag, 1. Januar 2008 11:19:50 schrieb Alexander Dorofeyev: > OK, I'll see what I can do with the test. Speaking of tests, I submitted > test for zero vertex rhw case (as suggested by H.Verbeet to avoid future > regressions), but I think it didn't get accepted. Perhaps, you can look > through it and provide some feedback? Would be good to hear the bad news > now, before I submit more wrong stuff (esp. considering that I'm also > trying to write a test for another issue with Aliens vs Predator 1 that I > want to fix). I'm attaching the zero rhw test. It is likely that Alexandre was waiting for an OK from me or Henri. He is the only committer, but when someone he doesn't know sends a patch he usually waits for the OK from someone who is maintaining the part of Wine. I think I forgot to send an OK mail to the test when you submitted it. A few minor suggestions for the test: * The vertex structure should be declared somewhere else already, as part of the lighting test I think. You can reuse that instead of redeclaring it. * You don't have to AND the color if 0xffffff, getPixelColor should do that already. * You don't have to set the render states unless you need a different setting than the previous tests leave behind * The "if(hr == D3D_OK)" after BeginScene should be changed to "if(SUCCEEDED(hr))"

Jan. 1, 2008

Commit stats

by Hans Leidekker

$ for y in {2002..2007}; do \ n=$( git log | grep ^Date: | grep $y | wc -l ); \ echo "Number of commits in $y: $n"; \ done Number of commits in 2002: 3094 Number of commits in 2003: 3283 Number of commits in 2004: 3851 Number of commits in 2005: 6006 Number of commits in 2006: 8431 Number of commits in 2007: 9526 -Hans

Jan. 1, 2008

Re: [5/6] ddraw: fix palette copying when destination palette is NULL

by Alexander Dorofeyev

OK, I'll see what I can do with the test. Speaking of tests, I submitted test for zero vertex rhw case (as suggested by H.Verbeet to avoid future regressions), but I think it didn't get accepted. Perhaps, you can look through it and provide some feedback? Would be good to hear the bad news now, before I submit more wrong stuff (esp. considering that I'm also trying to write a test for another issue with Aliens vs Predator 1 that I want to fix). I'm attaching the zero rhw test. Stefan Dösinger wrote: > Am Montag, 31. Dezember 2007 12:43:37 schrieb Alexander Dorofeyev: >> The thing that it tries this copy palette thing at all (AVP1 doesn't depend >> on that BTW, it does SetPalette on both source and target) - that shouldn't >> be difficult to test, I think I could write it. Beyond that, I don't know, >> the documentation on these old interfaces seems non-existant. Is there a >> way to obtain DX6 docs? > I suspect that we shouldn't copy the palette at all, I think Texture::Load and > friends just copy the bytes over. A test could verify / falsify that. As for > the docs, there were older dx docs available on some websites, but I lost the > link. I'll see if I can find it. diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c index c9a3147..2269d70 100644 --- a/dlls/ddraw/tests/visual.c +++ b/dlls/ddraw/tests/visual.c @@ -761,6 +761,66 @@ static void alpha_test(IDirect3DDevice7 *device) if(backbuffer) IDirectDrawSurface7_Release(backbuffer); } +static void rhw_zero_test(IDirect3DDevice7 *device) +{ +/* Test if it will render a quad correctly when vertex rhw = 0 */ + HRESULT hr; + DWORD color; + + struct { + float x, y, z; + float rhw; + DWORD diffuse; + } quad1[] = + { + {0, 100, 0, 0, 0xffffffff}, + {0, 0, 0, 0, 0xffffffff}, + {100, 100, 0, 0, 0xffffffff}, + {100, 0, 0, 0, 0xffffffff}, + }; + + /* Clear to black */ + hr = IDirect3DDevice7_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0, 0.0, 0); + ok(hr == D3D_OK, "Clear failed, hr = %08x\n", hr); + + /* Setup some states that may cause issues */ + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_CLIPPING, FALSE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState returned %08x\n", hr); + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_ZENABLE, FALSE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState returned %08x\n", hr); + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_FOGENABLE, FALSE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState returned %08x\n", hr); + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_STENCILENABLE, FALSE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState returned %08x\n", hr); + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_ALPHATESTENABLE, FALSE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState returned %08x\n", hr); + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_ALPHABLENDENABLE, FALSE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState returned %08x\n", hr); + hr = IDirect3DDevice7_SetRenderState(device, D3DRENDERSTATE_CULLMODE, D3DCULL_NONE); + ok(hr == D3D_OK, "IDirect3DDevice7_SetRenderState failed with %08x\n", hr); + hr = IDirect3DDevice7_SetTextureStageState(device, 0, D3DTSS_COLORARG1, D3DTA_CURRENT); + ok(hr == D3D_OK, "SetTextureStageState failed, hr = %08x\n", hr); + hr = IDirect3DDevice7_SetTextureStageState(device, 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1); + ok(hr == D3D_OK, "SetTextureStageState failed, hr = %08x\n", hr); + + hr = IDirect3DDevice7_BeginScene(device); + ok(hr == D3D_OK, "IDirect3DDevice7_BeginScene failed with %08x\n", hr); + + if (hr == D3D_OK) { + hr = IDirect3DDevice7_DrawPrimitive(device, D3DPT_TRIANGLESTRIP, D3DFVF_XYZRHW | D3DFVF_DIFFUSE, quad1, 4, 0); + ok(hr == D3D_OK, "DrawPrimitive failed, hr = %08x\n", hr); + + hr = IDirect3DDevice7_EndScene(device); + ok(hr == D3D_OK, "IDirect3DDevice7_EndScene failed, hr = %08x\n", hr); + + color = (getPixelColor(device, 0, 0)) & 0xffffff; + ok(color == 0xffffff, "Got color %08x, expected 00ffffff\n", color); + + color = (getPixelColor(device, 101, 101)) & 0xffffff; + ok(color == 0, "Got color %08x, expected 00000000\n", color); + } +} + START_TEST(visual) { HRESULT hr; @@ -806,6 +866,7 @@ START_TEST(visual) fog_test(Direct3DDevice); offscreen_test(Direct3DDevice); alpha_test(Direct3DDevice); + rhw_zero_test(Direct3DDevice); cleanup: releaseObjects();

Jan. 1, 2008

Re: comdlg32: 2/2 PageSetupDlgW: Draw paper preview

by Dmitry Timoshkov

"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > > What's the reason of moving PRINTDLG_PS_ChangePrinterW and changing > > its indentation? > > > I added a few new functions which it depends on. The change of indentation > was accidental. I fail to see how you can satisfy new functions by moving it down, not up. -- Dmitry.

Jan. 1, 2008

Re: bugs audit volunteers required

by Vijay Kiran Kamuju

On Dec 31, 2007 6:49 PM, Austin English <austinenglish(a)gmail.com> wrote: > > On Dec 31, 2007 6:42 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: > > I agree. If you cannot find the application or a demo version to work > > with, how can you fix the > > bug. Logs and other helpers go a long way. Maybe an intro page as to > > what is needed and how > > to get it. This will become more and more critical as the project > > approaches 'release' status (1.0). > > Also, marking bugs as having insufficient information to fix advises the > > reporter that the project > > needs more information to help or troubleshoot. > > Maybe add a resolution of NEEDMOREINFO? > > +1 vote from me > > > > This would put a heavy load on the bug admins and actually slow down the > > process. I work on > > other projects. Clicking on the "NEW BUG" link should take a person to > > a web page with reporting > > criteria. At this point, the reporter will read through a page of what > > should be done to report a > > bug. After clicking a 'I read and understand the reporting > > requirements', then the reporter will be > > able to submit a bug. After a few cycles of this, regular reporters > > will not be subject to this page and > > will be taken instead to the regular bug reporting page. For the > > occasional reporter, this is a good way > > to handle bug reports, IMHO. > > Agreed. +1 vote from me Page should contain some info like critical info we need like logs, etc, steps to reproducec, download link. (check ubuntu launchpad). It should automatically create the bug in bugzilla, based on that info. -- VJ > > - Austin > > >

Jan. 1, 2008

Re: bugs audit volunteers required

by Austin English

On Dec 31, 2007 6:42 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: > I agree. If you cannot find the application or a demo version to work > with, how can you fix the > bug. Logs and other helpers go a long way. Maybe an intro page as to > what is needed and how > to get it. This will become more and more critical as the project > approaches 'release' status (1.0). > Also, marking bugs as having insufficient information to fix advises the > reporter that the project > needs more information to help or troubleshoot. Maybe add a resolution of NEEDMOREINFO? > This would put a heavy load on the bug admins and actually slow down the > process. I work on > other projects. Clicking on the "NEW BUG" link should take a person to > a web page with reporting > criteria. At this point, the reporter will read through a page of what > should be done to report a > bug. After clicking a 'I read and understand the reporting > requirements', then the reporter will be > able to submit a bug. After a few cycles of this, regular reporters > will not be subject to this page and > will be taken instead to the regular bug reporting page. For the > occasional reporter, this is a good way > to handle bug reports, IMHO. Agreed. - Austin

Jan. 1, 2008