Implementing dxdiag as student project?

Stefan Dösinger stefan at codeweavers.com
Sun Dec 28 10:05:48 CST 2008


I think we should stay as close to the way the windows tools work and avoid
inventing too much wine-specific things. This is how I understand the
windows tools:

* dxdiag.exe: Prints DLL information, has very simple tests for ddraw, d3d,
dsound, dmusic, dplay. The tests just show that a device can be created and
a cube can be rendered. This could detect if the opengl libs are missing,
but it won't be able to tell direct rendering from indirect rendering.
(really dxdiag can't say so via the win32 API).

*) dxcapsviewer.exe: This app lists all the capability flags advertised for
ddraw, d3d8, dsound, etc. It is part of the dx sdk, but I don't see a
problem with implementing it. Sooner or later we'll clone other tools from
the dx sdk too, like vsa.exe, psa.exe and fxc.exe(shader assemblers and
compiler)

Another feature idea is to enable ddraw, d3d8 and d3d9 to import a
capability flag dump from dxcapsviewer to advertise exactly the same flags
as on Windows. This can help to debug capability flag problems.

*) pixwin.exe is interesting too. It allows to record something similar to a
+d3d9 trace on Windows, and save it for playback. The native version
currently doesn't work on wine, but I think it is fixable. A similar tool
could be useful to (1) see if a log recorded on windows produces the same
output on Wine, and (2) to see if a windows app performs the same calls on
Wine as it does on Windows(to detect caps problems for example)





More information about the wine-devel mailing list