Hello, my name is Daniel Oom and I'm a computer science and engineering student at Chalmers in Gothenburg, Sweden. I'm in my second year and I would love to partake in GSOC. I know C, use Linux daily and don't like it when I have to reboot my computer to windows.
I am very interested in game development and real time rendering, and have actually completed one simple game (written in Java/OpenGL). But I still have so much left to learn, and I believe I can learn a lot through working with wine in these areas.
My idea, or rather how I would like to improve wine, is related to gaming. I've tried to run some games in wine and sometimes it works very well but more often than not there's bugs. The bad performance, misc bugs and general unresponsiveness of Steam is my greatest itch.
Though as I'm not versed in wine's code base I don't know what would constitute as reasonable goals for GSOC. (I did do a bug report a long time ago, but back then I did not know a lot about programming).
Would, for example: fix Steam's in-game overlay feature be a good goal?
Some advice about where to take it from here would be greatly appreciated.
// Daniel Oom
On 03/07/2012 01:07 PM, Daniel Oom wrote:
Hello, my name is Daniel Oom and I'm a computer science and engineering student at Chalmers in Gothenburg, Sweden.
Welcome to Wine!
Would, for example: fix Steam's in-game overlay feature be a good goal?
Not really, as it's already working fine in most cases. You just need a "proper" version of gcc to compile Wine with.
You can find few ideas on what to do on GSOC Wiki page: http://wiki.winehq.org/SummerOfCode
Vitaliy.
Hi Daniel,
Again, welcome to Wine :-)
Finding good d3d-related gsoc projects has become harder each year, as the code is quite mature and we're out of easy things to fix. A few things that come to my mind are:
*) Writing more tests. Especially ddraw.dll could use a lot more tests and fixes for the pre-DirectX7 interfaces that are part of this dll, but also the dx7 interfaces.
*) The d3dx9 dlls are mentioned in the gsoc wiki page. I don't know how many medium-size tests (read: not HLSL-compiler related) are still left.
*) Speaking of d3dx9: An implementation of the vsa.exe, psa.exe and fxc.exe command line tools offered by the DirectX SDK may be a nice thing. This doesn't really require detailed d3d or gl knowledge either.
*) Fixing a bug of your choice may be an option. The risk here is that you get stuck finding out what the problem is, or that you end up with a problem that is not 3d-related and/or hard to fix. (e.g. the steam overlay had nothing to do with d3d, it needed a new feature in gcc)
*) Further implement Direct3D9Ex. This mostly comes down to writing tests, but there may be infrastructure changes involved that require in-depth knowledge of the d3d code.
*) A very long shot: Improve ddraw overlay support, e.g. to get some video players running. This *will* require very good understanding of Wine's d3d code.
I haven't looked into the details, so the time needed to accomplish either goal may be way off.
On Thu, Mar 8, 2012 at 3:23 AM, Vitaliy Margolen wine-devel@kievinfo.com wrote:
You can find few ideas on what to do on GSOC Wiki page: http://wiki.winehq.org/SummerOfCode
If he is adventurous, here is another idea:
A wish a day 14: Wine-based Application Virtualization http://www.elpauer.org/?p=1005
(too big for a Summer of Code, though)
-- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Am Donnerstag, 8. März 2012, 23:32:16 schrieb Pau Garcia i Quiles:
If he is adventurous, here is another idea:
A wish a day 14: Wine-based Application Virtualization http://www.elpauer.org/?p=1005
Wine doesn't help you too much in this(except for the cross-platform part), and the idea isn't really suitable for gsoc imo.
And no, Wine doesn't support USB devices(aside from some patches floating around), and you can't virtualize device drivers. Most drivers on Windows(and Linux) run inside the kernel. You can't simply boot up a second kernel instance to load the driver into.