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

re: GSoC WPKG and test.winehq.org
by Dan Kegel 05 Apr '10

05 Apr '10

> Converting the wpkg scripts to appinstall doesn't > seem like that difficult of a task, mostly just time consuming. It's harder than it sounds to actually get a few useful app tests written. Plus there'll be some work writing up and fixing the bugs it uncovers. > That is why I thinking working on tying it into test.winehq.org is more worthy. > I still think tying appinstall and patchwatcher together would be > beneficial and allow people submitting patches to see where > regressions pop up in software, and to see > what new software works with each submitted patch. > Perhaps a project of implementing all of this and adding wpkg scripts would be accepted? Arjun Comar is going to propose something similar, but using Buildbot as the point of integration. - Dan

4 7

Re: winedump: code cleanup
by Alexandre Julliard 02 Apr '10

02 Apr '10

"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

2 3

winmm: For MCI parsing, use 64bit compatible structures.
by Joerg-Cyril.Hoehle＠t-systems.com 01 Apr '10

01 Apr '10

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

2 1

WineD3D BltOverride overhaul
by Roderick Colenbrander 01 Apr '10

01 Apr '10

Hi, For a while we have been discussing on how to clean up / rewrite some parts of the surface code in WineD3D. I did submit a number of patches to initiate a rewrite of some parts but not all patches were correct and it wasn't clear what final design I had in mind. I'm posting my ideas to here to get some feedback on how to proceed. For people outside wined3d this might not be that interesting but I'll give a short overview of the problems, so that you could also understand it a little bit. The main issue is that pieces of modern code and legacy DirectDraw code are entangled in a way which is not easy to untangle. There are various places which can be improved but for now I want to limit myself to 'BltOverride'. It is a big function shared between DirectDraw/D3D7 blitting and D3D8 CopyRects / D3D9 StretchRect and over the years it has become large and very ugly. The way I thought about simplifying this call is to move some parts to helper functions and to remove legacy functionality (e.g. move colorfill back to Blt). A lot of the work which has to be done is not just about moving code around. Some functionality can these days be implemented in a nicer way thanks to functionality like shaders. Below I have some pseudo code on how I think a chunk of BltOverride and the blit_shader calls it uses, should be implemented. The main idea is to move the majority of the code to the blit_shader. Unless color keying / 8-bit is required, I expect that no actual shader is needed. In case we need a shader, there are two cases namely when blit_shader is implemented using GPU shaders and the case we need a fall back. In case of the fall back, I think we need big chunks of the 'old' BltOverride code which needs to be moved over to ffp_blit. BltOverride (color keyed) offscreen surface -> render target blitting { if(orm_fbo && can_stretch) stretch_rect_fbo <-- this check is around now; but I guess we ultimately want a IWineD3DDevice_StretchRect which contains this code and which can fall back to BltOverride) context = context_acquire(CTXUSAGE_BLIT) blit_shader->set_shader(src_surface) blit_shader->draw_quad(src_surface, src_rect, dst_rect) blit_shader->unset_shader(); } arb_blit_shader based implementation { blit_shader->set_shader(src_surface) { generate_shader (if needed) activate_shader if(color_keying_active) upload_colorkey_to_shader if(p8_active) load_p8_palette } blit_shader->draw(src_surface, src_rect, dst_rect) { surface_internal_preload(src_surface) { under the hood, LoadTexture/LoadLocation should not perform surface conversion for us basically the issue is how to distinguish between 2d and 3d color keying and how to separete this } /* drawing */ if(fbo_blit) fbo_blit() else draw_quad() } blit_shader->unset_shader(); } ffp_blit implementation { blit_shader->set_shader(src_surface) { if(p8_active) load_palette else not_much_todo } blit_shader->draw(src_surface, src_rect, dst_rect) { if(need_color_keying) play_with_color_keying_flags (like current BltOverride does) surface_internal_preload(src_surface); if(need_color_keying) restore_color_keying flags activate_alpha_test_magic draw_quad() } blit_shader->unset_shader(); } I think the design described above could work (perhaps I missed something, please correct me then). One of the issues is color keying. Right now color key conversion is performed in LoadLocation based on some flag magic. In case of a 2d blit using shaders this is not needed but for Direct3D purposes it is needed. I'm not sure how to handle this in a clear way. (I fear that we also get some new issues when a game alternates between 2d and 3d color keying). I don't expect issues regarding 8-bit as long as we implement them in software and use opengl only during the upload (UnlockRect). If we would allow hardware blitting, it would need to be 8-bit -> 8-bit blits and no converted blits else we need hacks like paletteOverride which I would like to eliminate. Roderick

3 10

GSoC - keyboard input
by wylda＠volny.cz 01 Apr '10

01 Apr '10

Hi guys, if it is not too late, i would have a proposal for GSoC. I'm waiting quite long for "BuildActionMap, SetActionMap, EnumDevicesBySemantics & co", i.e. to make games like need for speed happy/playable (bug 8754). Thanks for reading, W.

3 3

re: Implementation of WIndows Gaming APIs as GSoC project
by Mariusz Pluciński 31 Mar '10

31 Mar '10

2010/3/30 Dan Kegel <dank(a)kegel.com> Sounds good to me -- and you could start right now by checking in stubs, > if we don't have them already... > > The question is, though, how useful are these APIs (aside from > needing them to play some games)? Which games make use of them? > According to research made by Vincent Povirk (described at bugzilla: http://bugs.winehq.org/show_bug.cgi?id=21261) some games already use it. In my opinion, importance of this interface will be growing in the future. And MS will probably extend it to add new features. So, it would be easier to create these interfaces now, before moment they will become really big and complicated, like others Microsoft's APIs. Microsoft also solved problem with older games - they created some kind of games database which allows some older games to be visible in Games Explorer without using new APIs. Of couse, Wine project should not use Microsoft's database, but there's already Wine's Application Database, which after some extension may be used in similar way.

3 4

re: A proposal for implementing dxdiag.exe: thoughts?
by Dan Kegel 31 Mar '10

31 Mar '10

John wrote: >OK -- it would definitely not make sense to redo the work if the tests >are completed to satisfaction. >In that case, I would recommend renaming/clarifying the suggested GSOC >project on the Wine wiki. >It seems to suggest that conformance tests need to be written. Well, yes, but for the library that dxdiag.exe uses, dxdiagn.dll. I'm not clear on how complete the tests for our dxdiagn.dll are; if they're already complete enough, you could skip this step. See http://msdn.microsoft.com/en-us/library/ee416987(v=VS.85).aspx for the public interface to this library. - Dan

1 0

A proposal for implementing dxdiag.exe: thoughts?
by John Koelndorfer 31 Mar '10

31 Mar '10

I've written a proposal for what my plan would be regarding implementation of Wine's dxdiag based on my own thoughts and the suggestions of other wine-devel list members. I plan to submit proposals for other projects as well but before I write them I'd like to get a better feel for what's expected (I did look at PGSQL's tips as per the GSOC wiki page). Anyways, it's attached. Please let me know what you think.

3 5

re: [1/2] wcmd/setshow_attrib: Moved from internal to external attrib.exe
by Dan Kegel 31 Mar '10

31 Mar '10

Welcome to wine development! Problems with your patch: - you forgot to add your test to rsrc.rc - you forgot to include an expected output file - don't change .h files in patches that don't need the changes Please submit just the tests first, make sure 'make test' runs your tests, and make sure the .exe produced by 'make crosstest' passes on winetestbot. You might want to send the next patch to me for review before posting to wine-patches; you'll probably run into several more gotchas that it'd be nice to have cleared up before you post again. - Dan

1 0

re: Summer of Code applicant with ambition!
by Dan Kegel 31 Mar '10

31 Mar '10

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

7 10