My Idea for GSOC

[Stefan Dösinger]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120310/b36e40d6/attachment.pgp>