WINE 1.1.21 Starts On Shader Model 4 Support

[whizse]

Lets test Zero Ballistics or gl2benchmark on it. I never saw gl2benchmark running on oss drivers. Well I do not own a G965, but even a G35/Q35 which seems relatively similar does not support it.

Heh, for Zero Ballistics this would be bug #14448.

[deanjo]

this is why they dont let me do textures

Heh, I thought it looked very realistic

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 *

That is what wine more or less started out to do in the beginning. As time went on though users asked for game support. Besides alot of the current applications have many of the same library requirements as the games now as well. If you go back and look at the criteria they set out to finally say it reached 1.0 status you would notice that almost all the emphasis was on getting key applications working and not games.

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.

[Kano]

Well ZB has got Linux native binaries, but if you like use wine for it.

[whizse]

Well ZB has got Linux native binaries, but if you like use wine for it.

I don't run ZB with Wine, but it triggers the same bug. Noone has gotten around to updating the title of the bug report.

[remm]

lol, 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.

Ok, 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 ?

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

[NeoBrain]

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

The support question you find at the pulseaudio backend is just one point about using G3D in Wine. Basically, it's not easy to "simply add" another graphics backend, so we'd need to completely replace the currently working quite good (apart from the glitches) with one that'll be broken for most things for the next few years (just like our current graphics stack...).
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.

[whizse]

Ok, 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 ?

Adding pulse to Wine would probably also mean that the esd backend could be replaced. I very much doubt there's anyone prefering to use esd over pulse anyway.

[remm]

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.

You 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).

[NeoBrain]

You 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).

I don't think that everyone likes to only get 50% of the performance he'd get with a binary driver (esp. if one pays 150 euros on it), so there will always be people who use fglrx. Apart from that, we have EVERYONE using NVIDIA graphics cards, who are forced to use their binary blob (and please don't point me to nouveau; it's stable and good and stuff, but it's 3D support is nowhere near to even working for bigger games).
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.

[whizse]

Kano, if you're interested, it's now possible to run Zero Ballistics using Mesa. This is what it looks like:



Possible to run, but not really playable still, it's a little bit of progress.

I filed bug 21783 about this.