Directx 9

Ann and Jason Edmeades us at
Sat Jan 8 14:27:03 CST 2005


FYI I've spent the last couple of months putting together a directx 8 level
support into wined3d and calling it from d3d9 such that I can also change
d3d8 easily to use the new code. This is mostly complete other than the
texture support and the shader support plus moving some functions / stubs
into the common code.

If you have any directx 8/9 questions feel free to email me directly, put
questions on wine-devel or perhaps even the wined3d (very, very quiet - mailing list (Lionel's). You
really are welcome, and I'll try to answer any questions I can.

I wouldn't spent too much time trying to move existing functionality between
d3d8 to wined3d unless you really want to as I am trying to get this move
completed asap. I really don't want to discourage any d3d assistance, its
just I know where I am and what I have left to do.

I have generally been doing a patch and getting it committed both due to
lack to time, but also to avoid potential rework of multiple patches. I
really hope to get most of the non-shader support done quite quickly once
the 20 patch goes in (Christmas and FarCry got in the way, and I had some
teething problems with the render target support which delayed it!). Next
will be the texture support and that should be quick as it is relatively
trivial to move across.

>As soon as I'm happy with how wine's and directX work
>I can stop duplicating what you've done and start
>moving onto a more co-operative development...

Sounds good - one thing wine has suffered from is a lack of people doing the
directx support! Note that Raphael (copied on this note) has some
outstanding patches he has put off while I do the move to support hardware
vertex buffers so the drawstridedslow case is driven less frequently, but
that's the only outstanding work I know about.

> or moving DirectX8 over to using WineD3d.
I have a version locally where I have changed d3d8 up to about patch 13. I
can send it to you if it helps - Unfortunately I think the swap to wined3d
will have to be one big patch, I don't think there is a way to move d3d8
over slowly, as you have to move the state block code in one go, the
resource8 subclasses in one go etc... 

>I've merged all the creation surface code into a
>single createSurface function that is called with
>different parameters/flags to create a backbuffer,
>PlainOffscreenSurface or rendertarget etc...

Sounds fine - The problem I had with the latest patch was purely being able
to add the support for getfrontbuffer etc which needed to return d3d8 or
d3d9 objects, but the initial crates being done in the wined3d layer. A
single callback sounds useful, as I know I'll have to do something similar
for stencildepth surfaces (nothing else is created purely from the wined3d
layer, so I don't think others need the same). 

FWIW I do the same, ie find demos on the web with source code, and then try
to get them working. That's how most of the d3d8 support came about as it's
a lot easier making a demo work than finding why there's a small amount of
corruption for a particular game. I wouldn't claim to be a directx nor
opengl expert - its all been a learning experience as I go! Maybe we should
collect some useful test program links!

If there's any d3d8/9 programmers out there, there's definitely a fun
project to do to produce test programs for wine. They cant be automated (I
think!) but it would be useful to be able to visually see the effect
differences of all the render states, the texture states, prove the shader
support works in both hw and sw vertex and pixel code etc etc. 


More information about the wine-devel mailing list