My Idea for GSOC

[Daniel Oom]

I think I accidentally dropped wine-devel, I have re-added and hope it does
not create any trouble.

And thanks for the explanation, but I'm not sure I fully understand how the
different versions of direct3d interact within wine's implementation. I
will probably figure it out in time.

Also I will try to come up with a better test that compares
lighting-settings as this was fun and fine introduction to wine.

On Wed, Mar 21, 2012 at 15:18, Stefan Dösinger <stefandoesinger at gmx.at>wrote:

> Hi,
>
> Did you run the test on Windows? The purpose of the tests is not do
> document
> what we think should happen, but figure out how Windows behaves, and then
> replicate the same behavior.
>
> Is suspect your test fails on Windows because you're verifying that
> lighting
> is on or off in the wrong way. IDirect3DDevice2_GetRenderState(device,
> D3DRENDERSTATE_LIGHTING, &value) will most likely not work in this way
> because
> D3DRENDERSTATE_LIGHTING does not exist in IDirect3DDevice2. You have to
> set up
> the d3d states in a way that rendering produces a different result with
> lighting on vs lighting off, then read back the rendering result(there's
> already a get_pixel_color function for that) and verify that you get the
> correct color.
>
> A basic recipie for that: With lighting off, you get the diffuse color in
> the
> vertex as final color(well, assuming that stuff like texturing, fog, etc.
> are
> off too). With lighting on it runs through the d3d lighting
> calculations[1].
> If you disable all lights(d3d default), set the global ambient light to
> black(in later d3d there's a renderstate for that, in d3d2 I suspect that's
> part of D3DLIGHT and IDirect3DLight*), and set the emissive material
> property
> to a color != black, your emissive color will be the final color(since the
> ambient, diffuse and specular components of the equation are zero). By
> setting
> the vertex color and emissive material color to different colors you can
> tell
> if lighting is on or off.
>
> Cheers,
> Stefan
>
> PS: It's prefered to keep such discussions in public, ie with wine-devel
> CCed.
> I haven't CCed wine-devel yet, and I'm not sure if you dropped it or if I
> dropped it accidentally.
>
> 1: http://msdn.microsoft.com/en-
> us/library/windows/desktop/bb147178(v=vs.85).aspx
>
> Am Mittwoch, 21. März 2012, 09:25:40 schrieb Daniel Oom:
> > I have poked around a bit with the source and managed to add tests that
> > checks if lighting is disabled/enabled in device2 and device7. I also
> added
> > SetRenderState in IDirect3DDeviceImpl_2_DrawPrimitive. The tests works
> but
> > I have not checked what effect the change has in other circumstances.
> >
> > I attached a patch in hopefully the preferred format.
> >
> > On Sat, Mar 10, 2012 at 22:04, Stefan Dösinger
> <stefandoesinger at gmx.at>wrote:
> > > Am Samstag, 10. März 2012, 17:22:51 schrieb Daniel Oom:
> > > > Hi,
> > > >
> > > > Writing tests, or implementing the command line tools seems like
> > > > something I could do. I'm kinda leaning towards the command line
> > > > tools, since it would offer a chance to thoroughly learn the shading
> > > > languages.
> > >
> > > For learning purposes writing tests and fixing bugs uncovered by them
> > > will be
> > > better. The command line tools are mostly about parsing parameters and
> > > forwarding them to d3dx9 functions(*).
> > >
> > > If you want to look a little bit in either proposal(we recommend that
> in
> > > general):
> > >
> > > For the test stuff, take a look at IDirect3DDeviceImpl_2_DrawPrimitive
> > > in
> > > dlls/ddraw/device.c. It thunks IDirect3DDevice2::DrawPrimitive to
> > > IDirect3DDevice7::DrawPrimitive. The main difference is the VertexType
> > > parameter. It is a D3DVERTEXTYPE in the IDirect3DDevice2 method, and a
> > > DWORD
> > > with D3DFVF_* flags in Device7. Our thunk simply converts between these
> > > two,
> > > but a deeper difference a user noticed is that D3DVT_LVERTEX in Device2
> > > disables lighting calculations, whereas the equivalent D3DFVF flag
> > > collection
> > > in Device3 and Device7 does not. Device3 and newer have
> > > D3DRENDERSTATE_LIGHTING to enable / disable lighting, but this render
> > > state does not exist in Device2.
> > >
> > > Fixing this is fairly straightforward, just call
> > > SetRenderState(LIGHTING,
> > > ...)
> > > in the thunk, but it needs some tests to answer / show the following:
> > >
> > > * Show that D3DVT_LVERTEX indeed disables lighting, and D3DVT_VERTEX
> > > enables
> > > it
> > > * Show that D3DFVF_LVERTEX does not influence lighting in Device2 and
> > > Device7(D3DFVF_TLVERTEX disables all vertex processing in all d3d
> > > versions, this is already tested and implemented)
> > > * Test what happens when you call SetRenderState and GetRenderState in
> > > Device2.
> > > * Probably others
> > >
> > > There are numerous things like that that need testing and probably
> > > fixes.
> > > This
> > > is just one example that happens to be on my todo list. ddraw tests go
> > > to
> > > dlls/ddraw/tests/ddraw*.c. The other files should be moved to the
> > > tests/ddraw*.c files and extended to cover all ddraw versions.
> > >
> > > For the command line tools, download an older version of the directx
> sdk
> > > that
> > > still has vsa.exe and psa.exe(I think 2007 ones were the last ones) and
> > > compare their command line parameters to
> > > d3dx9.D3DXAssembleShaderFromFile
> > > and
> > > friends.
> > >
> > > The tests are certainly the more useful task. vsa.exe and psa.exe would
> > > mainly
> > > serve developer convenience when writing d3d8 and d3d9 tests since we
> > > wouldn't
> > > need an ancient dx sdk to assemble our own test shaders. d3d tests and
> > > fixes
> > > fix actual games.
> > >
> > > Enjoy,
> > > Stefan
> > >
> > > (*) Actually, that's not how native vsa/psa work. They seem to have
> > > their
> > > own
> > > copy-pasted version of the compiler and assembler, or they link
> > > statically. We
> > > should probably do it by calling d3dx9 though, especially for tools
> that
> > > mainly serve developer convenience.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120323/b928bc5f/attachment.html>