RFC: D3D7 and WineD3D

[Stefan Dösinger]

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