Re: Student Interested in Google Summer of Code 2010
Hi, We've had two D3DX projects last year - one implementing shaders, the other (which was mine) implementing meshes, fonts and texturing code. Both have only partially been integrated, yet (as far as I know), but most of the other stuff in d3dx9 is still untouched, you can take a look at the msdn documentation to see the whole list of interfaces. I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures. I'm not sure how much has been implemented in D3D10's effect area (they merged the effect interfaces from d3dx into d3d10), but you should maybe clarify with some d3d devs how much code can be shared here before. Just my suggestion, there might be other interesting areas of d3dx and Wine in general as well of course. Best Regards, Tony
On 27 January 2010 12:57, Tony Wasserka <tony.wasserka(a)freenet.de> wrote:
at the msdn documentation to see the whole list of interfaces. I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures. I'm not sure I'm sure the effect interface would be useful to implement, but aside from probably having a dependency on the HLSL compiler, it's probably just too hard. 2 or 3 months really isn't a whole lot of time either.
That said, I'd be willing to mentor D3D or D3DX projects this year, provided they have convincing proposals.
Am 27.01.2010 um 13:16 schrieb Henri Verbeet:
On 27 January 2010 12:57, Tony Wasserka <tony.wasserka(a)freenet.de> wrote:
at the msdn documentation to see the whole list of interfaces. I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures. I'm not sure I'm sure the effect interface would be useful to implement, but aside from probably having a dependency on the HLSL compiler, it's probably just too hard. 2 or 3 months really isn't a whole lot of time either. It would help a lot if the code from last years gsoc d3dx9 projects made it into wine git sooner rather than later to allow new participants to build on it. I don't know what the state of Tony's work is, but I think the only real concern blocking the assembler is splitting up the patches, a few commends and compatibility with older flex versions(what happened to that? Did Alexandre raise the minimum flex version needed to build wine?)
On 01/27/2010 01:25 PM, Stefan Dösinger wrote:
It would help a lot if the code from last years gsoc d3dx9 projects made it into wine git sooner rather than later to allow new participants to build on it. I don't know what the state of Tony's work is, but I think the only real concern blocking the assembler is splitting up the patches, a few commends and compatibility with older flex versions(what happened to that? Did Alexandre raise the minimum flex version needed to build wine?)
Not sure how new it is, but it looks like 2.5.33 is the minimum: http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce30733337e55d76c3870f... -- Cheers, Paul.
On Wed, Jan 27, 2010 at 8:32 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
On 01/27/2010 01:25 PM, Stefan Dösinger wrote:
It would help a lot if the code from last years gsoc d3dx9 projects made it into wine git sooner rather than later to allow new participants to build on it. I don't know what the state of Tony's work is, but I think the only real concern blocking the assembler is splitting up the patches, a few commends and compatibility with older flex versions(what happened to that? Did Alexandre raise the minimum flex version needed to build wine?)
Not sure how new it is, but it looks like 2.5.33 is the minimum:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce30733337e55d76c3870f...
-- Cheers,
Paul.
Hello, The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is installed from ports. # flex --version flex version 2.5.4 The version check passes on Linux and OpenSolaris but FreeBSD has a harder time with it. Gerald has a workaround for this.. Shall I call it a bug? since a newer version is actually installed but the version check fails. http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/wine/Makefile?rev=1.32... But if you download the Wine source and try to compile your out of luck unless you remove the version check from configure, which is what Ive done as a temporary fix. Tom
Tom Wickline wrote:
On Wed, Jan 27, 2010 at 8:32 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
Not sure how new it is, but it looks like 2.5.33 is the minimum:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce30733337e55d76c3870f...
-- Cheers,
Paul.
The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is installed from ports.
# flex --version flex version 2.5.4 Tom, that is the prediluvian flex version. 2.5.35 is way newer than 2.5.4
The version check passes on Linux and OpenSolaris but FreeBSD has a harder time with it. If your flex --version returns 2.5.4 than it is too old.
Gerald has a workaround for this.. Shall I call it a bug? since a The configure check doesn't checks the version number but a functionality that was implemented after 2.5.4. If that check fails on FreeBSD it means the flex version is too old.
newer version is actually installed but the version check fails.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/wine/Makefile?rev=1.32...
But if you download the Wine source and try to compile your out of luck unless you remove the version check from configure, which is what Ive done as a temporary fix. That doesn't make much sense as the Wine compilation should fail as the configure check uses a flex feature used in Wine from the commit e470475151692bd498124f1d3a7e2fca4be9092a. That is in wpp so it should die pretty soon during the build.
bye michael
On Wed, Jan 27, 2010 at 8:36 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
Tom Wickline wrote:
On Wed, Jan 27, 2010 at 8:32 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote:
Not sure how new it is, but it looks like 2.5.33 is the minimum:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=ce30733337e55d76c3870f...
-- Cheers,
Paul.
The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is installed from ports.
# flex --version flex version 2.5.4 Tom, that is the prediluvian flex version. 2.5.35 is way newer than 2.5.4
FreeBSD/PC-BSD should be bundling a newer version. When I compiled on BSD the other day I hit this, but I compiled flex from source and installed that instead. It only takes a few minutes... -- -Austin
On Wed, 27 Jan 2010, Tom Wickline wrote:
The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is installed from ports.
# flex --version flex version 2.5.4
The version check passes on Linux and OpenSolaris but FreeBSD has a harder time with it.
Gerald has a workaround for this.. Shall I call it a bug? since a newer version is actually installed but the version check fails.
It's not a bug in Wine or Wine's configure scripts. What happens on your system, or any "standard" FreeBSD system with the flex package installed is that the default path has /usr/bin before /usr/local/bin, so /usr/bin/flex which is 2.5.4 (as per your example) is found before, or should I say: instead, /usr/local/bin/flex which is the good one.
But if you download the Wine source and try to compile your out of luck unless you remove the version check from configure, which is what Ive done as a temporary fix.
Real fixes are setting your path to take /usr/local/bin before /usr/bin or probably better setting FLEX=/usr/local/bin/flex in your environment which tells configure and other tools to use that version of flex instead of the one in the base system. I would not recommend Wine trying to second guess which of several versions of flex on a system to use as opposed to following the common standard of use the first instance in the search path. I hope this makes sense? Gerald -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
On Thu, Jan 28, 2010 at 7:03 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote:
On Wed, 27 Jan 2010, Tom Wickline wrote:
The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is installed from ports.
# flex --version flex version 2.5.4
The version check passes on Linux and OpenSolaris but FreeBSD has a harder time with it.
Gerald has a workaround for this.. Shall I call it a bug? since a newer version is actually installed but the version check fails.
It's not a bug in Wine or Wine's configure scripts. What happens on your system, or any "standard" FreeBSD system with the flex package installed is that the default path has /usr/bin before /usr/local/bin, so /usr/bin/flex which is 2.5.4 (as per your example) is found before, or should I say: instead, /usr/local/bin/flex which is the good one.
Right. But it's a bug in the sense that FreeBSD is shipping an _extremely_ old version of flex ;-). Can you put in a request to update flex for FreeBSD 8.1/9.0? Or should I register/file a bug? -- -Austin
On Fri, 29 Jan 2010, Austin English wrote:
Right. But it's a bug in the sense that FreeBSD is shipping an _extremely_ old version of flex ;-).
True.
Can you put in a request to update flex for FreeBSD 8.1/9.0? Or should I register/file a bug?
Filing a request is fine, if you want to do so. Just don't hold your breath, there is a lot of FUD around GPLv3 in BSD-land¹ and anything with a GPLv3 license in the base system will need core (team) approval and a heck of a lot of a reason. Gerald ¹ Personally I do agree that GPLv3 was not very helpful, alas it's not the end of the world, either.
On Fri, Jan 29, 2010 at 1:44 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote:
On Fri, 29 Jan 2010, Austin English wrote:
Right. But it's a bug in the sense that FreeBSD is shipping an _extremely_ old version of flex ;-).
True.
Can you put in a request to update flex for FreeBSD 8.1/9.0? Or should I register/file a bug?
Filing a request is fine, if you want to do so. Just don't hold your breath, there is a lot of FUD around GPLv3 in BSD-land¹ and anything with a GPLv3 license in the base system will need core (team) approval and a heck of a lot of a reason.
Flex isn't GLPv3, it's got a BSD license: http://flex.sourceforge.net/manual/Copyright.html#Copyright Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED “AS IS” AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. -- -Austin
On Fri, 29 Jan 2010, Austin English wrote:
Flex isn't GLPv3, it's got a BSD license: http://flex.sourceforge.net/manual/Copyright.html#Copyright
You're right, and I had actually checked that a few weeks ago and confused it with something else now. Excellent. Please do file a PR against FreeBSD and let me know the number off-list. I may have an idea... :-) Gerald
Stefan Dösinger wrote:
Am 27.01.2010 um 13:16 schrieb Henri Verbeet:
On 27 January 2010 12:57, Tony Wasserka <tony.wasserka(a)freenet.de> wrote:
at the msdn documentation to see the whole list of interfaces. I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures. I'm not sure I'm sure the effect interface would be useful to implement, but aside from probably having a dependency on the HLSL compiler, it's probably just too hard. 2 or 3 months really isn't a whole lot of time either. It would help a lot if the code from last years gsoc d3dx9 projects made it into wine git sooner rather than later to allow new participants to build on it. I don't know what the state of Tony's work is, but I think the only real concern blocking the assembler is splitting up the patches, a few commends and compatibility with older flex versions(what happened to that? Did Alexandre raise the minimum flex version needed to build wine?) The "flex police" did; he just accepted that patch eagerly ;)
bye michael
Thanks everybody for the replies.
Welcome! I'm glad you've chosen Wine; we can sure use more help.
Sounds like you know your way around, but please feel free to ask for help anytime. The IRC channel works particularly well; real discussions will keep us from being annoyed by the trolls.
Note that there are a few caustic folks; please don't let sharp comments from any of them discourage you.
Overall, I like to think that we're the friendliest large open source development community out there. Of course, that is a bit like saying that we're the friendliest and nicest pit viper :-), but still...
Haha, yea, I know the game. Never had too much of a problem with those sorts of people.
I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures.
That sounds interesting, I'd be willing to give it a shot. @Henri: I'm always up for a challenge. Perhaps you could suggest a smaller subset of the problem that would be more feasible to attempt in 2-3 months? Perhaps a few effects rather than any significant chunk of them? Also, what are you looking for in a proposal? Here's the wiki for the problem I mentioned in my first post: http://wiki.winehq.org/DirectX-D3DX9 . What's the current status on this proposal? It sounds like a fairly major problem. @Tony: I'm not sure I followed the subsequent discussion. Has your work been incorporated into wine-git yet, or is that still pending? Thanks again guys. And as before, all suggestions are appreciated! --- Arjun Comar, Rose-Hulman '12
hi arjun, it's good to see your interest :) tony has been searching for someone to integrate his gsoc work, see: http://www.winehq.org/pipermail/wine-devel/2010-January/081160.html maybe you are that guy? ;) it would serve as an introduction to the d3d environment at least. maybe too much idk. if you have questions you can hang around #winehackers , we are there alot. 2010/1/27 Arjun Comar <mandaya(a)rose-hulman.edu>:
Thanks everybody for the replies.
Welcome! I'm glad you've chosen Wine; we can sure use more help.
Sounds like you know your way around, but please feel free to ask for help anytime. The IRC channel works particularly well; real discussions will keep us from being annoyed by the trolls.
Note that there are a few caustic folks; please don't let sharp comments from any of them discourage you.
Overall, I like to think that we're the friendliest large open source development community out there. Of course, that is a bit like saying that we're the friendliest and nicest pit viper :-), but still...
Haha, yea, I know the game. Never had too much of a problem with those sorts of people.
I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures.
That sounds interesting, I'd be willing to give it a shot. @Henri: I'm always up for a challenge. Perhaps you could suggest a smaller subset of the problem that would be more feasible to attempt in 2-3 months? Perhaps a few effects rather than any significant chunk of them? Also, what are you looking for in a proposal?
Here's the wiki for the problem I mentioned in my first post: http://wiki.winehq.org/DirectX-D3DX9 . What's the current status on this proposal? It sounds like a fairly major problem.
@Tony: I'm not sure I followed the subsequent discussion. Has your work been incorporated into wine-git yet, or is that still pending?
Thanks again guys. And as before, all suggestions are appreciated!
--- Arjun Comar, Rose-Hulman '12
That sounds interesting, and may be a good way to learn. I'll CC this reply to him to see if he still needs somebody. @Tony: It'd be slow going since I still need to learn how everything works, but if you're willing to work with me, I don't mind helping you out with your project. On Wed, Jan 27, 2010 at 2:34 PM, Ricardo Filipe <ricardojdfilipe(a)gmail.com>wrote:
hi arjun, it's good to see your interest :)
tony has been searching for someone to integrate his gsoc work, see: http://www.winehq.org/pipermail/wine-devel/2010-January/081160.html
maybe you are that guy? ;) it would serve as an introduction to the d3d environment at least. maybe too much idk.
if you have questions you can hang around #winehackers , we are there alot.
2010/1/27 Arjun Comar <mandaya(a)rose-hulman.edu>:
Thanks everybody for the replies.
Welcome! I'm glad you've chosen Wine; we can sure use more help.
Sounds like you know your way around, but please feel free to ask for help anytime. The IRC channel works particularly well; real discussions will keep us from being annoyed by the trolls.
Note that there are a few caustic folks; please don't let sharp comments from any of them discourage you.
Overall, I like to think that we're the friendliest large open source development community out there. Of course, that is a bit like saying that we're the friendliest and nicest pit viper :-), but still...
Haha, yea, I know the game. Never had too much of a problem with those sorts of people.
I guess the most profitable would be implementing the effect interfaces, since these are the most used ones next to shaders and textures.
That sounds interesting, I'd be willing to give it a shot. @Henri: I'm always up for a challenge. Perhaps you could suggest a smaller subset of the problem that would be more feasible to attempt in 2-3 months? Perhaps a few effects rather than any significant chunk of them? Also, what are you looking for in a proposal?
Here's the wiki for the problem I mentioned in my first post: http://wiki.winehq.org/DirectX-D3DX9 . What's the current status on this proposal? It sounds like a fairly major problem.
@Tony: I'm not sure I followed the subsequent discussion. Has your work been incorporated into wine-git yet, or is that still pending?
Thanks again guys. And as before, all suggestions are appreciated!
--- Arjun Comar, Rose-Hulman '12
--- Arjun Comar, Rose-Hulman '12
On 27 January 2010 20:14, Arjun Comar <mandaya(a)rose-hulman.edu> wrote:
@Henri: I'm always up for a challenge. Perhaps you could suggest a smaller subset of the problem that would be more feasible to attempt in 2-3 months? Perhaps a few effects rather than any significant chunk of them? Also, what are you looking for in a proposal?
Here's the wiki for the problem I mentioned in my first post: http://wiki.winehq.org/DirectX-D3DX9 . What's the current status on this proposal? It sounds like a fairly major problem.
The problem with the effect interface is that there are several fairly large parts/dependencies to implement. For example, it has important dependencies on both the (non-existent) HLSL compiler and the only partially merged shader assembler, needs to compile text effects into the (AFAIK) undocumented binary effect format and read that same binary format, and then render those effects in an efficient way. We'd certainly welcome work in this area, but it's a pretty large thing to implement with plenty of unknowns. My personal opinion is that you'd want something that's at least reasonably well defined in terms of what it would take to complete for a Summer of Code project. If you're looking for a subset of the effect interface, the thing that most applications will likely need is the part that does parsing of binary effects and rendering those. It would help if you found an actual application or set of demos that uses those interfaces though. An added advantage would be that you'd get an idea of how those interfaces are used in practice. As for what I'd look for in a proposal, an important part would be if the proposal is realistic in a technical sense, but also if it's possible to complete in that time span. Other considerations would be if the proposal is useful in the first place, and whether I get the impression that the author knows what he's talking about. Note that if you're a first time contributor to Wine, there's a significant chance that you'll spend quite some time working out process issues like setting up a proper build environment, learning to work with git effectively, submitting proper patches, etc. It would improve your chances of successfully completing the project quite a bit if you can get all that worked out before starting the project, by fixing a small bug or making an improvement somewhere in Wine and getting that patch committed. Perhaps students from previous years can also comment on this. I'd be careful with things like cleaning up and submitting projects from previous years. In principle that's a useful thing to do, but due to the nature of the project, Wine cares pretty strongly about things like authorship information. For this reason it's *strongly* preferred that the original author submits a patch. It does happen that people submit patches for someone else, but it's pretty rare, and usually by more established rather than new contributors.
On Wednesday 27 January 2010 23:41:27 Henri Verbeet wrote:
The problem with the effect interface is that there are several fairly large parts/dependencies to implement. For example, it has important dependencies on both the (non-existent) HLSL compiler and the only partially merged shader assembler There's another problem with any d3dx9 project: You cannot test a small subset of D3DX9 with any real-word game if the rest of the library is missing because no games use only the event interface or use only the assembler etc.
Matteo faced this issue - there was no game that used the assembler, but didn't use some of the Font or Texture loading code Tony was working on. This meant he could only test with test cases written himself and had no success moment when a real game started working without native d3dx9 thanks to his work. So before any further d3dx9 projects have a realistic chance at succeeding we need the existing code merged. If necessary I can pick up Matteo's patches, split them up and send them in, although it would be preferable if Matteo could do this himself.
2010/1/28 Stefan Dösinger <stefandoesinger(a)gmx.at>:
On Wednesday 27 January 2010 23:41:27 Henri Verbeet wrote:
The problem with the effect interface is that there are several fairly large parts/dependencies to implement. For example, it has important dependencies on both the (non-existent) HLSL compiler and the only partially merged shader assembler There's another problem with any d3dx9 project: You cannot test a small subset of D3DX9 with any real-word game if the rest of the library is missing because no games use only the event interface or use only the assembler etc.
Matteo faced this issue - there was no game that used the assembler, but didn't use some of the Font or Texture loading code Tony was working on. This meant he could only test with test cases written himself and had no success moment when a real game started working without native d3dx9 thanks to his work.
Yes, that's a relevant issue. I didn't find a single game, or even DirectX SDK sample, which needed only the shader assembler functions and not also some other unimplemented part of d3dx9 (expecially the texture functions are often used). This essentially means that you'd have to rely only on conformance tests to have some measure of correctness of your code (and fidelity to the behavior of native implementation), at least in the short to medium period.
So before any further d3dx9 projects have a realistic chance at succeeding we need the existing code merged. If necessary I can pick up Matteo's patches, split them up and send them in, although it would be preferable if Matteo could do this himself.
I have pretty much splitted the patches up in reasonable enough (I believe) pieces, now I just need to address the things Henri noticed last time I sent the main patches. That's not much to fix, but these days I'm really busy. Hopefully in some days I could dedicate some time to this.
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 ;) Matteo Bruni wrote:
Yes, that's a relevant issue. I didn't find a single game, or even DirectX SDK sample, which needed only the shader assembler functions and not also some other unimplemented part of d3dx9 (expecially the texture functions are often used). This essentially means that you'd have to rely only on conformance tests to have some measure of correctness of your code (and fidelity to the behavior of native implementation), at least in the short to medium period.
One of my main goals was to get some DirectX SDK samples running in Wine. During SoC, several factors pretended that, so I had to change my goal: I compiled the SDK samples in Windows using MSVC, but replacing all D3DXCreateTextureFromFile (etc) calls with my own implementations, that way I could easily check whether my code works in real-world scenarios without depending on other D3DX code. Of course, that won't work for closed source apps, but the DX SDK samples are a pretty good starting point as well. In fact, a combination of texture code, font code, shader code and effect code would probably cover many of the DX SDK samples already. Too bad they'd still require msvc++ (i.e. they don't compile with winelib) and safe string functions (which we don't have implemented) then... Henri: I'm not sure whether the D3DX9 interface _depends_ on the HLSL compiler; maybe the bytecode effect compiler does, but there's plenty of stuff the effect interface can do without shaders (on the other hand, maybe the interfaces are using shaders internally, but I think state blocks should be enough to do this stuff). I'm not really sure either whether the effect area is doable in GSoC's timeline; maybe a part of it (if that'd be usuable at all), otoh maybe it's not that hard in the end though... That should be checked before of course. I'll have to hand in a paper tomorrow, so I'll be busy for the rest of this evening, I could maybe take a look at that tomorrow. Best regards, Tony
2010/1/28 Tony Wasserka <tony.wasserka(a)freenet.de>:
Henri: I'm not sure whether the D3DX9 interface _depends_ on the HLSL compiler; maybe the bytecode effect compiler does, but there's plenty of
The effect compiler does, you can use embedded HLSL or assembly in effects. You can skip implementing the compiler of course, but that's a significant part of D3DX9 effects.
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: essen(a)dev-extend.eu web: http://dev-extend.eu
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. Arjun On Thu, Jan 28, 2010 at 1:46 PM, Loïc Hoguin <essen(a)dev-extend.eu> wrote:
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: essen(a)dev-extend.eu web: http://dev-extend.eu
-- Arjun Comar, Rose-Hulman '12
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: essen(a)dev-extend.eu web: http://dev-extend.eu
On 28 January 2010 20:15, Arjun Comar <mandaya(a)rose-hulman.edu> 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.
On 01/28/2010 09:25 PM, Henri Verbeet wrote:
On 28 January 2010 20:15, Arjun Comar <mandaya(a)rose-hulman.edu> 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: essen(a)dev-extend.eu web: http://dev-extend.eu
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.
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: essen(a)dev-extend.eu web: http://dev-extend.eu
Am 28.01.2010 19:46, schrieb Loïc Hoguin:
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.
Not sure whether integration of my work is still worth a whole SoC, but why not.
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
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.
I don't think I have a game that uses the mesh code so, sorry, I have no interest about that.
Yeah, meshes are handled internally most times, but they were neccessary for the DX SDK samples, in the first place. Best regards, Tony
On 28 January 2010 19:25, Tony Wasserka <tony.wasserka(a)freenet.de> 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.
There is already support for WIC codecs by Vincent Povirk that has been committed into wine, supporting bmp, jpeg, gif, png and other formats. I don't know how complete this is, though, for what D3DX needs. - Reece
Am 28.01.2010 20:38, schrieb Reece Dunn:
There is already support for WIC codecs by Vincent Povirk that has been committed into wine, supporting bmp, jpeg, gif, png and other formats.
I don't know how complete this is, though, for what D3DX needs.
- Reece
yeah, the plan was to use WIC and my code actually already does that. That way D3DX9 supports [in my branch] BMP, JPEG, PNG and DDS files, but there are a few more formats whose codecs need to be written from scratch.
participants (13)
-
Arjun Comar -
Austin English -
Gerald Pfeifer -
Henri Verbeet -
Loïc Hoguin -
Matteo Bruni -
Michael Stefaniuc -
Paul Vriens -
Reece Dunn -
Ricardo Filipe -
Stefan Dösinger -
Tom Wickline -
Tony Wasserka