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

Re: [PATCH 6/7] Use surface_is_offscreen instead of directly looking at the swapchain.

by Henri Verbeet

On 30 March 2010 21:19, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > @@ -4062,7 +4062,7 @@ static HRESULT IWineD3DSurfaceImpl_BltOverride(IWineD3DSurfaceImpl *This, const > * Also beware that the front buffer's surface size is screen width x screen height, > * whereas the real gl drawable size is the size of the window. > */ > - if (dstSwapchain && (IWineD3DSurface *)This == dstSwapchain->frontBuffer) { > + if (!surface_is_offscreen((IWineD3DSurface *)This)) { > RECT windowsize; > POINT offset = {0,0}; > UINT h; This looks wrong, the code is checking if the surface is the front buffer, not if it's onscreen.

March 30, 2010

re: Summer of Code applicant with ambition!

by Dan Kegel

John Koelndorfer wrote: >I've again gone over the list of possible projects on >the Summer of Code page and one that particularly piqued my interest >was "Direct3D - Conformance / Performance / Interactive tests". This >seems like it may be a good fit given my lack of previous experience >in the Wine codebase. I haven't written any code for 3D-ish games but >I can't imagine that would be a huge setback. Maybe Dan Kegel or >someone else who has worked on D3D can comment here? (Correction: I've never worked on D3D :-) Offhand, if you're not already a 3d person, that might be kind of hard? Although maybe the "get dxdiag working" task might be easy enough. (The only problem with that is it involves committing someone else's code, which isn't a good focus for a GSOC project.) >If that is not feasible, I think I would be a strong candidate for the >"Test Suite" project since my scripting-fu is fairly strong. Sure, you could find and fix tons of problems that way, I bet. - Dan

March 30, 2010

Re: Summer of Code applicant with ambition!

by John Koelndorfer

<snip quoted text> Firstly, thanks to Roderick for the prompt reply. I had a feeling that my ideas were a little much. :-) That being said, I've again gone over the list of possible projects on the Summer of Code page and one that particularly piqued my interest was "Direct3D - Conformance / Performance / Interactive tests". This seems like it may be a good fit given my lack of previous experience in the Wine codebase. I haven't written any code for 3D-ish games but I can't imagine that would be a huge setback. Maybe Dan Kegel or someone else who has worked on D3D can comment here? If that is not feasible, I think I would be a strong candidate for the "Test Suite" project since my scripting-fu is fairly strong. I've been looking through open Wine bugs but I've yet to find something that fits with GSOC and my skill level. If there are any suggestions for specific bugs to look into maybe I could build a project around one. Thanks! John

March 30, 2010

[PATCH 1/5] winmm: Improve MCI's Sysinfo command.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Eric Pouech wrote: >did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ? It's good you asked. Upon closer inspection, MCI_Sysinfo appears to behave differently. I'd say it's even a bug in MS that setting SYSINFO_PARMS.wDeviceType = MCI_ALL_DEVICE_ID is not recognized! Only sendCommand(MCI_ALL_DEVICE_ID, MCI_SYSINFO ...) appears usable to obtain the functionality of "sysinfo all ..." :-( I'll supersede the patch ASAP. Grr, that's not going to simplify the parser. Regards, Jögr Höhle

March 30, 2010

Implementation of WIndows Gaming APIs as GSoC project

by Mariusz Pluciński

Hello I'm Mariusz Pluciński, student of Information Technology in Gdańsk University of Technology (Poland). I decided to apply to Google Summer of Code in your project, cause I've been fascinated in Wine for a long time (without Wine, migration to open source OS would not be possible for me). In my opinion, one of the biggest problem for Wine is problems with support games written for MS Windows, so making progress in this area is something which I want to work on. I know C programming language very well, just as programming in Microsoft Windows APIs and Microsoft's COM technology. I also have some experience in working on open source - in Kdenlive project (video editor). I do a polish translation there, but I have also sent several patches to source code. In the past I was also reading some parts of Wine source code, so I know somewhat about how Wine's works and how it's code looks. In Google Summer of Code, I'm interested in implementation of new gaming APIs created by Microsoft for Windows Vista and enlarged in Windows 7. Main part of this is implementation of four COM interfaces: IGameExplorer, IGameExplorer2, IGameStatistics and IGameStatisticsMgr. In the bugzilla there's stub implementation of IGameExplorer interface, which may be good start point for me in development. Main parts of task will probably be creation of database to store games' data and parser of GDF files (Game Definition File). In favorable circumstances, if the APIs implementation is done fast enough, I will start work on simple equivalent of Windows Game Explorer application. It would be nice for Wine's users to control their games from one application, similar way as they do it in MS Windows. Also, application will use Game Statistics interfaces, so it will be good practical test for these interfaces. I hope my idea will get your acceptance. Thanks

March 30, 2010

Congratulations!

by Juan Lang

Hi Matteo, just wanted to congratulate you on getting your DRDXAssembleShader patches accepted. I know it can take a fair amount of persistence to get something substantial committed, and it seems that many lack the patience. Well done! --Juan

March 30, 2010

Re: winedump: code cleanup

by Alexandre Julliard

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > - winedump/search.c::get_type - cleanup variable usage That's not much better. It would be cleaner to stop abusing the passed argument as a local variable. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2010

Re: 10/10 wined3d: use RECT instead of WINED3DRECT in stretch_rect_fbo [try2]

by Alexandre Julliard

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > Hi, > > While working on some other patches, I spotted a small error in the > call to surface_get_rect for the source rectangle. I was passing > 'This' (destination) instead of Src. It doesn't work: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok wine: Unhandled page fault on read access to 0x00000050 at address 0x68e87fc9 (thread 0024), starting debugger... Unhandled exception: page fault on read access to 0x00000050 in 32-bit code (0x68e87fc9). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68e87fc9 ESP:0032f110 EBP:0032f248 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000001 EBX:68ed8d20 ECX:00000280 EDX:00000000 ESI:00000000 EDI:000001e0 Stack dump: 0x0032f110: 00146350 68ed2dbc 0032f228 00110014 0x0032f120: beef0202 7d7fb5c0 7bc4907b 68ed8d20 0x0032f130: 00147240 00000072 0032f198 68df9e66 0x0032f140: 00147240 00000080 00000080 00000001 0x0032f150: 0012fc70 00000000 00000072 00000000 0x0032f160: 00147000 686cb060 00000000 00010000 Backtrace: =>0 0x68e87fc9 IWineD3DSurfaceImpl_BltOverride+0x1529(This=<is not available>, DestRect=<is not available>, SrcSurface=(nil), SrcRect=(nil), Flags=0x1000400, DDBltFx=0x32fa9c, Filter=WINED3DTEXF_POINT) [/home/julliard/wine/wine/dlls/wined3d/surface.c:284] in wined3d (0x0032f248) 1 0x68e8b1e7 IWineD3DSurfaceImpl_Blt+0xb7(iface=<register ESI not in topmost frame>, DestRect=(nil), SrcSurface=<register EDI not in topmost frame>, SrcRect=(nil), Flags=0x1000400, DDBltFx=0x32fa9c, Filter=WINED3DTEXF_POINT) [/home/julliard/wine/wine/dlls/wined3d/surface.c:4271] in wined3d (0x0032f2d8) 2 0x686ae1bb IDirectDrawSurfaceImpl_Blt+0x1ab(iface=0x12b888, DestRect=<register ESI not in topmost frame>, SrcSurface=(nil), SrcRect=(nil), Flags=<register EDI not in topmost frame>, DDBltFx=0x32fa9c) [/home/julliard/wine/wine/dlls/ddraw/surface.c:806] in ddraw (0x0032f348) 3 0x686b0717 IDirectDrawSurface3Impl_Blt+0x47(This=0x12b88c, prcDst=(nil), pSrcSurf=(nil), prcSrc=(nil), dwFlags=0x1000400, pFX=0x32fa9c) [/home/julliard/wine/wine/dlls/ddraw/surface_thunks.c:113] in ddraw (0x0032f378) 4 0x68663213 D3D1_TextureMapBlendTest+0x263() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:1302] in ddraw_test (0x0032fb88) 5 0x68669bb5 func_visual+0x1375() [/home/julliard/wine/wine/dlls/ddraw/tests/visual.c:2979] in ddraw_test (0x0032fd48) 6 0x6866a82e run_test+0x14e(name=<is not available>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:543] in ddraw_test (0x0032fd98) 7 0x6866aa02 main+0x132(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:592] in ddraw_test (0x0032fe58) 8 0x6866ab9c __wine_spec_exe_entry+0x7c(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in ddraw_test (0x0032fea8) 9 0x7b8584c4 start_process+0x54(peb=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/process.c:989] in kernel32 (0x0032fee8) 10 0x7bc71344 call_thread_func+0xc() in ntdll (0x0032fef8) 11 0x7bc71510 call_thread_entry_point+0x70(entry=0x7b858470, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2459] in ntdll (0x0032ffc8) 12 0x7bc4cfca in ntdll (+0x3cfca) (0x0032ffe8) 0x68e87fc9 IWineD3DSurfaceImpl_BltOverride+0x1529 [/home/julliard/wine/wine/dlls/wined3d/surface.c:284] in wined3d: movl 0x50(%edx),%eax 284 rect_out->right = This->currentDesc.Width; -- Alexandre Julliard julliard(a)winehq.org

March 30, 2010

Re: Summer of Code applicant with ambition!

by Roderick Colenbrander

On Tue, Mar 30, 2010 at 4:34 PM, John Koelndorfer <jkoelndorfer(a)gmail.com> wrote: > Hello wine-devel, > > My name is John and I'm a computer science major at the University of > Minnesota, Twin Cities campus. I've made quite a bit of use of Wine before > (and I have purchased Crossover) and I'm inspired to give something back to > the project. > > I have fairly ambitious goals for myself (maybe too much so) so I wanted to > let you guys know who I am and what I'd like to do, then hopefully gain some > insight into whether or not what I am considering is reasonable. My > experience is roughly as follows: > > * I am familiar with C. I'm not an expert developer by any stretch but I can > certainly get by. I have some knowledge of Git. > * I don't have any Windows development experience outside of some exposure > to .NET a long time ago. > * I have not submitted a patch to the Wine project. I hope to change this in > the near future. I've looked at a little bit of the source code. > * I have high standards for myself. Whether or not they are high enough to > meet Alexandre's expectations... perhaps time will tell. :-) > * I'm a really fast learner. Maybe this is my single most redeeming quality. > > All that being said, my goal for the summer would be to really dig into the > D3D stuff, optimizing what is already completed and adding to what is not. > I'm a gamer myself, so I have an arsenal of programs with which to test (and > a Windows installation to compare to). Do you think this goal is reasonable? > If not, I could start somewhere smaller and work my way up. I'm certainly > open to suggestions. > > Thanks! > > John > First of all welcome to Wine. For a gsoc project I would try to work on a somewhat isolated piece of code, so that your work won't break daily and it is also easier to see what you are doing (and writing a good project description might be easier for an isolated project as well). Regarding the Direct3D code, it is quite complex and I don't think it is well suited for a gsoc project (it has a really steep learning curve). A project like 'optimizing Direct3D' is a bit vague and this would also make it hard to see whether you met your goals or not. Last year I would have said that if this area interests you, work on the D3DX9 helper dlls. Right now we have most of the easy 'bits' (though not all parts have been merged) and mainly lack the difficult part namely the HLSL shader compiler, but it is not suited for a GSOC project. I would think about an area which you like to work on (or perhaps a specific app which you really want to improve). Take into account that GSOC is quite short and realize that getting code into Wine can also take time because you might need multiple iterations of a patch and you have to write a lot of unit tests. So try to pick something which is realistic to improve in such an amount of time. Good luck! Roderick

March 30, 2010

winmm: For MCI parsing, use 64bit compatible structures.

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Eric Pouech wrote: >this patch is ugly as hell... Please qualify. To me, - data[3] = (DWORD_PTR)dev; + parms.open.lpstrElementName = dev; looks more robust than before: - no magic offsets, - no casts that may silence warnings. The one #ifdef WIN64 is a pure performance optimization on Win32. The other one with the TRACE() is indeed ugly, but I don't feel it's safe to call debugstr_w() on misaligned data in Wine64. Even if it were, printing data[3] as string may be wrong, because it may be data[4] (+5) that holds a pointer, not (3+4). Therefore I decided to renounce to print string contents on 64bit, despite their value in the logs. > and it still believe we can do the MCI >parser without knowing about MCI structures internals What do you mean? Quite to the contrary, the parser depends on knowing the internals of some commands (like MCI_OPEN) as well as the convention about the return value as 2nd (+3rd) slot after the callback. The parser bridges the gap between the resource definition files winmm_res.rc that are now in git and are known to work well with 32bit and the mixed DWORD/DWORD_PTR MCI_..._PARMS definitions whose correctness has been (partially) validated by tests. What we don't know is whether Win64 introduced a different winmm_res.rc. I'd sure would be pleased if somebody could describe whether there have been changes to the resources to accommodate 64bit pointers in MS-Windows. Everybody, please visit bug #22146 if you can contribute such knowledge. (Part of) my patch is needed even if there were (thanks to lack of magic offsets). Regards, Jörg Höhle

March 30, 2010