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

Re: Implementation of WIndows Gaming APIs as GSoC project

by Austin English

2010/3/31 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: >>> 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. >> >> To avoid this problem, it should be possible to add option enabling these >> classes support in compilation configuration or Wine's config panel. Has >> this idea any sense? > > If we really wanted to disable the classes by default, the way to do > it would be to not register gameux.dll by default. You could then run > regsvr32 gameux.dll to set them up for a Wine prefix, until it's > considered good enough to be enabled by default. > > But I don't know if that sort of thing would be accepted in Wine, or > if it would be better to enable it from the start. Or disable it in winecfg. -- -Austin

March 31, 2010

re: A proposal for implementing dxdiag.exe: thoughts?

by Dan Kegel

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

March 31, 2010

Re: Implementation of WIndows Gaming APIs as GSoC project

by Vincent Povirk

>> 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. > > To avoid this problem, it should be possible to add option enabling these > classes support in compilation configuration or Wine's config panel. Has > this idea any sense? If we really wanted to disable the classes by default, the way to do it would be to not register gameux.dll by default. You could then run regsvr32 gameux.dll to set them up for a Wine prefix, until it's considered good enough to be enabled by default. But I don't know if that sort of thing would be accepted in Wine, or if it would be better to enable it from the start.

March 31, 2010

Re: Implementation of WIndows Gaming APIs as GSoC project

by Mariusz Pluciński

Vincent Povirk <madewokherd+8cd9(a)gmail.com <madewokherd%2B8cd9(a)gmail.com>> > 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. To avoid this problem, it should be possible to add option enabling these classes support in compilation configuration or Wine's config panel. Has this idea any sense? > 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. > This looks like good idea for me, I'll probably include it in my proposal. Thanks.

March 31, 2010

Re: A proposal for implementing dxdiag.exe: thoughts?

by Stefan Dösinger

Am 31.03.2010 um 22:41 schrieb John Koelndorfer: >> Concerning tests, a possible project would be to pick an ATI and Nvidia GPU and make sure that our existing >> conformance tests pass on both GPUs on at least WinXP, WinVista and Win7. Currently there is no single >> Windows setup that can run all the tests successfully(usually because the tests are too strict), and that is a shame. > > Not even Alexandre's? :-) I don't know that this would necessarily be > worth it either. I might be wrong but doesn't > even a minor change to a graphics driver have a chance to cause a test > to fail? They pass on Linux/Wine on Nvidia cards. They don't pass on fglrx due to a few (documented) driver bugs, similarly on OSX. I think the tests pass in Mesa Software. > If that's the case, I'd certainly > not want to try to get tests passing between WinXP and WinVista/7 > since the architectural difference is > enormous. It's not that big, and the actual architecture is irrelevant, what is important is the behavior games see. It is helpful to know the differences between the Windows versions. For example, I recently noticed that a game called Shaiya performs D3D calls that didn't make sense. Those calls failed on Windows 7, with Wine behaving in the same way the game crashed. WinXP behaved differently, making Shaiya happy. And indeed Shaiya crashed on Windows 7 too. Thinking more about this though, debugging the tests and thus debugging possible driver bugs requires a lot of in-depth knowledge about various obscure D3D features, so it is probably not suitable for newcomers.

March 31, 2010

Re: A proposal for implementing dxdiag.exe: thoughts?

by John Koelndorfer

> I am still skeptical about the directx conformance test part. For one part, we already > have this: It's our regular unit tests, to be found in dlls/d3d?/tests/*, dlls/ddraw/tests/*, > etc. 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. > For end user purposes it would make more sense to write tests testing for known driver bugs and > report them to the user, stating a possible solution(usually "hope for a driver update") and possible > game specific problems this may cause. I'm not convinced that this is worth the effort however, since > usually all we can tell the user is that his driver is broken and that the game won't run no matter what > he does. I'm not convinced that would be worthwhile either. AppDB seems to document those types of things just fine already, and as you say the solution is most likely "wait for a driver update." > Concerning tests, a possible project would be to pick an ATI and Nvidia GPU and make sure that our existing > conformance tests pass on both GPUs on at least WinXP, WinVista and Win7. Currently there is no single > Windows setup that can run all the tests successfully(usually because the tests are too strict), and that is a shame. Not even Alexandre's? :-) I don't know that this would necessarily be worth it either. I might be wrong but doesn't even a minor change to a graphics driver have a chance to cause a test to fail? If that's the case, I'd certainly not want to try to get tests passing between WinXP and WinVista/7 since the architectural difference is enormous. Thank you for the input. I will work on a few other proposals and shoot them to the list soon. Hopefully I can have them formally submitted within the next few days. As always, thanks!

March 31, 2010

Re: A proposal for implementing dxdiag.exe: thoughts?

by Stefan Dösinger

I am still skeptical about the directx conformance test part. For one part, we already have this: It's our regular unit tests, to be found in dlls/d3d?/tests/*, dlls/ddraw/tests/*, etc. For end user purposes it would make more sense to write tests testing for known driver bugs and report them to the user, stating a possible solution(usually "hope for a driver update") and possible game specific problems this may cause. I'm not convinced that this is worth the effort however, since usually all we can tell the user is that his driver is broken and that the game won't run no matter what he does. Concerning tests, a possible project would be to pick an ATI and Nvidia GPU and make sure that our existing conformance tests pass on both GPUs on at least WinXP, WinVista and Win7. Currently there is no single Windows setup that can run all the tests successfully(usually because the tests are too strict), and that is a shame.

March 31, 2010

Re: A proposal for implementing dxdiag.exe: thoughts?

by John Koelndorfer

> A lot of the work is already done: > http://bugs.winehq.org/attachment.cgi?id=22871. There's a stub > dxdiag.exe already in wine, and last year some students from UCLA > coded a relatively functional dxdiag.exe. It's not yet in wine, > though. > > I don't think it would take a GSOC amount of work to get it cleaned up > and into wine, but I may be overestimating the quality of the code. > Regardless, I'm sure others have more to say. > > -- > -Austin I noticed that much of the work was done. I did indeed plan to use this as a reference. However, from what I've read of the patch that doesn't include the DirectX "conformance" portion that I described. I am also under the impression that I'd have to write a lot of unit tests, which takes time. Then, there's the whole getting code by Alexandre thing. For a lowly student like myself, that may not be so easy. :-)

March 31, 2010

Re: A proposal for implementing dxdiag.exe: thoughts?

by Austin English

On Wed, Mar 31, 2010 at 1:33 PM, John Koelndorfer <jkoelndorfer(a)gmail.com> wrote: > 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. A lot of the work is already done: http://bugs.winehq.org/attachment.cgi?id=22871. There's a stub dxdiag.exe already in wine, and last year some students from UCLA coded a relatively functional dxdiag.exe. It's not yet in wine, though. I don't think it would take a GSOC amount of work to get it cleaned up and into wine, but I may be overestimating the quality of the code. Regardless, I'm sure others have more to say. -- -Austin

March 31, 2010

A proposal for implementing dxdiag.exe: thoughts?

by John Koelndorfer

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.

March 31, 2010