Announcement
Collapse
No announcement yet.
WINE 1.1.21 Starts On Shader Model 4 Support
Collapse
X
-
Originally posted by L33F3R View Post
this is why they dont let me do textures
for real tho, what if wine only focused on generic desktop apps over attempting to keep up with games? i know wine isnt exactly an emulator but if we look at say... PS2 emulation. We cant hardly play PS2 games without top end machines and even that is a push. I understand the situation is different but the principal is the same. Its like trying to turn a torx screw with a flat head screwdriver - eventually you might get it but your screw is going to blow and its going to take a long time.
Wine looks pleasing on paper but its a curse overall, much like my ex girlfriend.
*gets ready for terror *
Nobody sane accuses bleem, dosbox, pearpc, mame, <insert favorite emulator>, etc etc for lack of ports for other platforms but somehow the wine guys have to face that BS accusation everyday.Last edited by deanjo; 10 May 2009, 09:56 PM.
Comment
-
Originally posted by deanjo View Postlol, have you even bothered to do a bug search on pulse or look at it's changlogs, and it's a project far less complex then what pulse is trying to accomplish.
The person is providing the patch, and regularly updates it. The patch is included downsteam in Fedora, with no problems. You say you are not including it because you'd have to support it, but actually Wine support for most "supported" sound systems is non existent, so what difference would it make other than landing you an additional contributor ?
Then it will be the same for any graphics overhaul, apparently. Exactly why is it nice to do something like:
DX 9 wrapper -> Wine3D -> OpenGL -> DRI driver -> graphics card
rather than:
DX 9 state tracker -> Gallium driver -> graphics card
If some people show up with that, I suppose they will be handled the same as the guy above
Comment
-
Originally posted by remm View PostThen it will be the same for any graphics overhaul, apparently. Exactly why is it nice to do something like:
DX 9 wrapper -> Wine3D -> OpenGL -> DRI driver -> graphics card
rather than:
DX 9 state tracker -> Gallium driver -> graphics card
If some people show up with that, I suppose they will be handled the same as the guy above
Another reason was that Gallium doesn't run on Macs or BSD, so we'd need to maintain the "old-fashioned" backend anyways for portability (especially since binary drivers don't support G3D either).
Generally speaking is one of the hardest part of reimplementing Direct3D the "little details" that need to be taken care of. A G3D driver would have to deal with these ones, too, so we wouldn't gain anything from it. Investing time in fixing current bugs in Wine is much more effective IMO.
By the way, you're oversimplificating (does that word exist?) the G3D pipeline a bit. We'll still need a wrapper around the Direct3D state tracker, as the Direct3D API isn't compatible with Linux. Also, WineD3D supports everything from (at least) Direct3D 7 to Direct3D 9 (10?). The Direct3D state tracker will need the same level of abstraction as we have it today.
Comment
-
Originally posted by remm View PostOk, let's get into specific stuff then: http://bugs.winehq.org/show_bug.cgi?id=10495
The person is providing the patch, and regularly updates it. The patch is included downsteam in Fedora, with no problems. You say you are not including it because you'd have to support it, but actually Wine support for most "supported" sound systems is non existent, so what difference would it make other than landing you an additional contributor ?
Comment
-
Originally posted by NeoBrain View PostBy the way, you're oversimplificating (does that word exist?) the G3D pipeline a bit. We'll still need a wrapper around the Direct3D state tracker, as the Direct3D API isn't compatible with Linux. Also, WineD3D supports everything from (at least) Direct3D 7 to Direct3D 9 (10?). The Direct3D state tracker will need the same level of abstraction as we have it today.
It also seems you put a lot of emphasis to porting to proprietary platforms. Great, but I am not interested ... You should see what your users are, I think. And hopefully plan for the next gen free desktop rather than try to fight it (at which point I think they won't care and will use virtualzation instead, which I assume will have decent 3D support by then).
Comment
-
Originally posted by remm View PostYou could move to a Vista solution: do DirectX 10, and do the old versions on top of that. That's what they do, right ?
It also seems you put a lot of emphasis to porting to proprietary platforms. Great, but I am not interested ... You should see what your users are, I think. And hopefully plan for the next gen free desktop rather than try to fight it (at which point I think they won't care and will use virtualzation instead, which I assume will have decent 3D support by then).
About implementing DX 7/8/9 with DX 10, it would be the same again as implementing a DirectX state tracker. Microsoft was only able to do that because they have WAY more employees to do that job, whereas we have "only" got a dozen of people working on D3D stuff.
As a side note, support for OSS drivers (i.e. radeon) in Wine is comming along at the moment; I don't know the specifics about what else is missing to make them work, but starting with GLSL support in radeon was definetely a huge step forward.
Comment
Comment