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

Re: ddraw: Do not increase wined3d texture refcount in IDirect3DDevice7_GetTexture.

by Stefan Dösinger

On Friday 29 July 2011 17:17:45 Ričardas Barkauskas wrote: > This makes it behave like similar place in d3d8. The subject is confusing, otherwise it looks OK.

July 31, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Sunday 31 July 2011 12:02:35 Michael Mc Donnell wrote: > I figured out how to do the conversion using bit-fields. I've updated > the patch to include a test and implementation of UDEC3 and DEC3N > welding. Nice, I was just about to reply not to bother too much about it. No Windows driver I know of supports those formats. Wined3d doesn't implement them either. With the bitfields I'm not sure about stuff like endianess. My gut feeling would be to use bitmasks and shifts to separate a DWORD instead, but bitfields certainly look nicer. Beyond that endianess is a somewhat academic consideration with an API that's available on x86 only. So I'd say keep the bitfields. d3dx9 has a few of those issues(and similar things like float vs double) that should be good for a search and replace job. I've fixed a few of those issues in wined3d and friends, but I'm sure more are remaining. On Saturday 30 July 2011 14:13:00 Michael Mc Donnell wrote: > I've implemented D3DCOLOR welding as UBYTE4N welding as you described. > Test 14 improves the color comparison to check that it is correct. > +static BOOL weld_short4(void *to, void *from, float epsilon) > ... > SHORT truncated_epsilon = epsilon; This will cause a precision loss warning on msvc. Adding a cast should do. Some nitpicking: struct D3DXWELDEPSILONS uses "FLOAT" not "float". It is advised to stick to the API types. This is quite academic since a "F+static BOOL weld_short4(void *to, void *from, float epsilon) LOAT" is afaik just a typedef for "float", but it helps when porting Wine to different CPUs. I think we had problems with LONG vs long on amd64 because win32 uses 32 bit LONGs or something like that. > I've also added tests 25 and 27 for color usage index larger than 1. > The usage index is not capped like TEXCOORD > 7. It instead uses the > default value of 1e-6f. I've changed the implementation so it uses the > default value instead of printing out an error message. That's interesting. I wonder what those people in Redmond are smoking :-)

July 31, 2011

Re: Winhelp crash in assertion(0) if .hlp file is not found

by Bruno Jesus

I see, thank you. You protected the local calls instead of protecting the called function, I guess it's better this way. Best wishes, Bruno On Sun, Jul 31, 2011 at 03:55, Eric Pouech <eric.pouech(a)orange.fr> wrote: > I've just sent a patch that should fix it. > A+ > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > >

July 31, 2011

Re: [PATCH 1/5] mshtml: Added semi-stub implementation of IHTMLWindow2::status property

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=13084 Your paranoid android. === WVISTAADM (32 bit dom) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

July 31, 2011

Re: mshtml: Added semi-stub implementation of IHTMLWindow2::status property

by Jacek Caban

Please ignore this one. I will send proper version with other mshtml patches. Thanks, Jacek

July 31, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Sat, Jul 30, 2011 at 2:13 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > I still haven't figured out how to weld UDEC3 and DEC3N as I'm unsure > how to convert three integers to the 3*10-bit + 2-bit format. Do you > know any good sources? I figured out how to do the conversion using bit-fields. I've updated the patch to include a test and implementation of UDEC3 and DEC3N welding.

July 31, 2011

Re: Winhelp crash in assertion(0) if .hlp file is not found

by Eric Pouech

I've just sent a patch that should fix it. A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

July 31, 2011

Listed package maintainers

by Ben Klein

Hello everyone, For those of you who remember all the trouble I've had with my health, I'm on the mend now. I'm adjusting to some new medication that's doing wonders, and also adjusting to the new lifestyle they allow me to lead. I've just had a look at http://www.winehq.org/download, as I'm well out-of-date with Wine, and I see Maurilio and I are still listed as being the maintainers for the Debian packages, even though Kai Wasserbäch has taken over that duty (and thank you Kai for doing so!) I also notice the pages have been renamed (so instead of deb = ubuntu, ubuntu and debian are named correctly and unambiguously). I would like to voice my approval as former maintainer of the Debian packages, as token as that may seem at this stage. Kind regards, Ben

July 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, Jul 28, 2011 at 4:01 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am 26.07.2011 um 11:29 schrieb Michael Mc Donnell: >>> Wrt the D3DDECLTYPE epsilon, it may be more efficient to scale the epsilon and calculate the diff and comparison as UBYTEs rather than floats. You'll need the diff functions for the other types like *BYTE*, *SHORT* anyway. Also tests would be helpful here, especially how the epsilon is treated in normalized values like D3DCOLOR and UBYTE4N and how it is treated in non-normalized values like UBYTE4. >> >> Ok I'll look into that and get back to you later. I've implemented D3DCOLOR welding as UBYTE4N welding as you described. Test 14 improves the color comparison to check that it is correct. >>> Wrt the usage/index fields, what happens when a combination that isn't supported by the fixed function pipeline is used, e.g. NORMAL3 or POSITION5? Those are valid in a vertex declaration and can be used with shaders. >> >> It works because the code does not check the UsageIndex field, except >> for differentiating between DIFFUSE and SPECULAR. I've added test 13 >> that shows this (tested on Windows 7 and Linux). > You may still get into trouble with something like TEXCOORD10 > > I'd recommend to change test 13(or add a new one) that tests a TEXCOORD > 7 and COLOR > 1 Good catch. I've added test 25 that shows TEXCOORD is capped at 7 so it uses the epsilon for TEXCOORD7 when it welds TEXCOORD10. I've also updated the implementation to cap it at 7. I've also added tests 25 and 27 for color usage index larger than 1. The usage index is not capped like TEXCOORD > 7. It instead uses the default value of 1e-6f. I've changed the implementation so it uses the default value instead of printing out an error message. Test 15 to 23 tests welding of UBYTE4N, UBYTE4, SHORT2, SHORT2N, SHORT4, SHORT4N, FLOAT16_2, and FLOAT16_4. I've also improved the implementation to weld these types. I still haven't figured out how to weld UDEC3 and DEC3N as I'm unsure how to convert three integers to the 3*10-bit + 2-bit format. Do you know any good sources?

July 30, 2011

Re: [1/2] cmd/tests: Add FOR /D tests (try 2)

by Octavian Voicu

2011/7/29 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > On Fri, Jul 29, 2011 at 22:05, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: >> I believe you can also use this syntax [put for instruction in >> parentheses, add | sort at the end]: >> (for ... ...) | sort > > Yeah, but as usual, when NT4 enters in the dance... you get the > picture... doesn't support the same set of arguments as later > versions... > Sorting is of course a very recent problem ;) > > BTW I quickly tested your stuff, but I get a list of "prompt>echo ..." It works for me, but it does seem it has some problems. It seems cmd doesn't terminate the pipe nicely and sort throws an ugly error after cmd exits. It also kind of freezes after the command if you run it interactive. Cmd doesn't play nicely with non-windows executables, or the piping stuff is not properly implemented. $ ls bar baz foo x.cmd $ wine cmd /c x.cmd Z:\home\octav\x>(for /d %i in (*) do echo %i) | Z:\usr\bin\sort foo bar baz $ Z:\usr\bin\sort: read failed: -: Input/output error >> Btw, it's a horrible hack, but until you'll have a wine sort you can >> test with (for ... ...) | Z:\usr\bin\sort :) > > I'm sure AJ would appreciate that a lot ;) I wasn't even remotely suggesting committing such an atrocity! It was just to make sure the commented tests you commit are OK, but I guess you can also use native sort.exe. Come to think of it, if you add Z:\usr\bin to PATH it should work even better... Octavian

July 30, 2011