New subject: My Idea for GSOC

23 Mar 2012

      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@gmx.atwrote:
...
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@gmx.atwrote:
...
...
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.

Re: My Idea for GSOC