On 27 January 2010 20:14, Arjun Comar mandaya@rose-hulman.edu wrote:
@Henri: I'm always up for a challenge. Perhaps you could suggest a smaller subset of the problem that would be more feasible to attempt in 2-3 months? Perhaps a few effects rather than any significant chunk of them? Also, what are you looking for in a proposal?
Here's the wiki for the problem I mentioned in my first post: http://wiki.winehq.org/DirectX-D3DX9 . What's the current status on this proposal? It sounds like a fairly major problem.
The problem with the effect interface is that there are several fairly large parts/dependencies to implement. For example, it has important dependencies on both the (non-existent) HLSL compiler and the only partially merged shader assembler, needs to compile text effects into the (AFAIK) undocumented binary effect format and read that same binary format, and then render those effects in an efficient way. We'd certainly welcome work in this area, but it's a pretty large thing to implement with plenty of unknowns. My personal opinion is that you'd want something that's at least reasonably well defined in terms of what it would take to complete for a Summer of Code project.
If you're looking for a subset of the effect interface, the thing that most applications will likely need is the part that does parsing of binary effects and rendering those. It would help if you found an actual application or set of demos that uses those interfaces though. An added advantage would be that you'd get an idea of how those interfaces are used in practice.
As for what I'd look for in a proposal, an important part would be if the proposal is realistic in a technical sense, but also if it's possible to complete in that time span. Other considerations would be if the proposal is useful in the first place, and whether I get the impression that the author knows what he's talking about. Note that if you're a first time contributor to Wine, there's a significant chance that you'll spend quite some time working out process issues like setting up a proper build environment, learning to work with git effectively, submitting proper patches, etc. It would improve your chances of successfully completing the project quite a bit if you can get all that worked out before starting the project, by fixing a small bug or making an improvement somewhere in Wine and getting that patch committed. Perhaps students from previous years can also comment on this.
I'd be careful with things like cleaning up and submitting projects from previous years. In principle that's a useful thing to do, but due to the nature of the project, Wine cares pretty strongly about things like authorship information. For this reason it's *strongly* preferred that the original author submits a patch. It does happen that people submit patches for someone else, but it's pretty rare, and usually by more established rather than new contributors.