March 2007 - Wine-Devel - list.winehq.org

Re: [11/19] cmd.exe: Add dir /Q support
by Alexandre Julliard March 13, 2007

March 13, 2007

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> writes: > + secBuffer = (LPBYTE) malloc(sizeNeeded * sizeof(BYTE)); > + if(!secBuffer) return; Please don't use malloc in Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

d3drm test implementation need comments and review
by Vijay Kiran Kamuju March 13, 2007

March 13, 2007

Hi, I have implemented some d3drm functions and made some changes. Original implementation is by David Adam. Currently I dont have a wine repository to test the patch. Before applying the patch please create the dlls/d3drm/tests directory Please send me you comments, regarding this. If there are any compilation/execution errors, please notify me. I will correct them (I dont have access to linux m/c currently) Thanks, VJ

2 1

Re: Add d3drmdef.h header - try 2
by Francois Gouget March 13, 2007

March 13, 2007

On Tue, 13 Mar 2007, Vijay Kiran Kamuju wrote: > Changelog > --------------- > Add minimalistic d3drmdef.h > > extern LPD3DVECTOR D3DRMAPI D3DRMVectorAdd(LPD3DVECTOR, LPD3DVECTOR, LPD3DVECTOR); Two nitpicks: Wine's headers usually don't specify extern (it's implicit). If there's a large list of functions it can also be nice to sort them in alphabetical order as other forms of grouping tend to break down after a time. But this is not a hard and fast rules and it is not always followed. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

2 1

Re: Set D3DCAPS2_DYNAMICTEXTURES flag
by Mirek March 13, 2007

March 13, 2007

Shouldn't we use WINED3DCAPS2_DYNAMICTEXTURES rather than D3DCAPS2_DYNAMICTEXTURES ? Mirek Slugen Kovács András napsal(a): > Hi, > Set D3DCAPS2_DYNAMICTEXTURES flag. > This makes Call of Duty 2 to run. Stefan told me, this function is supported, > but we don't advertise it currently. > > > > ------------------------------------------------------------------------ > > From e9398c4ee873ef8b8257fcb3db4945c858655732 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Andr=C3=A1s_Kov=C3=A1cs?= <andras(a)debian.sth.sze.hu> > Date: Tue, 13 Mar 2007 03:07:30 +0100 > Subject: [PATCH] Set D3DCAPS2_DYNAMICTEXTURES flag > > --- > dlls/wined3d/directx.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 209e745..c5898c6 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1879,7 +1879,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > > *pCaps->Caps = 0; > *pCaps->Caps2 = WINED3DCAPS2_CANRENDERWINDOWED | > - WINED3DCAPS2_FULLSCREENGAMMA; > + WINED3DCAPS2_FULLSCREENGAMMA | > + D3DCAPS2_DYNAMICTEXTURES; > *pCaps->Caps3 = 0; > *pCaps->PresentationIntervals = WINED3DPRESENT_INTERVAL_IMMEDIATE; > > > > ------------------------------------------------------------------------ > >

2 1

const cleanup round 1(commentary on what I found)
by Mike Schaadt March 13, 2007

March 13, 2007

Some of this was included in the patch submission. Some of it I had questions about. spawn.c : warnings may or may not be harmless depending on if esecvp attempts to modify the results. Specs indicate it doesn't, but the function typing doesn't indicate so(the difference is 'const char * const argv[]' and 'char *const argv[]') libs/wine/string.c: strstrW - returns the location where sub was found in str. I believe returning a non-const value is what is expected. Should this be changed to a non-const parameter, or just leave the warning as is? tools/winedump/pdb.c: pdb_exit [line 149,153,155] - freeing of const variable. Is this ok? I could imagine it *could* cause problems if what we are freeing isn't in readable/writeable memory. pdb_dump_symbols [line 293,403,409] - same as pdb_exit. pdb_dump_types [line 462] - ditto pdb_jg_dump line[514] - ditto pdb_ds_dump line[643] - ditto tools/winedump/search.c: get_type [line 305, 329] - freeing of const variable again. [line 314, 335] - both cases, set return_text to type_str. Either parsed_symbol's return_text needs to be constified, proto should be unconstified, or leave it in place as a necessary cast. Any comments on the above spots? what of these are necessary casts? what of these can/should be corrected, and what needs to be done to correct them? **patches submitted to wine-patches** the following were straight forward patches that shouldn't modify the flow of the program beyond fixing the warnings. libs/wine/string.c: strtolW and strtoulW - constify the endptr value. This is just an output value to indicate where in the array we stoped processing. Change causes this to be the same type as the first value. Reduces number of cast-qual warnings by 6. tools/winedump/lnk.c: dump_pidl [line 176] - switched to const. Value is never modified in the function. Removes a cast-qual warning. tools/winedump/symbol.c: symbol_clean_string - this function is modifying the string. This should most definitely *not* be a const parameter. It's not even logically const(as a comment tried to claim) as the the intent of the function is to make the type string Wine-friendly. That requires modifications to that string, and to the variable. Removes a cast-qual warning. Comments? questions? Current number of cast-qual warnings fixed: 8. Number deemed necessary: 0(you guys need to help me decide what of these need to remain) Number looked at: 24. Estimated number remaining: 521.

1 0

re: Add d3drmdef.h header - try 2
by Dan Kegel March 13, 2007

March 13, 2007

Vijay wrote: > Add minimalistic d3drmdef.h But why? None of the code in wine currently needs it. Maybe you should submit it together with the first bit of code that needs it. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

re: Add d3drmdef.h header
by Dan Kegel March 13, 2007

March 13, 2007

vijay wrote: > [complete d3drmdef.h] It seems premature to check that in without any code that uses it. Also, did you really write all that yourself? - Dan

3 5

Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)
by Dan Kegel March 12, 2007

March 12, 2007

On 3/11/07, Dan Kegel <dank(a)kegel.com> wrote: > I'm putting a list together at > http://wiki.winehq.org/DesktopMigrationProjects This, and all my other recent wiki changes, seem to have vanished in a puff of greasy black smoke. What's up? This isn't doing much for my trust in wikis... - Dan

4 10

CreateScalableFontResource - a few questions
by Chris Howe March 12, 2007

March 12, 2007

Hi all, For my first foray into contributing to Wine (a blast, so far :) ) I am implementing CreateScalableFontResource which is currently present in stub form, but when fully implemented should create .FOT files from .TTF files for (amongst other things) temporarily installing fonts by a successive call to AddFontResource (which exists in Wine). It was trivial to code the functionality for the flow of CreateScalableFontResource as per the documentation but my research into the .FOT file format threw up a couple of questions. Even though .FOT files, as far as they're used by AddFontResource are little more than storage for a couple of pathnames, they are in fact Win3.1-style NE-binary files. With that in mind, 1) AFAICT, there is no code in Wine currently to save NE-binaries to disk, although obviously they are loadable and data structures relating to the format are defined. Rather than write a standalone, .FOT saving function, based off the kind of code you see in the fnt2fon program - .FON files are a similar, though not identical format - would it be better to write something like a NE_SaveModule that takes an in-memory NE module and saves it to disk, and call that from my .FOT saving code? This would live in ne_module.c I guess, and be limited, certainly initially, to the context in which I'd be using it. IE, just saving the resources. Indeed, I don't know in what other context that code WOULD be used, but who knows, down the line someone might want to expand it to do something more useful. 2) NE binaries, including FOT files, contain as part of the header a DOS stub-executable that typically spits out a message of some sort. I reasoned that being in itself a compiled binary we can't legally use the blob of binary that would appear in a real-world FOT file as-is, and I certainly wasn't about to go decompiling it, so I lifted the DOS stub executable from fnt2fon which I'm assuming as it's distributed with WINE is fair game. This will mean .FOT files generated by my code will be slightly different to a real, "in-the-wild" .FOT file, but I'm not sure in the circumstances that matters as the file is typically temporary, and only used as a container, never to be run - it's just different from a user perspective. Is this OK? Also, are there any open-source requirements on that small binary blob? Fnt2fon certainly includes it with no added info. 3) Related to item 2, so far, the actual spec of the .FOT file format has eluded me, though knowing that it's a NE binary has enabled me to reverse a lot of it, which I'm yet to test but I believe will be enough to fool AddFontResource into doing what it's supposed to do. Again, is it enough to go that far for now as the FOT format seems to be unsupported in WINE? Advice on these points would help me help you :) -- Chris Howe

2 1

DirectX 10 start as a SoC project?
by Stefan Dösinger March 12, 2007

March 12, 2007

Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: -> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan

11 21

Re: CreateScalableFontResource - a few questions
by Juan Lang March 12, 2007

March 12, 2007

Hi Chris, > For my first foray into contributing to Wine Welcome! > would it be better to write something like a NE_SaveModule that takes > an in-memory NE module and saves it to disk, and call that from my > .FOT saving code? Only if it makes your code more readable. In general Wine doesn't share code between modules, unless Windows does. So this would almost certainly be kept in gdi32, unless you know of a public Windows API that does what you suggest. > 2) NE binaries, including FOT files, contain as part of the header > a DOS stub-executable that typically spits out a message of > some sort. I reasoned that being in itself a compiled binary we > can't legally use the blob of binary that would appear in a > real-world FOT file as-is, and I certainly wasn't about to go > decompiling it, so I lifted the DOS stub executable from fnt2fon > which I'm assuming as it's distributed with WINE is fair game. That seems reasonable to me. > Also, are there any open-source requirements on that small binary > blob? Fnt2fon certainly includes it with no added info. Taking it from fnt2fon seems safe enough to me too. > 3) Related to item 2, so far, the actual spec of the .FOT file > format has eluded me, though knowing that it's a NE binary has > enabled me to reverse a lot of it, which I'm yet to test but I > believe will be enough to fool AddFontResource into doing what > it's supposed to do. Again, is it enough to go that far for now > as the FOT format seems to be unsupported in WINE? Yes, that's probably enough for now. --Juan ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news

1 0

Re: wined3d: Set wrapmode for cubemags to clamp regardeless of the sampler state
by Stefan Dösinger March 12, 2007

March 12, 2007

Am Samstag 10 März 2007 15:02 schrieb Fabian Bieler: > This Patch forces GL_CLAMP_TO_EDGE on all cubemaps. > > I tested this on XP with some Radeon X1???. > > Also, this fixes some renderissues Half-Life 2. Say, does that fix the strange quad boarders like in this screenshot? http://bugs.winehq.org/attachment.cgi?id=5297&action=view (Eve Online). It sounds like it would do that, I'm very impressed :-) How did you test that? It sounds like a test case using the visual test framework is worth an investigation. I can try to write a test for that.

3 4

WineHQ maintenance
by Jeremy Newman March 12, 2007

March 12, 2007

I will be performing some maintenance to WineHQ today at 14:30 CST. The recent outages on WineHQ were attributed to a faulty drive in the RAID. I will be taking the server offline to replace that drive. The server should only be offline for about 20 minutes. -newman

1 0

LockRect Problem
by Erich Hoover March 12, 2007

March 12, 2007

I'm looking into a problem that causes Supreme Commander to segfault (Bug #7643 <http://bugs.winehq.org/show_bug.cgi?id=7643>) and I believe I may have run into a problem with IWineD3DSurfaceImpl_LockRect. I believe the problem is a typo in the line: > This->resource.allocatedMemory = HeapAlloc(GetProcessHeap() ,0 , This-> > resource.size + 4); I think that the allocated memory should be the size of the resource multiplied by 4 (instead of adding 4). With the current allocation, for some textures, the operation to calculate the pBits location returns a memory address that is past the end of the allocated memory. So, after this operation: > pLockedRect->pBits = This->resource.allocatedMemory + (pLockedRect->Pitch > * pRect->top) + (pRect->left * This->bytesPerPixel) > the value of pLockedRect->pBits is greater than "This-> resource.allocatedMemory + This->resource.size + 4". I've dug around a bit to see if This->resource.size was just allocated incorrectly but that does not appear the case. So, if someone could confirm or deny that this is a typo problem then I'd really appreciate it. Erich Hoover ehoover(a)mines.edu

3 4

fog with pixel shaders < 3.0
by Fabian Bieler March 12, 2007

March 12, 2007

Hello! I'd like to get fog working in conjunction with pixel shaders 2.0 or earlier. The problem is that said shaders don't replace the fog stage in Direct3D. Adding the necessary fog calculations to a GLSL fragment shader is trivial, however, this results in a dependency of the shader on the current fog state. Now, I have thought up three solutions for this problem: 1) Compile two versions of every fragment shader (one with fog and one without) and choose the appropriate one according to the state. Pro: Probably performance wise the cheapest solution Con: Generates more shaders, however, as shader are only compiled on demand, this shouldn't be too bad. 2) Rebuild the shader whenever it is bound in conjunction with a changed fog state. Pro: ? Con: This would be a performance killer as it would potentially cause multiple calls of IWineD3DPixelShaderImpl_CompileShader per frame, as some Programs use the same fragment shader for rendering with and without fog. (ok, I only know this of source based games, but imo that's bad enough) 3) Add Fog calculation to every shader, enabling or disabling it at runtime via a constant factor of 1.0 or 0.0 depending on the fog state which is supplied as a shader constant. Pro: cpu-load wise cheap Con: Adds some more instructions to fragment shader code. Now, I don't particularly like any of these solutions, so I'd welcome other ideas, comments or suggestions. Fabian P.S: I noticed that fog-state management is not yet included in the state table. Should a patch that fixes fog with pixel shaders wait until this is done, or is this of no importance?

3 8

Re: [2/2] imm32: Fix the unwanted root_context string buffer cleanup code.
by Byeong-Sik Jeon March 12, 2007

March 12, 2007

I'm sorry. This patch don't fix kinput2 case. kinput2 case may be wanted situation. but this patch fix the 'nabi' and 'scim' case. Hmm, I'll stop the my poor patch series. Thank you. Byeong-Sik Jeon worte: > kinput2: Japanese xim. when we press japanese/english toggle key > at the composition state before commit, we lost composition > string. > nabi : Korean xim. same 'kinput2' case. > scim : General IM platform. when we input Japanese string, if > we press the "commit key(ENTER)", then we lost the all > composition string. > > This patch fix all above. > --- > dlls/imm32/imm.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-)

1 0

mswsock.dll, Soc & legal questions
by Benoit Pradelle March 12, 2007

March 12, 2007

Hi, I'm pretty interested in implementing mswsock.dll as a SoC this summer : this dll seems to be used by many apps and it's, I think, the sort of job I can do. As I'm not a Wine dev, I was wondering about how should I work for implementing this lib : should I juste use the MSDN description of the functions and make some tests with some apps to validate the behavior ? Or can I take the original dll, execute some apps with it and try to see how the dll is interacting with other libs, what sort of network traffic is generated, etc ? Is this solution possible with the microsoft license ? Thanks, Ben

2 2

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.
by Aric Stewart March 12, 2007

March 12, 2007

I am pretty sure that these are done via SendMessage when I checked with Spy++. Additional a number of the applications I am working with hang when the WM_IME_NOTIFY is sent out of order. -aric Byeong-Sik Jeon wrote: > We have to call PostMessage to send WM_IME_NOTIFY message. > To send WM_IME_CONTROL, we use SendMessage, but WM_IME_NOTIFY is not... > > changelog: > Use the PostMessageW for WM_IME_NOTIFY message. > --- > dlls/imm32/imm.c | 25 ++++++++----------------- > 1 files changed, 8 insertions(+), 17 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 02a362e..034d4ea 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -77,8 +77,8 @@ static UINT WM_MSIME_DOCUMENTFEED; > */ > static LRESULT WINAPI IME_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, > LPARAM lParam); > +static LRESULT ImmInternalPostIMEMessage(UINT, WPARAM, LPARAM); > static void UpdateDataInDefaultIMEWindow(HWND hwnd); > -static void ImmInternalPostIMEMessage(UINT, WPARAM, LPARAM); > static void ImmInternalSetOpenStatus(BOOL fOpen); > > static VOID IMM_PostResult(InputContextData *data) > @@ -160,16 +160,7 @@ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpReserved) > } > > /* for posting messages as the IME */ > -static void ImmInternalPostIMEMessage(UINT msg, WPARAM wParam, LPARAM lParam) > -{ > - HWND target = GetFocus(); > - if (!target) > - PostMessageW(root_context->hwnd,msg,wParam,lParam); > - else > - PostMessageW(target, msg, wParam, lParam); > -} > - > -static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > +static LRESULT ImmInternalPostIMEMessage(UINT msg, WPARAM wParam, LPARAM lParam) > { > HWND target; > > @@ -177,7 +168,7 @@ static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > if (!target) target = GetFocus(); > > if (target) > - return SendMessageW(target, WM_IME_NOTIFY, notify, lParam); > + return PostMessageW(target, msg, wParam, lParam); > > return 0; > } > @@ -214,7 +205,7 @@ static void ImmInternalSetOpenStatus(BOOL fOpen) > else > ShowWindow(hwndDefault, SW_SHOWNOACTIVATE); > > - ImmInternalSendIMENotify(IMN_SETOPENSTATUS, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETOPENSTATUS, 0); > } > > > @@ -1243,7 +1234,7 @@ BOOL WINAPI ImmSetCompositionFontA(HIMC hIMC, LPLOGFONTA lplf) > MultiByteToWideChar(CP_ACP, 0, lplf->lfFaceName, -1, data->font.lfFaceName, > LF_FACESIZE); > > - ImmInternalSendIMENotify(IMN_SETCOMPOSITIONFONT, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETCOMPOSITIONFONT, 0); > > if (data->textfont) > { > @@ -1267,7 +1258,7 @@ BOOL WINAPI ImmSetCompositionFontW(HIMC hIMC, LPLOGFONTW lplf) > return FALSE; > > memcpy(&data->font,lplf,sizeof(LOGFONTW)); > - ImmInternalSendIMENotify(IMN_SETCOMPOSITIONFONT, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETCOMPOSITIONFONT, 0); > > if (data->textfont) > { > @@ -1418,7 +1409,7 @@ BOOL WINAPI ImmSetCompositionWindow( > if (reshow) > ShowWindow(hwndDefault,SW_SHOWNOACTIVATE); > > - ImmInternalSendIMENotify(IMN_SETCOMPOSITIONWINDOW, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETCOMPOSITIONWINDOW, 0); > return TRUE; > } > > @@ -1447,7 +1438,7 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) > if (hIMC == (HIMC)FROM_IME) > { > ImmInternalSetOpenStatus(fOpen); > - ImmInternalSendIMENotify(IMN_SETOPENSTATUS, 0); > + ImmInternalPostIMEMessage(WM_IME_NOTIFY, IMN_SETOPENSTATUS, 0); > return TRUE; > } >

2 3

Re: imm32: Use the PostMessageW for WM_IME_NOTIFY message.
by Dmitry Timoshkov March 12, 2007

March 12, 2007

"Byeong-Sik Jeon" <wjsqudtlr(a)gmail.com> wrote: > We have to call PostMessage to send WM_IME_NOTIFY message. > To send WM_IME_CONTROL, we use SendMessage, but WM_IME_NOTIFY is not... > > changelog: > Use the PostMessageW for WM_IME_NOTIFY message. Aric just changed the code to use SendMessage for WM_IME_NOTIFY message. Sounds like it's time to write some message tests or look at the existing ones (which confirm that WM_IME_SETCONTEXT and WM_IME_NOTIFY are sent, not posted). -- Dmitry.

2 3

Re: Add implementation of D3DRMVector* functions
by Dmitry Timoshkov March 12, 2007

March 12, 2007

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > This is a patch by David Adams, implementing D3DRMVector* functions in d3drm.dll > I am sending the patch to this mailing list as this was posted on > bugzilla and awaiting review. 1. it's not really nice to send something with name attachment.cgi as a patch. 2. the patch has inconsistent formatting and very hard to read due to that 3. the patch is extremely buggy in memory allocations: instead of allocating the space for an object it allocates the space only for a pointer. I'd suggest to allocate all the objects on the stack instead. -- Dmitry.

3 2

Re: Add implementation of D3DRMVector* functions
by H. Verbeet March 12, 2007

March 12, 2007

On 12/03/07, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > This is a patch by David Adams, implementing D3DRMVector* functions in d3drm.dll > I am sending the patch to this mailing list as this was posted on > bugzilla and awaiting review. > A few comments: >- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA >+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 0;2110;-130;1, USA I don't think that change should be there. >+ LPD3DVECTOR result=(LPD3DVECTOR)(malloc(sizeof(LPD3DVECTOR))); That and other places in that patch should be using HeapAlloc/HeapFree >+LPD3DVECTOR D3DRMAPI D3DRMVectorRandom(LPD3DVECTOR d) >+{ >+ >+ srand(time(NULL)); >+ d->x=(float)(rand()); >+ d->y=(float)(rand()); >+ d->z=(float)(rand()); >+ TRACE("Random vector=(%f,%f,%f)\n",d->x,d->y,d->z); >+ return d; >+} I'm not sure about this, but I'm thinking it might be better to generate a normalized vector there. - The indentation in D3DRMVectorRotate is a bit of a mess - Writing test cases doesn't hurt, and in this case should be pretty easy

2 1

Re: [try 3] wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
by Stefan Dösinger March 12, 2007

March 12, 2007

Am Montag 12 März 2007 11:54 schrieb Fabian Bieler: > On Monday 12 March 2007 10:39, Stefan Dösinger wrote: > > You seem to add a 2nd table for GL_NV_texture_shader3 formats and try > > this table first. It is another solution for the static table problem I > > haven't thought of yet. For now, can you just hardcode the formats in the > > normal table? It should not cause any issues otherwise, because the > > function looking for a surface conversion will filter them out anyway. > > This patch includes the requested changes. I did not implement the > conversions for the new pixel formats, as that would not help anything > without also alterting the fragment shaders. Almost perfect :-) + {WINED3DFMT_X8L8V8U8 ,0x0 ,0x0 ,0x0 ,0x0 ,4 ,FALSE ,GL_DSDT8_MAG8_INTENSITY8_NV,GL_DSDT_MAG_INTENSITY_NV,GL_BYTE}, Can you align the } with the other lines? (I'm picky because it is very tricky to fix the formating afterwards)

1 0

Re: wined3d: Implented signed texture formats via NV_TEXTURE_SHADER
by Stefan Dösinger March 12, 2007

March 12, 2007

Am Montag 12 März 2007 00:30 schrieb Fabian Bieler: > The same patch as before, but with GL_DSDT_NV instead of GL_HILO8_NV as > suggested by Frank Richter. You seem to add a 2nd table for GL_NV_texture_shader3 formats and try this table first. It is another solution for the static table problem I haven't thought of yet. For now, can you just hardcode the formats in the normal table? It should not cause any issues otherwise, because the function looking for a surface conversion will filter them out anyway. It is mostly my own fault; When I created that pixel format table almost a year ago, we only had static formats which were supported by the gl core, or by a max of one extension. Nowadays the table hits the limit with bump map formats, and sRGB textures. I think it is time to think about changing the design. A few ideas by me: * Stop making the table static and keep one table per adapter. Then we can insert the proper formats depending on the supported extensions at initialization time +: One table to search for a format -: No solution for sRGB * Duplicate the tables, create extra tables for sRGB formats and per-extension tables +: Tables stay static -: Multiple tables look nasty. Can get out of control * Put one format into the table, select other per-extension formats in d3dfmt_get_conv. +: One table +: Simmilar to the color keying and palette handling -: No solution for sRGB -: Complicated, final format hard to read from pixel format table * Add extra columns to the table to allow multiple table entries per format: like a flag sRGB, and a supported extension. +: One table, stays static +: Deals with sRGB formats -: Searching for a format gets more complex, will be more expensive than with the many tables approach. * Replace the table with a function with a huge switch statement. +: Can deal with all sorts of parameters dynamically +: Not really more expensive than a lookup table with a linear search +: If done right should be easy to read -: We have had that before, it didn't look nice(ok, it used 3 different functions)

1 0

Re: wined3d: Allow SetCursorProperties on existing cursor
by Erich Hoover March 12, 2007

March 12, 2007

> > Am Samstag 10 März 2007 06:10 schrieb Erich Hoover: > >* Real Name: > *>* Erich Hoover > *>* Description: > *>* The SetCursorProperties call needs to be capable of being performed on > *>* existing cursors. The current behavior removes the cursor handle at the > *>* beginning of any SetCursorProperties call (and on Uninit3D). The removal > *>* of the cursor on SetCursorProperties is counter to the documentation and > *>* causes some applications to lose the cursor when SetCursorProperties is > *>* re-issued (See Bug #7619 <http://bugs.winehq.org/show_bug.cgi?id=7619>). > *>* This patch corrects this issue and permits SetCursorProperties to retrieve > *>* the gl texture of an old cursor. > *>* Changelog: > *>* wined3d: Allow SetCursorProperties on existing cursor > *This is not completely correct: > > The application can Release the d3d surface after setting the cursor. This > would also delete the gl texture used to draw the cursor. Also, the apps can > potentially change the surface and call PreLoad. This would change the cursor > without SetCursorProperties(The cursor texture does not have to be in > D3DPOOL_SCRATCH, so the app can preload it manually). > > But you are right, a non-dirty surface causes issues with the current code. I > think you can fix that by modifying LoadTexture not to release the surface > memory is SFLAG_FORCELOAD is passed. (Or better, fix the SFLAG_DONOTFREE > macro in wined3d_private.h). Then, when SetCursorProperties sets the surface > texture to 0 remove SFLAG_INTEXTURE from the surface flags. > > The API documentation doesn't say anything about an application releasing the d3d surface, but the documentation in the code seems to indicate that the gl texture needs to remain when the surface is deleted - I did nothing to change this. What I did see as requiring a change is the call to "glDeleteTextures(1, &This->cursorTexture);" at the beginning of SetCursorProperties. Maybe I'm not understanding you correctly, but in my mind it is necessary to remove this call so that applications that re-use the same cursor can do so. This change (in combination with the change for non-dirty surfaces) was also experimentally verified to fix the problem I was experiencing (See Bug #7619<http://bugs.winehq.org/show_bug.cgi?id=7619>). I will look into changing/implementing the flags to eliminate the "non-dirty surface" problem. Erich Hoover ehoover(a)mines.edu

4 12

Re: quartz: Check allocation failure and clear memory in DSound Renderer
by Detlef Riekenberg March 12, 2007

March 12, 2007

On Fr, 2007-03-09 at 03:02 -0800, Chris Robinson wrote: > + ZeroMemory(pDSoundRender, sizeof(DSoundRenderImpl)); Since you clear the whole struct, ... > pDSoundRender->lpVtbl = &DSoundRender_Vtbl; > pDSoundRender->IBasicAudio_vtbl = &IBasicAudio_Vtbl; > @@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter, > LPVOID * ppv) > pDSoundRender->pClock = NULL; > pDSoundRender->init = FALSE; > pDSoundRender->started = FALSE; ... there is no need to clear it again. -- By by ... Detlef

5 8