Re: Implementation of WIndows Gaming APIs as GSoC project
2010/3/31 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. Or disable it in winecfg. -- -Austin
Re: Implementation of WIndows Gaming APIs as GSoC project
>> 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.
Re: Implementation of WIndows Gaming APIs as GSoC project
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? > 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.
Re: Implementation of WIndows Gaming APIs as GSoC project
2010/3/31 Mariusz Pluciński : > 2010/3/30 Dan Kegel >> >> 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.
re: Implementation of WIndows Gaming APIs as GSoC project
2010/3/30 Dan Kegel 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.
