Student Interested in Google Summer of Code 2010

Tony Wasserka tony.wasserka at freenet.de
Thu Jan 28 11:33:39 CST 2010


About my own work, it's not been integrated that much, yet:  Loïc Hoguin
has expressed interest to integrate them, but I'm not sure whether he
was sure about that, yet.
I might work again on integrating my texture stuff in case you'd really
participate in gsoc with some d3dx stuff, can't promise anything though.
Arjun: Check
http://www.winehq.org/pipermail/wine-devel/2010-January/081160.html and
http://www.winehq.org/pipermail/wine-devel/2010-January/081288.html to
see what this is about. Contact me on IRC at #winehackers (my Nick is
BigBrain) in case you're still interested after that ;)

Matteo Bruni wrote:

> Yes, that's a relevant issue. I didn't find a single game, or even
> DirectX SDK sample, which needed only the shader assembler functions
> and not also some other unimplemented part of d3dx9 (expecially the
> texture functions are often used).
> This essentially means that you'd have to rely only on conformance
> tests to have some measure of correctness of your code (and fidelity
> to the behavior of native implementation), at least in the short to
> medium period.

One of my main goals was to get some DirectX SDK samples running in
Wine. During SoC, several factors pretended that, so I had to change my
goal:
I compiled the SDK samples in Windows using MSVC, but replacing all
D3DXCreateTextureFromFile (etc) calls with my own implementations, that way
I could easily check whether my code works in real-world scenarios
without depending on other D3DX code.
Of course, that won't work for closed source apps, but the DX SDK
samples are a pretty good starting point as well. In fact, a combination
of texture code, font code, shader code and effect code would probably
cover many of the DX SDK samples already. Too bad they'd still require
msvc++ (i.e. they don't compile with winelib) and safe string functions
(which we don't have implemented) then...

Henri: I'm not sure whether the D3DX9 interface _depends_ on the HLSL
compiler; maybe the bytecode effect compiler does, but there's plenty of
stuff the effect interface can do without shaders (on the other hand,
maybe the interfaces are using shaders internally, but I think state
blocks should be enough to do this stuff). I'm not really sure either
whether the effect area is doable in GSoC's timeline; maybe a part of it
(if that'd be usuable at all), otoh maybe it's not that hard in the end
though... That should be checked before of course. I'll have to hand in
a paper tomorrow, so I'll be busy for the rest of this evening, I could
maybe take a look at that tomorrow.

Best regards,
Tony



More information about the wine-devel mailing list