GSoC D3DX9 work

[Tony Wasserka]

> Hello,
> I might be interested as a side project. I've been poking around in the
> wine code looking for something interesting for the last few weeks and
> this might be it. However I know I wouldn't have much interest in it if
> it doesn't actually help me, so I'd like to know a few additional
> details about it.
>
> * Do you have list of bugs that your changes are known to fix?
> * Same question for what bugs a completed work should fix.
> * Could I see the TODO list to get a better idea of what needs to be done?
>
> Thank you.
>   
(note that I replied to wine-devel since this might be useful for
someone else as well)

Okay, so here we go:
Generally, I don't have visual (wine) tests for any of the stuff I
wrote, not sure whether they're needed actually though.

font code:
- Probably the easiest to start with, although it might be a bit
confusing if you're unfamiliar with the code.
- Requires D3DXFilterTexture with D3DX_DEFAULT filter on A8R8G8B8
textures first though (that one's relatively easy to implement).
- Requires this
http://repo.or.cz/w/wine/d3dx9TW.git?a=commit;h=e4dfdb7c2cc4264bbe89ef938c939a3965f654ca
patch to be applied first (fixes a bug in D3DXSprite implementation)
- Not sure whether PreloadGlyphs was working correctly when I last
worked on it. Glyphs are cached into textures and if an app caches to
many glyphs new textures must be generated, which I didn't do first. I
added this functionality but can't tell if it still works. Could be
tested pretty easy with my testing demos.
- Glyph positions in the texture cache (which are returned by
GetGlyphData) differ by 1 or 2 from the native dll. At least they did,
maybe I figured out why and fixed it meanwhile. It doesn't really matter
anyways since it doesn't really affect applications, but just wanted to
tell you ;)
- two flags in DrawText aren't implemented, yet (DT_NOCLIP could be
important to speed up things). Generally that one function (and its
bunch of helper functions) really needs some cleanup before actually
submitting it to wine-patches. It's forked from user32 code (or
whereever DrawText is implemented in), so it's not /that/ clean.
In conclusion, the only problematic bit here should be the last one.

texture code, D3DXLoadSurfaceFromMemory:
- implement other color conversion and filtering routines, you REALLY
should talk to me in case you really want to do this, since I have
thought much about how to organize code to be efficient and relatively
clean as well, and I'm having a fairly good idea how it probably should
be done.
- What's missing for color conversion: about any format which is not
unsigned 1,2,3 or 4 b(yte)pp ARGB, but my design allows fairly easy
addition of support for large ARGB formats, signed formats, luminance
channels and other non-compressed stuff. compressed formats might be
hard, but not a necessarity to implement in the first place anyway.
- other filters to be implemented: point filtering is the only one
necessary here actually, since it can be used as a fallback for more
advanced filters for now.

texture code, other stuff:
- not really much to fix here, it just all depends on a working
D3DXLoadSurfaceFromMemory implementation.
- only thing: my d3dx9 implementation implements
W(indows)I(maging)C(omponent) codecs, and I'm not really sure how to
integrate that one into Wine. right now they reside in the d3dx9 folder
itself, but it could also be possible to create a new dll for it (since
it might be usefull for d3dx10 as well)... you should talk to
madewokherd (sorry if I'm misspelling that nick; he's the one who
implemented most of the WIC stuff) and julliard (since he is the one to
decide whether the integration method actually goes into mainline) on
IRC about how to it properly I guess.

mesh code:
- right now dependent on d3dxof for .x file loading routines, but d3dx9
actually provides its own file loading routines, which should be
reimplemented using d3dxof's methods. The current code must be ported
over to using the d3dx9 methods.
- Optimize() is not really implemented, I have a few ideas how to do it,
but it's not of greates priority anyway
- D3DXCreateMesh might work with some vertex declarations which do NOT
map directy to a FVF, this might require architectural changes to the
core code...
- generally, the COM interfaces might not be implemented cleanly (maybe
they are though, I wasn't sure how to do it properly since dsound and
wined3d are doing this different, I went for the way wined3d does it).
- .x file parsing doesn't read texture file names... this one might be
trivial but I just couldn't get it working, for whatever reason
- D3DXFVFFromDeclarator might not cover everything - I just forked it
from some wined3d or d3d9 code (it does work fairly good at least)

As for the affected bug reports, just search for the "d3dx" or
"createtexture" terms on bugzilla ;) No non-DX-SDK apps are really
dependant on the mesh stuff AFAIK, only few on the font stuff (e.g. the
Dolphin emulator), so there aren't really any bug reports for them. -
generally there aren't that many bugs, since most d3dx9 code just wasn't
implemented, yet... There are numerous games though which don't run with
our d3dx9 implementation, since they often require the texture loading
functions.