July 2008 - Wine-devel - list.winehq.org

RE: [1/3] WineD3D: Use C bitfields to compact the ffp description
by Stefan Dösinger 28 Jul '08

28 Jul '08

Don't apply the patches yet, they break the d3d7 visual tests > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Monday, July 28, 2008 11:44 AM > To: wine-patches(a)winehq.org > Subject: [1/3] WineD3D: Use C bitfields to compact the ffp description >

1 0

Re: d3dx8: [patch 2/2] Implement D3DXBoxBoundProbe
by H. Verbeet 28 Jul '08

28 Jul '08

2008/7/28 David Adam <david.adam.cnrs(a)gmail.com>: > + ortho = D3DXVec3Dot(praydirection, &normal[i]); > + if ( ortho && D3DXVec3Subtract(&difference, &point, prayposition) ) > + { > + t = D3DXVec3Dot(&difference, &normal[i]) / ortho; While correct, due to the fact that the box is axis-aligned, this just turns into an expensive way to calculate t = (point->x - prayposition->x) / praydirection->x t = (point->y - prayposition->y) / praydirection->y t = (point->z - prayposition->x) / praydirection->z depending on the face you're testing against. I think performance wise it makes more sense to just write it out for each face, and get rid of the for-loop and normal. > + if ( number_intersection == 2 ) return TRUE; This implies that eg. a ray that starts inside the box doesn't intersect it. Is that intentional? Otherwise you could return early as soon as you find an intersection, and skip testing the other faces. Also note that at least in theory the ray can intersect all six faces of the box if it goes through two opposing corners.

1 0

Re: wined3d: in surface Blt when source and destination are not the same only lock the part of the destination surface that is requested to copy to.
by H. Verbeet 28 Jul '08

28 Jul '08

2008/7/28 Aric Stewart <aric(a)codeweavers.com>: > + if (Src != This) > + { > + xdst.top = 0; > + xdst.bottom = DestRect->bottom - DestRect->top; > + xdst.left = 0; > + xdst.right = DestRect->right - DestRect->left; > + } This will still break the rectangle bounds check further down (around line 940), and anything else that depends on the position of the rectangle within the surface. Come to think of it, the rectangle bounds check should probably be done before trying to lock the surface. Something else I just thought of is that LockRect() probably won't handle mirrored or flipped destination rectangles very well.

2 2

Re: ole32: fix offsets managment
by f.dorin＠free.fr 28 Jul '08

28 Jul '08

>Thank you for your first contribution, but first of all the subject >isn't correct as the patch is to rpcrt4 instead of ole32. Oups, sorry. My apologies for this mistake. But I'm currently working on ole32 and I forgot this file belongs to rpcrt4. I will pay attention next time. >Second of >all, the patch is not correct as it is widl that is generating the >wrong format string here: > >http://www.winehq.org/pipermail/wine-patches/2008-June/056332.html >http://www.winehq.org/pipermail/wine-devel/2008-June/066587.html Thanks for the links. I didn't think one moment it can be a widl bug. I believed it was a rpcrt4 one. François DORIN

1 0

Re: [PATCH] ntdll: use symbols, add documentation for i386 page faulterror code
by Dmitry Timoshkov 28 Jul '08

28 Jul '08

"John Reiser" <jreiser(a)BitWagon.com> wrote: > diff --git a/include/winnt.h b/include/winnt.h > index e8a37f5..ad2f674 100644 > --- a/include/winnt.h > +++ b/include/winnt.h > @@ -812,9 +812,24 @@ typedef struct _CONTEXT86 > > typedef CONTEXT86 CONTEXT; > > -#define EXCEPTION_READ_FAULT 0 > -#define EXCEPTION_WRITE_FAULT 1 > -#define EXCEPTION_EXECUTE_FAULT 8 > +/* Page Fault Error Code. > + * Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A: > + * System Programming Guide, Part 1; Figure 5-9, Page-Fault Error Code, p.5-55. > + * http://www.intel.com/design/processor/manuals/253668.pdf > + * linux/arch/x86/mm/fault.c do_page_fault() > + */ > +/* This hardware bit is ignored by shifting it off the bottom. > + *#define EXCEPTION_PAGE_NOT_P (0<<0) > + *#define EXCEPTION_PROT_VIOL (1<<0) > + * > + * Hardware delivers these bits [below] one position to the left. > + */ > +#define EXCEPTION_READ_FAULT (0<<0) > +#define EXCEPTION_WRITE_FAULT (1<<0) /* 1 */ > +#define EXCEPTION_KERNEL_MODE (0<<1) > +#define EXCEPTION_USER_MODE (1<<1) /* 2 */ > +#define EXCEPTION_RSV_PAGETAB (1<<2) /* 4 */ > +#define EXCEPTION_EXECUTE_FAULT (1<<3) /* 8 */ These changes are not compatible with PSDK. -- Dmitry.

1 0

Re: wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)
by Stefan Dösinger 28 Jul '08

28 Jul '08

> Well, the last attempt (with added big-endian support) was submitted several > days ago, and again - no feedback, and patch still isn't accepted. > What's wrong with patch now? Sorry, I must have missed this on Wine-patches again :-( It look ok to me. The endianess #ifdefs look strange, but I don't know how that's supposed to be handled. PS: Sorry, I lost the original mail. I don't know how to supply a reference ID to outlook, so I broke the thread appart

1 0

Re: [WideChar conversion improvements - 2/5] Implement new versions ofwctomb and wcstombs
by Dmitry Timoshkov 28 Jul '08

28 Jul '08

"Colin Finck" <mail(a)colinfinck.de> wrote: > -INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch ) > +INT CDECL MSVCRT_wctomb(char *mbchar, MSVCRT_wchar_t wchar) What's the point of the above change? > { > - return WideCharToMultiByte( CP_ACP, 0, &ch, 1, dst, 6, NULL, NULL ); > + BOOL bUsedDefaultChar; > + char chMultiByte[MSVCRT_MB_LEN_MAX]; > + int nBytes; Please don't use ugly mixed case variable names. Same for other tests. > + > + /* At least one parameter needs to be given, the length of a null character cannot be queried (verified by tests > under WinXP SP2) */ > + if(!mbchar && !wchar) > + return 0; Please keep line length close to 80 columns limit. What are you calling a "null character" here? A NULL pointer is not a NUL character. What happens in the code below if mbchar is not NULL but wchar is? > + > + /* Use WideCharToMultiByte for doing the conversion using the codepage currently set with setlocale() */ > + nBytes = WideCharToMultiByte(MSVCRT___lc_codepage, 0, &wchar, 1, chMultiByte, MSVCRT_MB_LEN_MAX, NULL, > &bUsedDefaultChar); -- Dmitry.

3 3

Re: [WideChar conversion improvements - 5/5] Add a lot of WideCharToMultiByte tests
by Vitaliy Margolen 28 Jul '08

28 Jul '08

Colin Finck wrote: > Remove todo_wine from two tests, which now pass under Wine after the > changes in my previous patches. You have to do that in the patch that fixes the test. Each patch have to be autonomous and have all tests pass before and after it. Vitaliy.

2 2

Re: [3/5] WineD3D: Optimize the fragment processing description
by H. Verbeet 28 Jul '08

28 Jul '08

Is there any particular reason you're not simply using the compiler's support for bit-fields?

3 4

Re: [10/10] [try 5] appwiz.cpl: Gather extra information for SupportInfo dialog
by Owen Rudge 28 Jul '08

28 Jul '08

> 3 files changed, 86 insertions(+), 0 deletions(-) I'm just wondering if there's a reason this patch wasn't committed with the other appwiz patches? The patch applies cleanly to the current git master. If there's anything obviously wrong with it that I've not spotted, please do let me know so I can fix it. Cheers, -- Owen Rudge http://www.owenrudge.net/

2 1