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

Re: Implementation of WIndows Gaming APIs as GSoC project

by Vincent Povirk

2010/3/31 Mariusz Pluciński <vshader(a)gmail.com>: > 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? Odd, I can't see Dan Kegel's reply. AFAIK, the API's aren't needed currently to play any games, but many games use them if they are available. I would guess that once game developers become comfortable dropping support for Windows XP (which is inevitable, but you can argue about how soon it will be), they'll start writing games that require this API. I suspect that once the classes exist, games will expect them to actually work, and adding the stubs will break some games that currently work. That means that once the stubs are in, it's very important to add at least a basic implementation. It also means that adding the classes will be a disruptive process, and it will only get worse the longer we wait. (Note: I haven't tested this theory, and for all I know most games will gracefully fall back on the old methods when they see a non-functional IGameExplorer. I wouldn't count on it though.) The project would potentially also include the Game Explorer shell namespace extension, which will likely be needed for shortcuts to work correctly. The control panel extension (CLSID_ControlPanel) is probably a good example. The main task there would be to implement an IShellFolder object that uses the game explorer database.

March 31, 2010

re: [1/2] wcmd/setshow_attrib: Moved from internal to external attrib.exe

by Dan Kegel

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

March 31, 2010

Re: WineD3D BltOverride overhaul

by Roderick Colenbrander

On Wed, Mar 24, 2010 at 9:09 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 24 March 2010 20:03, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: >> I have experimented a bit with the design (intially only color fill >> since that's quite independent). Note this is just a proof of concept >> (some of the helper functions would become separate patches). This >> patch is the current code in the new form. In a later stage an FBO >> blit_shader can be added which can call the FBO based color fill but >> that's quite easy to extend later on. At this point no context setup >> is needed since the helpers already do that but after this is all >> over, they could be moved over to this framework to make it a bit >> nicer. >> > The general direction looks ok. As a first step you probably don't > even need to call the functions through struct blit_shader though. > I have worked on some more parts of the blit_shader code. Before I clean it up and submit it, I'm posting it here to see if the direction is ok. Below I summarize each patch and also mention when I think a patch is ready (if that's the case more thorough feedback is welcome). 0007 - Renames is_color_fixup_supported to blit_supported and adds some parameters. I think this patch is ready. 0008 - Adds a blit method to arbfp_blit and limits the arbfp shader to complex blits (yuv/p8); for now this disables hw accelerated 8-bit color keying but that can easily be readded once the transition is over by modifying the p8 shader. I think this patch is ready. (I'm not that happy with the name arbfp_blit_surface but I had to use something else because arbfp_blit won't work and arbfp_blit_blit is a bit silly I think) 0009 - This moves the remaining 'offscreen -> render target' code to ffp_blit. I have thought long about whether to move the color key flag voodoo over as well. You can reason that it is up to the blit_shader how and if it implements color keying. If you move the code over, you would need some of the DDBLTFX information in the blit_shader (either through a parameter or some surface variable). I'm not sure if we want to go that way. I think it is better to leave the voodoo in one place. Later on I want to use it for the p8 arbfp code as well. As mentioned in a next patch the moved code, should likely become a helper function, so that ffp_blit.blit can decide whether to call 'ffp_blit_offscreen_to_render_target' or the fb_copy* calls. 0010 - Adds an initial fbo_blit implementation which supports blitting. I think this patch is ready but I'm only not sure where we want to have the fbo_blit code. Right now stretch_rect_fbo is in device.c (and the same for fbo color fill but Henri said that we shouldn't use it). I would say that the code should be in surface.c unless it is fine to use stretch_rect_fbo (some types have to be unified to be able to get rid of casts) as a helper function. 0011 - This patch is work in progress and moves the fb_copy_* calls to ffp_blit. It adds initial selection logic to ffp_blit.blit to decide which helper function to call. The logic tries to use SFLAG_SWAPCHAIN and WINED3DUSAGE_RENDERTARGET which I think works to get rid of some of the swapchain/surface checks which are around in BltOverride. Note this patch patch won't compile, so I also haven't tested it ;) If this work is in the right direction, I plan to work on the blitter selection next. I would apply it to 'render_target -> texture' and 'offscreen -> render_target'. Thanks, Roderick

March 31, 2010

Re: [GSoC] IUri Implementations

by Jacek Caban

Hi Thomas, On 03/31/2010 04:15 AM, Thomas Mullaly wrote: > >> You could use dynamic array for that or a list with a Uri_PROPERTY >> value as a key for example and a data as an offset and length. >> Another way is to compute each property offset only when it's >> requested and store it. An obvious bad case for that is a long uri. >> So probably one pass property computation while building IUri >> instance is not bad. >> > I like the idea of making a lightweight data structure which stores > the offset and length for each component property. I'd imagine it > would look something like this: > > typedef struct { > DWORD offset; > DWORD length; > } UriComponent; > > Although it becomes a little more tricky on how to store the > UriComponents, but, I have a few ideas if anyone has any suggestions. > > I do like the idea of using an array inside the Uri struct to store > the UriComponents but not all of the values in the Uri_PROPERTY enum > actually mean anything (at least thats what I have gathered from > reading the MSDN docs), like the Uri_PROPERTY_STRING_START and the > Uri_PROPERTY_STRING_LAST are just there to say all the enum values > between >= START and <= LAST correspond the string components of the > URI. > > So I'm thinking the Uri struct should have a constant size array of > UriComponents of length Uri_PROPERTY_STRING_LAST (which would be 15.. > correct me if I'm wrong). > > So it would look something like... > > typedef struct { > /** The other stuff */ > > BSTR *uri; > UriComponents components[15]; > } Uri; > > and then for the GetPropertyBSTR(BSTR *component, Uri_PROPERTY prop) > function you could just have something like. > > if(prop >= Uri_PROPERTY_START && prop <= Uri_PROPERTY_LAST) { > UriComponent comp; > comp = uri->components[prop]; > > /** Parse the component out */ > } > > And that should get you the necessary offsets and lengths for the > component you need. > > I also like the idea suggested before using a one-pass solution to > find everything when the Uri is constructed. > > > Thank you for the quick responses and suggestions, I hope to have a > proposal ready in the next few days. In general, the idea looks right, that's how it probably should be implemented. This is an implementation detail through. The bigger and more important problem is URI parsing and canonicalization. That's where most of work needs to be done. In this case tests will be also very important. You don't know how it should work until you have a test. The first step would be to write a test infrastructure some tests (adding new test shouldn't be harder than filling a table with more data). Once it's done, you'll be able to decide on best way to implement parser and IUri interface. The project should result in many tests and good support for at least more useful flags and IUri functions. Thanks, Jacek

March 31, 2010

GSoC - keyboard input

by wylda＠volny.cz

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.

March 31, 2010

Re: Summer of Code applicant with ambition!

by Roderick Colenbrander

On Wed, Mar 31, 2010 at 11:56 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > I think writing (yet another) D3D benchmark isn't going to help a lot, there > are already numerous benchmarks out there. > > I have built a very hacky set of cxtest and php scripts that run a bunch of > benchmarks and games(3DMark, Half Life 2, UT 2004, Team Fortress), store the > results on a server and generate some graphs with gnuplot. Extending this and > making it easier for others to run would be more useful than implementing > another benchmark. > > If you want to get familiar with the D3D code writing tests is a good start. > If you want to implement some small new functionality, maybe Nvidia's Depths > Bound extension( NVDB, see http://aras-p.info/texts/D3D9GPUHacks.html ) might > be a possible weekend project. > > Btw, the above webpage might have some other d3d9 "extensions" that are more > work could be suitable for Gsoc projects, maybe DF16, DF24, INTZ, RAWZ, NULL > and ATOC. > > Optimizing wined3d is certainly an idea as well, but it's not an easy task. > We're beyond the point where you can get reasonable performance gains from > simply fixing a loop or two. Some performance issues are known bugs(sRGB > switching, sRGB write correction in HW, thread synchronization), others > require tedious debugging to find out what specific 3D drivers don't like about > our GL calls. > Perhaps the long talked about fixed function vertex shader replacement could be an option though. It would fix vertex blending but it might also improve performance (some people were complaining about poor GL T&L performance http://forum.winehq.org/viewtopic.php?t=7975) Further it might be more efficient for modern drivers anyway, especially open source DRI ones since they are mostly investing in shaders. Roderick

March 31, 2010

Re: Summer of Code applicant with ambition!

by Stefan Dösinger

Hi, I think writing (yet another) D3D benchmark isn't going to help a lot, there are already numerous benchmarks out there. I have built a very hacky set of cxtest and php scripts that run a bunch of benchmarks and games(3DMark, Half Life 2, UT 2004, Team Fortress), store the results on a server and generate some graphs with gnuplot. Extending this and making it easier for others to run would be more useful than implementing another benchmark. If you want to get familiar with the D3D code writing tests is a good start. If you want to implement some small new functionality, maybe Nvidia's Depths Bound extension( NVDB, see http://aras-p.info/texts/D3D9GPUHacks.html ) might be a possible weekend project. Btw, the above webpage might have some other d3d9 "extensions" that are more work could be suitable for Gsoc projects, maybe DF16, DF24, INTZ, RAWZ, NULL and ATOC. Optimizing wined3d is certainly an idea as well, but it's not an easy task. We're beyond the point where you can get reasonable performance gains from simply fixing a loop or two. Some performance issues are known bugs(sRGB switching, sRGB write correction in HW, thread synchronization), others require tedious debugging to find out what specific 3D drivers don't like about our GL calls.

March 31, 2010

re: Implementation of WIndows Gaming APIs as GSoC project

by Mariusz Pluciński

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.

March 31, 2010

Re : Summer of Code applicant with ambition!

by paulo lesgaz

One of the most useful GSOC project for gamers would be to implement DInput with XInput2. Vitaly sent some hackish patches in Bug 6971 It could be a good start to begin to code. A+ David On Tue, Mar 30, 2010 at 6:11 PM, Edward Savage <epssyis(a)gmail.com> wrote: > <snip thread> > > Sorry this is a little off topic from D3D but maybe what the OP is > looking for. > > I'm not sure how easy it is but .net 3.5 sp1 is currently a blocker > for several high profile games that would otherwise work well with > Wine, and many others that may work. .net needs to install correctly > and function well enough so that generic .net game lunchers run and > (importantly) Games for Windows Live runs and authenticates. GFWL is > what many of these games rely on and it is currently blocked by .net > so it's unknown how well it runs under Wine but it does install > properly. > > This maybe suited to a GSoC project and in my opinion would have the > greatest positive outcome for gamers. > > Edward Edward seems to know what I'm after. :-) As I mentioned originally, I'm a gamer and so that's where I'd like to lend my coding arm. If .net is doable, I'd certainly look into that too. > Note, I don't want to discourage you but I'm not sure if we should > write any benchmark app to be bundled with Wine. When a game is slow > it can be due to a lot of factors: > - quality of the display drivers, basically only Nvidia's drivers > (though AMD is catching up) are well optimized > - opengl extensions supported by the display driver, not all drivers > support functionality like FBOs, GLSL and other stuff which is needed > to run games at good speeds > - behavior of the app, if unlucky the app makes calls which are > inefficient to emulate (on newer cards, modern opengl extensions can > remove some of the limitations and we use such extensions where we > can) > > So when you encounter a 3D performance issue, it is not necessarily a > Wine issue. I certainly agree here 100% -- however, my own previous experiences have led me to conclude that there are Wine performance deficiencies *somewhere* (maybe not necessarily D3D, but it seems the likely candidate). See e.g. Warcraft 3 and World of Warcraft. Both of these games have Direct3D and OpenGL modes. Running each game in Wine (at least in my testing from several months to a year ago) D3D was anywhere from 40-60% slower than OpenGL mode. I'd be happy to test with the latest Wine, too. The point is, all things being held constant, calls that had to go through WineD3D were much slower. That's where the spirit of my proposal came from, anyways. Now, you might say "does Wine need some sort of benchmarking?" That's debatable. Maybe it could be a part of dxdiag? My goal for this proposal was to create something that developers could use to assess performance deficiencies, or that end users (maybe) could use to figure out what type of effects ought to be turned off/down on their systems. Essentially, answer the question "what's making my FPS drop?" Is it AF, AA, specular lighting, HDR? There's been a lot of feedback so far (thanks!) So far, the projects I'd like most are roughly: * Get .net 3.5 working * Implement dxdiag * DirectShow/Gstreamer * The "Direct3D - Conformance / Performance / Interactive tests" given @ http://wiki.winehq.org/SummerOfCode#head-8d0895f237c9c3579ffe4282412bbbf2c8… Again, many thanks for all the helpful feedback. I look forward to (hopefully) being able to work with you all in the near future. :-) John

March 31, 2010

Re: [GSoC] IUri Implementations

by Thomas Mullaly

> You could use dynamic array for that or a list with a Uri_PROPERTY > value as a key for example and a data as an offset and length. Another > way is to compute each property offset only when it's requested and > store it. An obvious bad case for that is a long uri. So probably one > pass property computation while building IUri instance is not bad. > I like the idea of making a lightweight data structure which stores the offset and length for each component property. I'd imagine it would look something like this: typedef struct { DWORD offset; DWORD length; } UriComponent; Although it becomes a little more tricky on how to store the UriComponents, but, I have a few ideas if anyone has any suggestions. I do like the idea of using an array inside the Uri struct to store the UriComponents but not all of the values in the Uri_PROPERTY enum actually mean anything (at least thats what I have gathered from reading the MSDN docs), like the Uri_PROPERTY_STRING_START and the Uri_PROPERTY_STRING_LAST are just there to say all the enum values between >= START and <= LAST correspond the string components of the URI. So I'm thinking the Uri struct should have a constant size array of UriComponents of length Uri_PROPERTY_STRING_LAST (which would be 15.. correct me if I'm wrong). So it would look something like... typedef struct { /** The other stuff */ BSTR *uri; UriComponents components[15]; } Uri; and then for the GetPropertyBSTR(BSTR *component, Uri_PROPERTY prop) function you could just have something like. if(prop >= Uri_PROPERTY_START && prop <= Uri_PROPERTY_LAST) { UriComponent comp; comp = uri->components[prop]; /** Parse the component out */ } And that should get you the necessary offsets and lengths for the component you need. I also like the idea suggested before using a one-pass solution to find everything when the Uri is constructed. Thank you for the quick responses and suggestions, I hope to have a proposal ready in the next few days.

March 31, 2010