Simple D3D/WGL demos for wine

[Matteo Bruni]

2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111 at gmail.com>:
> Hello all. I'd like to implement a set of simple demos which would be
> something like glxgears for Wine — a simple way to check that WGL,
> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need
> to look for a real app to test. I suppose it's not very interesting to
> have just flat untextured gears, so I'd instead draw a textured cube
> (similarly to what the tests in dxdiag do).

Do you plan to include these demos in Wine or maintain them
separately? I'd be in favor of including them in Wine proper (others
might disagree though) but that introduces a few additional
constraints, like no C++ code allowed.
BTW, actually we do have a (VERY sketchy) dxdiag implementation in
Wine, under programs/dxdiag/. You could integrate those demos into it
in principle.

> I have some prototype code for this (standalone and written in C++ for
> now), and it uses D3DXCreateTextureFromFile. This is all OK when I
> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with
> ming32. But when I try to compile for D3D8 with wineg++, there's a
> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine.
>
> Is it undesirable for Wine to have d3dx8 (I remember some commits
> removing the library and headers related to it several years ago)?

You remember correctly. It turns out d3dx8 in practice was always
statically compiled into the game executables. IIRC the DX8 SDK had no
d3dx8.dll at all, just a d3dx8.lib with the full library. There was
also a d3dx8_d.dll with a debug version of the library but that wasn't
installed by the usual DirectX redistributable so applications can't
depend on its presence either. In any case, we've had 0 applications
using our d3dx8.dll, which means our implementation wasn't actually
used or tested and there was no point in keeping it.

> Should I just drop usage of D3DXCreateTextureFromFile and use plain
> IDirect3DDeviceX::CreateTexture?

You could use some other API to load the image files. I imagine that
mixing d3dx9.h with d3d8 won't be a great experience. There are other
options though, depending on the texture file format you want to use;
WIC (windowscodecs) might be a good choice generally speaking.
Another possibility is to create the textures you need procedurally,
without needing to load them from a file or a resource.

> Also I use some matrix functions, which are identical between d3dx8
> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for
> d3d9 and d3d8 versions of it? Or should I just reimplement all the
> needed functions?

As I mentioned above, I suspect you would get issues when trying to
include d3dx9.h together with d3d8.h, although you can probably
workaround that in this case by carefully dividing your code over
multiple .c files.
Depending on what you exactly need, just copying or reimplementing the
relevant functions might be simpler.

As an aside, one possible objection to these demos could be "but we
have tests already!" IMO these cover a somewhat separate use case and
having simple d3d* demos that common users could easily run, similarly
to the "Test sound" button in winecfg, could be valuable.