d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal
Anyways, where should we put the d3dx9 code? I mean, we have 13 folders to choose from.. Perhaps It'd be better if we create a new dll (or at least directory) called d3dx9 were we implement all d3dx9 stuff and let the other d3dx9_xx dlls just call these functions? This would improve the clarity of the code structure, so that people that don't follow this discussion can also understand what we're doing ;-)
Re: [4/8] WineD3D: Do not try to disable unsupported texture units
On 27/11/2007, Stefan Dösinger [EMAIL PROTECTED] wrote: textures. In this case we build a texture map to read a texture from a lower texture unit from a higher register combiner. This texture unit always stays below GL_LIMITS(textures) though. Yes, but you're checking against the sampler, not the texture unit. Shouldn't you be checking against mapped_stage instead?
Re: [1/8] WineD3D: Inform the texture about filtering changes
On 27/11/2007, Stefan Dösinger [EMAIL PROTECTED] wrote: Don't you need to mark the sampler dirty if it's bound somewhere? Or is it guaranteed it never is at that point?
Re: d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal
Am Mittwoch, 28. November 2007 09:17:04 schrieb [EMAIL PROTECTED]: Anyways, where should we put the d3dx9 code? I mean, we have 13 folders to choose from.. Perhaps It'd be better if we create a new dll (or at least directory) called d3dx9 were we implement all d3dx9 stuff and let the other d3dx9_xx dlls just call these functions? This would improve the clarity of the code structure, so that people that don't follow this discussion can also understand what we're doing ;-) Yes, I think this is a good idea. It wouldn't be a wined3dx which is shared among d3dx8 and d3dx9, but it would just be a central place for the common code in d3dx9_xx.dll, which will be a big majority of the code I guess. signature.asc Description: This is a digitally signed message part.
Re: [try2 1/1] msi/tests: automation: Fix pointer check before calling lstrcpyW.
Misha Koshelev [EMAIL PROTECTED] writes: The previous patch was last week I think. This fixes a Valgrind error in the test. This is correct as vtResult is just hte _expected_ return type, and this way we check the actual return type (new this version) and then the validity of the pointer (same as old patch) before calling lstrcpyW so we don't pass NULL to lstrcpyW. It seems to me what you really want to do is check that the call succeeded, instead of relying on the variant being cleared on error. -- Alexandre Julliard [EMAIL PROTECTED]
d3dx9__xx dlls
Following Alexandre (and I agree with him :D ), one only needs to export the functions of d3dx9_36 (the latest one) to the older d3dx9_xx dlls. So, we just just need to implement the functions in the d3dx9_36 dll repertory. No wine_d3dx9 is useful. David
Re: d3dx9__xx dlls
Am Mittwoch, 28. November 2007 18:14:21 schrieb [EMAIL PROTECTED]: Following Alexandre (and I agree with him :D ), one only needs to export the functions of d3dx9_36 (the latest one) to the older d3dx9_xx dlls. So, we just just need to implement the functions in the d3dx9_36 dll repertory. No wine_d3dx9 is useful. What do we do if there's a d3dx9_37.dll next month? signature.asc Description: This is a digitally signed message part.
Re: d3dx9__xx dlls
Hello Stefan, Stefan Dösinger schreef: What do we do if there's a d3dx9_37.dll next month? One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a forward dll for the old one. Cheers, Maarten
Re: d3dx9__xx dlls
Maarten Lankhorst wrote: Stefan Dösinger schreef: What do we do if there's a d3dx9_37.dll next month? One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a forward dll for the old one. Renames are cheap in git and we do not loose the history. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: d3dx9__xx dlls
On Nov 28, 2007 12:34 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: Maarten Lankhorst wrote: Stefan Dösinger schreef: What do we do if there's a d3dx9_37.dll next month? One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a forward dll for the old one. Renames are cheap in git and we do not loose the history. I also think that rename is not a good idea. I would like propose a new idea, why dont we have different spec files inside wine_d3dx for all different versions of dlls. Its something like we have done it in the ole32. But, it requires some makefile/configure cruft. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: xdg_user_dirs patches
On Nov 26, 2007 4:49 PM, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: Hi Lei, I think a new file for user dir look up in the shell32 is of no use. Rather than we can add it to the xdg.c and xdg.h, as it contains the generic xdg code for shell32. Its like having all xdg specific code at one place. This is my personal opinion about those patches. Thanks, VJ I was not sure if was alright to mix code with different licenses in the same file. I looked around and found that include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT licensed code from the Mesa project. Based on that, I guess it's ok to do, so I will send out another patch. - Lei
Re: d3dx9__xx dlls
Vijay Kiran Kamuju wrote: On Nov 28, 2007 12:34 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: Maarten Lankhorst wrote: Stefan Dösinger schreef: What do we do if there's a d3dx9_37.dll next month? One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a forward dll for the old one. Renames are cheap in git and we do not loose the history. I also think that rename is not a good idea. Heh. I didn't say that i don't like renames. I said renames are a workable solution: read there's no technical reason why to not use them. I would like propose a new idea, why dont we have different spec files inside wine_d3dx for all different versions of dlls. Its something like we have done it in the ole32. But, it requires some makefile/configure cruft. There's no need to name that wine_d3dx. Nothing stops us to name it d3d9x and have all the other versions generated inside that. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111
Re: [PATCH 1/3] advpack/tests: Rename the wrappers around HeapAlloc() Co to use the new standard naming.
On Nov 28, 2007 3:39 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: Alexandre, i'm unsure about this patch series. Yes this are simple wrappers around HeapAlloc() that are the same as the standard wrappers used in Wine. But they are used only as callbacks aka different usage. I don't think this particular series is beneficial. Your script won't be able to use these names because they're not called directly. -- James Hawkins
Re: [PATCH 1/3] advpack/tests: Rename the wrappers around HeapAlloc() Co to use the new standard naming.
James Hawkins wrote: On Nov 28, 2007 3:39 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: i'm unsure about this patch series. Yes this are simple wrappers around HeapAlloc() that are the same as the standard wrappers used in Wine. But they are used only as callbacks aka different usage. I don't think this particular series is beneficial. Your script won't be able to use these names because they're not called directly. I know. But i had written the patches already but before wiping them from my tree i thought to send them in for documentation purpose. Btw. the unfree-wine.pl has mem_alloc() in there because of the malloc() wrapper in the server that happens to have the same name. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: xdg_user_dirs patches
Lei Zhang [EMAIL PROTECTED] writes: I was not sure if was alright to mix code with different licenses in the same file. I looked around and found that include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT licensed code from the Mesa project. Based on that, I guess it's ok to do, so I will send out another patch. It's OK to do, but I don't think you want to copy the code as is, you should write your own version that parses the file only once and handles variables as they are found. Also these variables should take priority over the default heuristics, and you most likely want to handle the desktop dir the same way. -- Alexandre Julliard [EMAIL PROTECTED]
re: shell32: symlink user's profile shell folders to xdg well known directories [2/2] (try 3)
I feel like a broken record, but: some apps don't like following symlinks, and the native Windows way to configure what the My Foo folders point to is called shell folder redirection; These are documented at http://support.microsoft.com/kb/242557 among other places, and I think Wine supports these registry settings. Is there any reason we don't want to use these instead of symlinks? - Dan
