wine-devel July 2006

wine-devel@winehq.org

142 participants
297 discussions

Re: mapi32: Write-strings warnings fix
by Alexandre Julliard 03 Jul '06

03 Jul '06

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > @@ -113,8 +114,8 @@ > } > if (message->nFileCount) FIXME("Ignoring attachments\n"); > > - subject = message->lpszSubject ? message->lpszSubject : ""; > - body = message->lpszNoteText ? message->lpszNoteText : ""; > + subject = message->lpszSubject ? message->lpszSubject : empty; > + body = message->lpszNoteText ? message->lpszNoteText : empty; These are … [View More]

2 3

Re: [Bug 5592] Fifa06 Demo closes directly after starting
by Dejan Velimirovic 03 Jul '06

03 Jul '06

Are you using real windows drive, instead of virtual windows drive by any chance? It's not recommended to do that.

1 0

Re: [Bug 5592] New: Fifa06 Demo closes directly after starting
by Dejan Velimirovic 03 Jul '06

03 Jul '06

Does it output something in terminal? I think it's caused by some copyprotection.

1 0

Semantics, shaders, and fixups
by Ivan Gyurdiev 03 Jul '06

03 Jul '06

Hi, Here's another problem with shaders. Vertex shader input is marked up with tags that hint at the data usage - semantics. For the fixed pipeline, those tags must be 100% correct, because they tell the pipeline how to interpret the data - is that the position stream, or the color stream, or the texcoord stream. For shaders, however, I think this is not the case. Since the app has control of the shader, it doesn't need to give meanings to the different semantics. I've looked at two … [View More]demos, which demonstrate various problems. Demo #1: Instancing: http://www.humus.ca/index.php?page=3D&ID=52 This demo has hlsl shaders, which make use of the TEXCOORD8 semantic. This is an invalid semantic, according to the way we map things, since only 0-7 texcoords are supported. Furthermore, comments make it clear that this is not texture data. It would seem that the semantic is just meant to relay the data to the vertex shader input that is marked dcl_texcoord8. This means that we need to support all semantic names and indices 0-15 as possible labels for shader input data. MSDN even mentions that texcoord can be used for user-defined data. This presentation: http://www.ati.com/developer/gdc/D3DTutorial1_Shaders.pdf , has examples which make use of position > 0, normal > 0, etc, which are all invalid on the fixed function pipeline. I am currently working on a very large patch, which will restructure strided data to address this problem, but that's not all. Demo #2: Many Per Pixel Lights, http://www.zanir.szm.sk/dx/017_Many_Per_Pixel_Lights.zip This is a d3d8 demo. The shader inputs are not marked with a semantic - the declaration data is mapped 1:1 to the shader inputs, so a specific register number is designated as the D3DVSDE_DIFFUSE register. Now, consider that we use the semantic to implement shader fixup - flipping red and blue on color inputs. Previously this fixup did not work at all on d3d8 shaders (as far as I can tell), and I just made it work today, by storing a fake semantic for d3d8 shaders. The result is that in the demo above, everything turned green, and very wrong. Why? Looking at the demo it seems that it loads registers that contain user-defined data in all the declaration inputs, without paying any attention to the "meaning" of that register, since it controls the shader. As a result, we are flipping random data, that could be important, and not red and blue. In this particular case, it's a relative address token, which means that's absolutely critical that it gets the right value - that's why everything breaks. Therefore, how can we rely on a semantic tag for shader fixups? Seems we can't do that. Also, I don't understand why we're applying fixups on shader input either. Can someone explain why this fixup is needed exactly? If we need to flip red and blue because the format is backwards, shouldn't this be done at the end of the pipeline, at the point of interpretation by GL. Flipping things at an intermediate point can affect all kinds of calculations in the shader. At the end of the pipeline we can also reliably tell what's to be interpreted as color data, instead of following semantic hints. Any thoughts? [View Less]

2 10

Re: [setupapi] fix return values and GUID string in SetupDiOpenClassRegKeyExW
by Joris Huizer 03 Jul '06

03 Jul '06

Damjan Jovanovic wrote: > + guidStringWithBraces[0] = (WCHAR) '{'; > + CopyMemory(&guidStringWithBraces[1], lpGuidString, > + (MAX_GUID_STRING_LEN - 3)*sizeof(WCHAR)); > + guidStringWithBraces[MAX_GUID_STRING_LEN - 2] = (WCHAR) '}'; > + guidStringWithBraces[MAX_GUID_STRING_LEN - 1] = 0; > + RpcStringFreeW(&lpGuidString); Just wondering, shouldn't that be something like guidStringWithBraces[0] = (WCHAR) '{'; CopyMemory(&… [View More]

2 1

Re: Slow EULA display patch
by Alexandre Julliard 03 Jul '06

03 Jul '06

Daniel Steven Hipschman <dsh(a)linux.ucla.edu> writes: > ChangeLog: > * Sped up GetTextExtentExPointW by adding a new freetype GDI font function > WineEngGetTextExtentExPoint and a new DC function pGetTextExtentExPoint. Looks good, but you should remove the non-Ex entry points in freetype.c and the DC table, there's no reason to have both. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Slow EULA display patch
by Dan Kegel 03 Jul '06

03 Jul '06

Krzysztof wrote: >Well, *great* to see that solved in the Wine core, but I still think I >have a bug in RichEdit, because the original (native) riched20 works >fast, despite the bug you just fixed. Is there a good test document for which our riched20 is (with Dan H's patch) still way too slow? If so, let's dig into this. FWIW, Dan H also explored a change to make a riched "run" struct be refcounted; that gave a 4x speedup. Then he switched to using git bisect to find the cause of … [View More]

2 1

A big online GUID-List
by Detlef Riekenberg 02 Jul '06

02 Jul '06

Found a big online GUID-List: http://www.myplugins.info/guids/guidlist.php -- By By ... ... Detlef

1 0

re: Any chances to get some feedback on latests mswsock patch?
by Dan Kegel 02 Jul '06

02 Jul '06

In addition to Juan's comments: it would be nice if, when you post new patches that obsolete old ones, if you stated that clearly. Otherwise we have to think a bit to decide if they apply on top of your old ones.

1 0

Re: Slow EULA display patch
by Krzysztof Foltman 01 Jul '06

01 Jul '06

Daniel Steven Hipschman wrote: > This patch fixes the slow EULA loading problem in > http://bugs.winehq.org/show_bug.cgi?id=5516 Well, *great* to see that solved in the Wine core, but I still think I have a bug in RichEdit, because the original (native) riched20 works fast, despite the bug you just fixed. Krzysztof

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2006