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.
Hi,
Another idea came up in #winehackers: Implement the interesting bits of nvapi.dll, e.g. for http://bugs.winehq.org/show_bug.cgi?id=24928 .
The main caveat and challenge is that we don't know much about this library. It is Nvidia-specific, and http://developer.nvidia.com/nvapi has some documentation and development files. However, this seems to be only a part of the library. Maarten Lankhorst hacked a bit on it and warned about an undocumented query function(probably nvapi_QueryInterface) that is used to retrieve a lot of other undocumented function pointers.
Another challenge is agreeing on a way how d3d9.dll and nvapi.dll interact. Nvapi gets a IDirect3DDevice9 * from the app, and would call wined3d. For this it needs the struct wined3d_device * that is in the d3d9 device implementation. But only d3d9.dll knows this, as it is a private implementation detail.
For more details see http://developer.nvidia.com/nvapi . The interesting function for bug 24928 is probably NvAPI_D3D9_StretchRectEx, but there are many other goodies in that library.
Since this library is a part of the Nvidia Windows drivers a Nvidia GPU is required for this.
My guess is that this would be an interesting, but hard and risky project. It'll require some reverse engineering skill(or diplomancy, if you want to ask Nvidia about the needed information and get it in a non-NDA'd form).
Stefan
Am Samstag, 10. März 2012, 22:04:17 schrieb 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.
On 14 March 2012 19:50, Stefan Dösinger stefandoesinger@gmail.com wrote:
Another idea came up in #winehackers: Implement the interesting bits of nvapi.dll, e.g. for http://bugs.winehq.org/show_bug.cgi?id=24928 .
I don't think so, unless you can make a convincing argument.
-
Henri Verbeet -
Stefan Dösinger -
Stefan Dösinger