RFC: D3D7 and WineD3D
Stefan Dösinger
stefandoesinger at gmx.at
Sat Dec 10 18:00:15 CST 2005
Hello,
In the past weeks, I've worked on a re-write of the Direct3D7 implementation
with WineD3D. Well, I've managed to get some games running, but I have also
encountered a few problems. Before I continue with this, I'd like to ask for
your opinions.
I have uploaded a patch to http://doesi.gmxhome.de/d3d7.patch.bz2, it's a diff
against Wine CVS from December, 11th 2005. It's not really meant to be used,
but rather to have something to look at.
I don't know how long I can keep the patch there, because I am limited in
space. I've sent the patch to Oliver some days ago to upload it to his
sourceforge website, it will be available there when he uploads it.
So what's the point of this mail? While a D3D7->WineD3D wrapping can be done
by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly
drawbacks:
-> Device initalisation: In D3D7, the first step is to create a IDirectDraw
Device, set up the device, create a surface and then create a Direct3D
Device. When creating the WineD3DDevice in the last step, I have to do some
ugly things to wrap the allready existing Surface to a newly created
WineD3DSurface. The same applies in reverse order for the device removal. I
also don't know what to do if a game changes the screen setup after D3DDevice
creation.
-> Surfaces: In D3D7 surfaces are children of IDirectDraw, while in WineD3D
they are children of WineD3DDevice. Because the D3D7Device can be created and
destroyed without modifying surfaces, I have to manage the surface's
properties and memory areas for both DirectDraw and WineD3D. Overrides for
the Lock() and Unlock() functions are used to access the WineD3D surface if
it exists.
I think that everything would be much cleaner if the DirectDraw functionality
was also moved to WineD3D. My suggestion is the follwing.
-> WineD3D would be initialised in the D3D7 way, using a new interface
WineDDrawDevice. D3D8 and D3D9 could easily manage this in their create
functions
-> Surfaces are created with WineDDrawDevice, and they survive the release of
WineD3DDevice. This makes surface creation easier for D3D7, and it's easy to
adopt it for D3D9 and D3D8.
-> The IWineD3DSurface interface gets additional functionality for DirectDraw
operations. I'd suggest 3 versions of the 2D functions: One based on plain
X11(for compatiblity) calls, one that uses DGA(speed without 3D
acceleration), and one that uses OpenGL(For fast rendering without /dev/mem
access). For DXVersion > 7 the OpenGL version is used, and for DX7 it can be
decided when the primary surface is created.
What's the drawback? First, it's much more work, and it's a really invasive
change to WineD3D, which becomes more complex. Because of this I'd like to
know your opinion before I spend a lot of time for this.
Stefan
More information about the wine-devel
mailing list