Re: Is this a bug or feature incompleteness
On 02/18/2010 01:44 PM, MD.IMAM HOSSAIN wrote: > The bug is from DirectX 8.1 SDK, C++ samples, Direct3D samples, SkinnedMesh. > > Please, see the attached file for clear idea. > > Tested with latest wine 1.1.38 Probably this: http://bugs.winehq.org/show_bug.cgi?id=6955 Missing vertex blending. -- Loïc Hoguin web: http://dev-extend.eu
Re: Student Interested in Google Summer of Code 2010
On 01/29/2010 07:17 PM, Tony Wasserka wrote: > Am 28.01.2010 21:42, schrieb Loïc Hoguin: >> >> What would be the solution then to have a chance to get Tony's work >> committed if he can't/won't do the rest of the work himself > FWIW, I handed in my skilled-work paper today, so I've had some spare > time today again. I just prepared a patch which implements point > filtering for ARGB surfaces in D3DXLoadSurfaceFromMemory. If (and only > if) that one goes in, I can submit the D3DXFilterTexture implementation > which is needed for my font code to work properly. I'm going to send it > to wine-patches today or tomorrow probably then. Good news, thanks for your hard work! I hope my question didn't sound offensive, I only used this as an example in hopes it could get me a general answer over this issue. I have seen it pop up a few times the last month alone and so far I haven't seen a straight answer other than it'd be "hard" to get a commit if the author is different than the committer. Looking forward to your patches. -- Loïc Hoguin mel: es...@dev-extend.eu web: http://dev-extend.eu
Re: Student Interested in Google Summer of Code 2010
On 01/28/2010 09:25 PM, Henri Verbeet wrote: > On 28 January 2010 20:15, Arjun Comar wrote: >> Ah, I wasn't going to do it as a SoC project, but rather as a way to get a >> feel for wine, directx, etc. over the next couple months (leading up to >> SoC). Henri is suggesting that I not do so? >> > I think anyone would have a hard time getting those committed if > they're not the original author. What would be the solution then to have a chance to get Tony's work committed if he can't/won't do the rest of the work himself? -- Loïc Hoguin mel: es...@dev-extend.eu web: http://dev-extend.eu
Re: Student Interested in Google Summer of Code 2010
On 01/28/2010 08:15 PM, Arjun Comar wrote: > Ah, I wasn't going to do it as a SoC project, but rather as a way to get > a feel for wine, directx, etc. over the next couple months (leading up > to SoC). Henri is suggesting that I not do so? > > Anyway, if there are no objections, I'm willing to do it. Loic, you > probably have more experience, I'll cede to you if you want to work on > it. There are plenty of other things I can whet my teeth on. Both of us could work on it until this summer, I believe there is enough to do for two people. I may have more programming experience, but I haven't done much in wine, and my last real Windows development dates back 8 years, so we're both inexperienced in that respect. I can't say if you should do it or not though. But if you have nothing else to do in the meanwhile I suppose it can't hurt to get some experience, even if your SoC subject isn't affected by this work in the end. On 01/28/2010 08:25 PM, Tony Wasserka wrote: > Just btw, those depend on D3DXGetImageInfoFromMemory, D3DXFilterTexture, > D3DXCreateTexture and possibly others I can't think of right now. > D3DXFilterTexture is quite trivial, but the other two also add a notable > effort. On the other hand, I have written the neccessary code for all > three already though, it's just that I don't have that many WIC codecs, yet. Yes I expected that. The good part of it is that it's only texture code. Hopefully it doesn't use a codec that wine doesn't have yet and can become a good test case for the integration work. Otherwise it can still be something to aim for after integrating your work. -- Loïc Hoguin mel: es...@dev-extend.eu web: http://dev-extend.eu
Re: Student Interested in Google Summer of Code 2010
On 01/28/2010 06:33 PM, Tony Wasserka wrote: > About my own work, it's not been integrated that much, yet: Loïc Hoguin > has expressed interest to integrate them, but I'm not sure whether he > was sure about that, yet. > I might work again on integrating my texture stuff in case you'd really > participate in gsoc with some d3dx stuff, can't promise anything though. > Arjun: Check > http://www.winehq.org/pipermail/wine-devel/2010-January/081160.html and > http://www.winehq.org/pipermail/wine-devel/2010-January/081288.html to > see what this is about. Contact me on IRC at #winehackers (my Nick is > BigBrain) in case you're still interested after that ;) If a student wishes to do the integration work as a SoC project, then I'll step down. It'll certainly be more helpful for a student than for me. I can find another project to work on in that case. My main motivation about it is that I have 3 games which are using only a small subset of the D3DX functions: textures and math. The math is already done, so all that remains is the texture code. Specifically, the following functions: D3DXLoadSurfaceFromSurface D3DXLoadSurfaceFromFileInMemory D3DXCreateTextureFromFileInMemoryEx D3DXLoadSurfaceFromMemory D3DXCreateTexture With those implemented the games Touhou 10, 11 and 12 should work in wine without native DLLs. They're my priority. And probably a good test case. I also have games that use the font code so that would also benefit me in the long term (Trine imports D3DXCreateFontIndirectA for example, not sure if it uses it for anything important though). I don't think I have a game that uses the mesh code so, sorry, I have no interest about that. Other than that I'm also interested in seeing vertex blending make it into wine (other than the software patch), but from what I understand it depends on Stefan's work, and to be honest it sounds too complicated for me at this point. But maybe it would be a good student project? It's all there is missing for a number of older games to work perfectly. If a student wants to work on any of those then don't worry about me, I'll find something else to do. And I'll be here to help test if there's any need. Otherwise I'll proceed with the font code. -- Loïc Hoguin mel: es...@dev-extend.eu web: http://dev-extend.eu
Re: GSoC D3DX9 work
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. -- Loïc Hoguin mel: es...@dev-extend.eu web: http://dev-extend.eu
Re: dinput: Initialize js state with sane values when the application acquires the device instead of at allocation.
On 01/01/2010 10:44 PM, Vitaliy Margolen wrote: > Loïc Hoguin wrote: >> See the attached patch. >> >> +/* Get sane state values for the joystick before giving control to the >> application. >> + Before this call was made in alloc_device, before the application >> sets the joystick >> + properties, so the values given by fake_current_js_state weren't in >> the range >> + of values expected by a few applications. */ >> +fake_current_js_state(This); >> + > > The comment is a bit too verbose. First line is enough. > > However my main problem with your patch is you doing it on every acquire > call which invalidates prior state of the joystick which could have been > correct. I'm afraid you'll need to find a way to do it once or pull the real > device state from the device. > > Vitaliy OK for the comment. I had two possible solutions in mind, doing it in Acquire, which doesn't seem good, and doing it when the range properties are being changed (and keeping the original call in alloc_device for a safe initialization). This would mean the values would be correct at all time from the point of view of the application. I'm guessing the second solution is better then; after all, the axis data in 'js' should be invalidated if the range is changed (and possibly when the dead zone is changed too). In fact if I understand it correctly it should be possible to simply convert the existing data into the new range when this range is changed by the application. This would fix my issue without invalidating the data already available. Doing it for the dead zone doesn't sound as straightforward though, it would work perfectly if it is being increased but not when decreased, as data in the dead zone can't be recovered until the joystick sends more information. And as far as I know no application would benefit from doing this when the dead zone property is changed. Tell me what you think about this and I'll start working on a better patch. -- Loïc Hoguin mel: es...@dev-extend.eu web: http://dev-extend.eu
