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

d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal
by tony.wasserka＠freenet.de Nov. 30, 2007

Nov. 30, 2007

Okay, then that has been discussed. By the way, what about David's second patch? Was there anything wrong about it or why isn't it in the tree, yet?

1 0

d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal
by tony.wasserka＠freenet.de Nov. 30, 2007

Nov. 30, 2007

> So, just to clarify, you propose to create a d3dx9.dll dll, putting its > code in dlls/d3dx9. Does this dll exist on Windows? If not, then we > should call it wined3dx9 (and its code would go in dlls/wined3dx9). Well, it shouldn't even be a dll, just a folder were put in all the d3dx9 code and let the d3dx9_xx.dlls just export the functions they need. I don't know of how much the makefile system is capable, but maybe we can put all the d3dx9_xx.spec files in the same directory to improve overviewability, I don't like these 13 dlls/d3dx9 directories that much :D Anyways, what are the concrete differences between the d3dx9_xx.dlls?

2 1

Re: [Patch] for wined3d: Correcting order issue
by Roderick Colenbrander Nov. 30, 2007

Nov. 30, 2007

> Hi all, > > This patch repairs my previous one, as the command never got executed, > because 8600 matches before 8600M. > > > Marco Schuster > > ---- > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index e4b5bdf..50b3250 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -950,6 +950,11 @@ BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info > *gl_info) { > gl_info->gl_card = CARD_NVIDIA_GEFORCE_8800GTS; > vidmem = 320; /* The 8800GTS uses 320MB, a 8800GTX > can have 768MB */ > } > + /* Geforce8 - midend mobile */ > + else if(strstr(gl_info->gl_renderer, "8600 M")) { > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_8600MGT; > + vidmem = 512; > + } > /* Geforce8 - midend */ > else if(strstr(gl_info->gl_renderer, "8600") || > strstr(gl_info->gl_renderer, "8700")) > @@ -957,11 +962,6 @@ BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info > *gl_info) { > gl_info->gl_card = CARD_NVIDIA_GEFORCE_8600GT; > vidmem = 256; > } > - /* Geforce8 - midend mobile */ > - else if(strstr(gl_info->gl_renderer, "8600 M")) { > - gl_info->gl_card = CARD_NVIDIA_GEFORCE_8600MGT; > - vidmem = 512; > - } > /* Geforce8 - lowend */ > else if(strstr(gl_info->gl_renderer, "8300") || > strstr(gl_info->gl_renderer, "8400") || > I would prefer not to extend the list with lots of additional models. In my opinion it isn't really needed as the list would become a lot longer and this makes it harder to maintain. If we would continue this way we would easily have to add two dozen additional mobile cards which are now handled as their desktop equivalents. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

2 1

Re: [4/4] WineD3D: Enabling too many lights is silently ignored
by H. Verbeet Nov. 30, 2007

Nov. 30, 2007

On 30/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > But you're not creating the lights first with SetLight(). IIRC you can create lots of lights with SetLight(), but only enable MaxActiveLights at the same time with LightEnable(). I guess calling LightEnable on a light that isn't created first is simply ignored. I thought that at least for ddraw I created a test for this back when I started working on wine, but perhaps I never sent it in. :-/

2 1

Re: [1/4] WineD3D: mov to a0.x does a floor(), not a round to nearest
by Alexandre Julliard Nov. 30, 2007

Nov. 30, 2007

Stefan Dösinger <stefan(a)codeweavers.com> writes: > I sent this patch already, and it was committed and shows up in the 0.9.49 > changelog. The commit ID is 6209b36acbef6e7f8edcf3a45a006bb09bffe4af, but > somehow the functional change was reverted again in > 0183f3e305ae1e40a806682ec85e8b4507e4ddd8 and the test was reverted in > 4454096db27e7560cce99367b45be3b24dd0894a Most likely what happened is that I applied it, then reverted it because it caused test failures, but I didn't remove the commit properly. Anyway, it's still failing: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:5165: Test failed: The device was not properly freed: refcount 1 make[2]: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Some thoughts about next GSoC
by Kai Blin Nov. 30, 2007

Nov. 30, 2007

Hi folks, from what we discussed at the last WineConf, we wanted to work on our procedures for the Google Summer of Code a little. I'm sending this email in hope to start some discussion about this, so we have it out of the way until the 2008 version is announced so we can talk about proposed projects then. The goal of Wine's SoC procedures should be to get high-quality proposals that can be completed by the student proposing the project in the time allocated for GSoC, so both scope and difficulty should be checked. I haven't been on the mentoring side of things, but my understanding from the WineConf side of things was that we had some problems getting this right the past years. I was thinking about strongly encouraging people to post their project proposal to wine-devel prior to applying, so more developers can have a look at it and see if it's doable or not and offer suggestions. I know some projects did an introductory quiz to figure out the student's coding skills, I'm not convinced the knowledge needed for Wine can be tested in a quiz. What do you think? Another thing that didn't turn out too well last time is that it was really hard to figure out what was going on during the summer. I have a few ideas on how we could address this. Lots of other projects had their student write a weekly public progress report. I think we should require the same. This will probably help keeping people updated, and might help spotting problems early. According to the wiki page, we already require a post-mortem report on the project, however I can't remember seeing much of those this year. We should make sure those are written next time. We might think of a better name for the report, post-mortem sounds like the project is dead after the summer, we want people to keep working. Last year, some of the students set up a public git repo on repo.or.cz. I was thinking about making that a requirement for next year. This would allow people to review work in progress. Comments? Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

5 11

re: shell32: symlink user's profile shell folders to xdg well known directories [2/2] (try 3)
by Dan Kegel Nov. 30, 2007

Nov. 30, 2007

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

3 2

d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal
by tony.wasserka＠freenet.de Nov. 30, 2007

Nov. 30, 2007

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 ;-)

3 2

Re: urlmon: Rename the wrappers around HeapAlloc() &Co to use the new standard naming.
by Steven Edwards Nov. 30, 2007

Nov. 30, 2007

Hi, On Nov 29, 2007 4:12 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > diff --git a/dlls/urlmon/urlmon_main.h b/dlls/urlmon/urlmon_main.h > index aeb0eb2..9f31fb9 100644 > --- a/dlls/urlmon/urlmon_main.h > +++ b/dlls/urlmon/urlmon_main.h > @@ -63,22 +63,22 @@ HRESULT start_binding(LPCWSTR url, IBindCtx *pbc, REFIID riid, void **ppv); > > HRESULT create_binding_protocol(LPCWSTR url, IInternetProtocol **protocol); > > -static inline void *urlmon_alloc(size_t len) > +static inline void *heap_alloc(size_t len) > { > return HeapAlloc(GetProcessHeap(), 0, len); > } > > -static inline void *urlmon_alloc_zero(size_t len) > +static inline void *heap_alloc_zero(size_t len) > { > return HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len); > } > > -static inline void *urlmon_realloc(void *mem, size_t len) > +static inline void *heap_realloc(void *mem, size_t len) > { > return HeapReAlloc(GetProcessHeap(), 0, mem, len); > } > > -static inline BOOL urlmon_free(void *mem) > +static inline BOOL heap_free(void *mem) > { > return HeapFree(GetProcessHeap(), 0, mem); > } Rather than duplicating these inline functions in each dlls private header, could we add the heap wrappers somewhere like winbase.h and mark it as a wine extension? Doing it there would make sense as winbase.h is where HeapAlloc and friends is defined. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 1

wine for two, please.
by Athel Nov. 29, 2007

Nov. 29, 2007

Hi Rob, i was looking a long time the way to do this. Can you help me to done this?, plis I really need it. If I could understand better the functionality I'll do it for myself. Sorry for my english. Regaards Athel > I was going to wait til tomorrow to test this, but couldnt wait. > This works perfectly for my app and couldnt have came at a better time. > > I just created a simple Win32 dispatcher program for each screen and sent > the window creation messages to the HWNDs from FindWindow instead of the > local app and it creates the dialogs on any screen I want. Joy Joy!!!!! > > It worked out perfectly since the threads that create windows have to send > messages to the main loop for it to create them so that the dialogs dont > from close when the thread exits anyway. > > It is refreshing that after I went through all the battles of getting > multihead display, gcc, and wine running on Solaris that FINALLY something > would work so simply. > > Thanks again to the whole Wine crew that made this possible!!!

1 0