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=e4dfdb7c2cc4264bbe89ef938c93... 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.
On 01/22/2010 03:48 PM, Tony Wasserka wrote:
[...] 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.
Hello,
Well I'm mostly interested in the texture code, but I probably shouldn't begin with that. So I'll take the font code. It's not really a critical part so I can take my time doing it and learning wine development without conflicts with my normal schedule. Then if the texture code is still in limbo I'll be glad to do it.
I'll try to talk to you on IRC sometimes next week, although I probably won't start working on it until the week after. What timezone/hour are you generally available?
Greetings.
Hello,
Well I'm mostly interested in the texture code, but I probably shouldn't begin with that. So I'll take the font code. It's not really a critical part so I can take my time doing it and learning wine development without conflicts with my normal schedule. Then if the texture code is still in limbo I'll be glad to do it.
I'll try to talk to you on IRC sometimes next week, although I probably won't start working on it until the week after. What timezone/hour are you generally available?
Greetings.
fwiw: http://whatismytimezone.com/ says my timezone is GMT+1 what I can tell for sure is, I live in Germany ;)
Anyway, I'm nearly always on IRC when I'm home, so I hope there shouldn't be that much of a problem contacting me. (I'm reachable between 3pm and 8 pm of my time then)
-
Loïc Hoguin -
Tony Wasserka