How big is the Direct3D stuff?

[Lionel Ulmer]

Hi all,

As I once started working on Direct3D in Wine and was one of the contributor
to the DDraw code, let me answer some of these questions :-)

>  * What are the tasks for implementing Direct3D?

It's not easy to separate the tasks. For one, documenting and
re-appropriating the DDraw code would be the first thing to do.

<start of minor rant>

As other people discussed it, the current DDraw code in WineHQ's CVS tree is
from TransGaming. I do not say that it's worse than the previous code (it's
certainly better and respects the DLL separation stuff), but my biggest
problem with it is that it was entirely developped 'in-house' and sumbitted
'as is' to the WineHQ tree without really involving any of the WineHQ
DirectX developpers (like Marcus or me). Now don't undertand this wrong, I
am certainly also to blame because I found other interests at that time and
mostly stopped working on Wine.

This means that now that TG does not really contribute back much to WineHQ
(even in pure 2D stuff), we have a large piece of code that nobody really
bothered to undertand and is largely unmaintained.

Now I understand why Linus absolutely refuses big patches doing a lot of
stuff in one go and wants small incremental patches :-)

Finally, saying 'now let's start working on Direct3D' will not help much if
we do not find at least 3 or 4 people interested in working on it. I once
submitted some D3D work but nobody ever contributed to it and it was mostly
unmaintained once I stopped working on it (and I fear that would be the same
for other parts of Wine like Multimedia, the debugger for example, if Eric
did take some prolonged vacations :-) )

So the current situation is *not* TransGaming fault, but largely the
community's for not doing anything at all and letting things in the state it
was (well, not TG's fault except if you consider that they 'bought out' the
people who would have worked on it in their free time, but that is just
plain good business sense :-) ).

<end of minor rant>

>  * Can older versions be implemented independently from the newer ones?

This is the big problem when doing DDraw work, designing stuff that :

 a) can work accross multiple DDraw versions (ie find the common stuff and
    implement hardware acceleration here and then doing the rest in some
    'emulation' layer).
    
 b) can work accross multiple object 'types' (for example, a surface can be
    the front / back buffer, a texture, a ZBuffer, a compressed texture, some
    random buffer, an overlay, ...).

 c) respects the DLL separation (ie puts all 'hardware' related stuff like
    X11 calls or OpenGL in the X11drv).

>  * Do we have nothing at all or do we have something? What changes need
> to be done to this something to make it better.

We still have the old Direct3D code that I wrote to support DirectX 5 / 6 in
CVS (not functionnal, but enough to see the ideas :-) ).

>  * What modifications are necessary to other parts (x11drv, DirectDraw)
> to implement Direct3D?

As said before, a lot of X11drv work and a DDraw rework :-)

>  * Are there other DirectX areas that are lacking and that will prevent
> games from working even if we get Direct3D working (DirectPlay,
> DirectInput)?

Mostly all the DirectX 8 (Dinput and DSound 8) if we want to support
Direct3D 3. Otherwise, we should have almost everything needed in the other
DirectX stuff to implement Direct3D.

>  * One item I can suggest is adding support for XVideo to DirectDraw (I
> believe that's where it fits) to enable hardware scaling and YUV
> conversion when playing videos. This would be more for media players
> than games but could be useful anyway.

I have a patch than I am slowly working on to re-add the Xv support to DDraw
(it's based on some work that Marcus did). But as explained before, it's not
that easy to do :-)

                            Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/