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.
Implementation of WIndows Gaming APIs as GSoC project
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
