Student Interested in Google Summer of Code 2010

Henri Verbeet hverbeet at gmail.com
Wed Jan 27 16:41:27 CST 2010


On 27 January 2010 20:14, Arjun Comar <mandaya at 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.



More information about the wine-devel mailing list