Hiya,
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 - http://www.bbrox.org/mailman/listinfo/wine-d3d) 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.
Jason