The problem is that the directx binaries on Windows have become the most wart ridden messes of unexplained undocumented behavior implementing the api intuitively means almost nothing works.
Originally Posted by werfu
Microsoft had the habit (and still does) of patching Windows to fix bugs in games. Device vendors do this a lot too, it is why many AAA titles require day-one gpu drivers from AMD / Nvidia.
Wine is so huge, in part, because it has to find and implement all the bugs in directx beyond just the functionality. And even a dx9 state tracker would have to do the same, because directx isn't an API, it is an implementation - and as a developer, conforming to implementations makes me want to perform ritual sacrifice of goats.
No reason I can see that it wouldn't, so long as it's using an up-to-date Mesa stack. As this state tracker looks to be Mesa 10 I would imagine that you would get everything you get from Mesa 10 (including all radeonsi improvements) plus the D3D9 st.
Originally Posted by ChrisXY
Are you trying to make a point, or promote NVIDIA's proprietary driver? I fail to see any reason for the latter in this thread...
Originally Posted by pinguinpc
My only problem with fglrx and Wine was Guild Wars 2 and osu!, and both seem to work great for me now. On radeonsi, both games also worked, but were slightly slower. Can't say I care how they perform on NVIDIA since I don't own such hardware (and won't for political reasons). But giving the impression Wine is next to useless on AMD in-comparison to NVIDIA just isn't true.
LOL. Yeah rite... So Wine has to do all these things? Maybe they need to hire more people for their marketing division based on this patch? Maybe they need more salesmen? Gosh, the burden...
Originally Posted by Gusar
I can't take you seriously. You see, unlike you, i am a pro programmer... And i know lies when i see them...
They don't have to. Anyway, it is not like the do stellar QA for the rest of Wine...
Originally Posted by zxy_thf
But, they don't have to enable it by default. They can just accept it, provide a compile time option, and let the community maintain it. But of course, that can't happen on an "open source" project, right?
So let me get this straight: If i have not given money to the developers, i am not allowed to review their product and criticize their decisions? Especially an "opensource" product? SERIOUSLY? I don't know if you are a developer, but you don't seem too bright to me...
Originally Posted by justmy2cents
I never said i don't like Wine in general. I don't like the attitude of Crossover employees... That is my right, and i can express it since we are not in N. Korea...
Their decision is purely based on the fact that most of their money come from Mac users. I am willing to bet Linux users don't usually pay for Crossover... That is the reason they don't want Linux specific enhancements. There is no technical reason, this patch is so simple. If it was complicated, i might have accepted their argument. But is is so simple...
PS: They won't get that much "bug noise" from supporting the d3d9 state tracker. They don't have to enable it in Crossover. They can let it as an unsupported Linux compile time feature...
criticize? yea, you can. that is your basic right. same as developers have the right of choice... or don't they? you damn sure fight for your rights, but deny basic right to others. right of choice is most basic part of OSS. but, what you're doing is not criticizing. example, "wine developers LIED...", i mean how can you lie that you don't like something and don't plan on supporting it? it was a CHOICE, not a CLAIM and AFAIK choice cannot be lie. same for your comment, is not criticism, it is a claim
Originally Posted by TemplarGR
oss project rejecting inclusion? never happens... or does it? look at kernel. they will flat out reject inclusion if it doesn't fit in their plan or structure, their agreed writing style...
in OSS both developer and user are right. but
- developer has the right to decide on not accepting some solution into their project or take another direction
- user has the right to say screw them, fork and prove them wrong
not much noise? let's see http://appdb.winehq.org/objectManage...tion&iId=13667
right now it is pretty decent and clean how versions work. imagine all this duplicated since it might run for someone with tracker and not for someone without. why would they need to go trough that if they don't want it? and this never happens, i guess http://www.phoronix.com/scan.php?pag...tem&px=MTMyNDU
even if you leave it outside.of crossover people usually simply write "wine appname" in google. now, go figure what articles one will saw. some random templargr bragging it works x fps. imagine the surprise when he installs it just to realize it doesn't work. what will they do the 1st thing... flood the wine support
keeping side project outside wine, where you simply take each tarball and release with patches would be painless, not require any work (your words, not mine). that's how distros do binary blobs for example
You're not "criticizing their decisions". You're making demands, you're throwing out accusations, hefty ones at that (they're "lying", seriously?), you're claiming they have an agenda, you're also throwing out insults and cheap shots at other forum participants, and you're doing it all with a really stinky attitude. All the while proclaiming how trivial supporting the tracker would be.
Originally Posted by TemplarGR
You're a "pro programmer", *show* me how trivial it would be! Why do you refuse? With one supposedly easy gesture you could shoot down my arguments completely. Why do you not take that chance? Well, the answer is obvious.
Lol, you do realise the main users of Wine are Linux users, right?
Originally Posted by werfu
And if adding something that "only the minority of Linux users will be able to use" is bad, then why did the Wine devs add that OSX specific X11 replacement some time ago?
Face it, it's all ego issue. Someone developed something such that the whole DX-GL translation layer can now be obsoleted, but the old Wine devs, who think more about their legacy than the actual benefit of users, want to keep this layer and reject any alternatives, even if they are clearly superior.