Batman: Arkham Asylum Demo and its amazing Nvidia ONLY MSAA technology!

Please show us all a quote where I said that this was the rule.

No SirPauly, I'm hoping it does NOT become commonplace. But if Nvidia gets away with it without comment from the press or consumers, what reason would they have to not do so again? and again?

That is how an exception becomes the rule.

Very mature.

 

Guys, obviously dialogue has continuted post these mails.

 

Obviously, since it was over a month ago, however unless someone is willing to disclose further emails or information, this is all we have to go on. If AMD can supply more information then urge them to, otherwise all we have is a month of silence and inaction, then a comment from AMD on a forum that doesn't provide anything new and is just in respond to Nv shit-slinging.

 

Just look at Kane and Lynch for an example of how Edios works. It may not be as simple as "giving them the code."

 

I may own and use as much NV hardware as just about anyone I know, between a 9600 GT, 8800 GT, 8800 GTS 512 volt modded, and an o/c'd XFX GTX 285. I am by no means a shill or a corporate loyalist. I do not agree with NV's tactics in this situation. Everyone knows ATi hardware can run MSAA in UE3 games, especially their newest stuff.

 

That is right, but then ATI/AMD needs to show that. There is simply no reason for the huge uproar given the evidence that AMD has put forward. They should at least send this "standard" code over so they can lay the blame at Eidos' feet for inaction (pressured or not from nvidia) instead of complaining. Then everyone can get in a tizzy about why Eidos did not put the code in that AMD sent and validated to work correctly in the game. Until that happens it is just whinging. What happened to the good old days when developers were competent to write their own code

And btw if we have to talk about hardware in our posts I have certainly owned more ATI cards than Nvidia cards b/c they were better value propositions for me at the time of purchase. I only owned ATI cards (except for a cheapo geforce 6200 I modded and gave to someone else) from the 9x series all the way to last spring when I got a 8800. I think the grass is often greener on the other side though as they say (meaning you notice the things that annoy you about the card you have more than the one you don't have).

 

Sxotty, didn't AMD according to reports offer their own code instead (which, as being standard DX, was same as nVidias minus the vendor id check), which was refused?

 

When I do patches of third party code, I often put these kinds of 'locks' around the code not because I truly want to lock out third party hardware, but because I don't want to be responsible for breaking the app on hardware I don't certify/test/validate for.

Think about this scenario: Big new AAA title coming out. I offer "standards patch" with no checks, and it works on my hardware, but causes crashes/artifacts/etc on some other HW due to driver bugs or HW problems. Now my ass is on the line for causing all of this extra work for the developers from my 'free' "standards patch"

There is no such thing as a fire-and-forget "standards patch". You have to test on EVERYTHING, and that is not the responsibility of some level4 staff engineer of NVidia to commit resources to validating for all third party cards. It's EIDOS's responsibility at best, AMD's at worst.

Long story short, when you patch code you don't own, it is best to be as conservative as possible to limit collateral damage.

Now, could PR/marketing types love the implicit advantage this gives NV? You betcha, but I wouldn't assume that the patch started out this way. The engineers typically do things for legitimate technical reasons and only do "evil" stuff if very explicitly commanded to do it. This patch lock could have started out as a simple "I don't want to fuckup Batman on all kinds of shit, so I'm going to patch this to work on the few cards I have access to and limit it so I don't have to worry", and later transmogrified into (PR person) "Muahaha, we can market this as Batman has better AA too! It's a win-win!"

 

Presented that point - with a few others as a possibility in another forum and makes a lot of sense; nVidia coded and supported it for nVidia and if this would of broken something on ATI hardware -- for whatever reason -- all hell would of broke loose on that as well. nVidia sabotaged AMD systems -- hahahaha with evil intent to control the world and hates the consumer. It was dismissed and nVidia is evil and doesn't care.

In an ideal sense, you would like to see in-game AA not being being political in late 2009 considering where in DirectX 11 now but this was a port that is based on DirectX 9 using the Unreal engine. There is a lot of grey and some seem to be trying to make it right or wrong or black and white.

I am sure there is a blame pie and the slices can be made up of the Unreal engine, developers, nVidia and ATI --- and it does suck that AA is in the political fore-front and maybe ATI does have a beef, too.

 

Unfortunately, it doesn't seem clear exactly what has been offered or what code has been written by AMD.

I presume that sorting out AA code using the standard DX API would be a reasonably straightforward process for a competent coder? This being the case, you'd think that AMD would simply get one of their many software engineers to write such code then provide it to the developers to test and include in a patch as soon as possible. If the developers refused to do this or dragged their feet then I can imagine why the AMD folks might get a bit irritated and then bring it into the public eye. Is this what is happening now?

To me, it would seem to be rather too machiavellian to assume that AMD are bringing this argument out into the open simply trying to make NVidia look bad if they haven't actually provided the code in the first place. Perhaps I'm wrong, though?

To be honest I don't see how Huddy's comments about having the ability (though not the inclination) to lock out Fermi for certain DX11 stuff are helpful at all.

On the other hand, I can see how it would be in NVidia's interests to cheekily claim IP for the AA code if for no other reason to make things more tricky for AMD to provide AA support.

Ultimately, I wonder if the problem is because the developer or the publisher doesn't have either the common sense or the gumption to take a stand and do their best to include proper AA support for all their customers. The interchange in e-mails between Eidos and Huddy published on BSN would indicate that somebody, somewhere isn't certain of what is actually going on here, even if it is Eidos' legal department!

 

Did this title fall under the NV branding TWIWMTBP (or whatever it is)?

 

Why is it necessary for ATi to send the developer the same code code that's already present in the game? Batman:AA MSAA works just fine on ATi cards if you remove the Vendor ID block. Really, how hard is it to delete the line that compares Vendor ID?

Does this mean that if S3 and Matrox want AA working on their cards that they would have to send in more copies of the code with the Vendor ID removed? How many copies of it does the developer need?

Just let it work on everybody's card, the same as it has always been up until this point.

 

Yes, but just about every game does these days.

 

Well, I guess we'll cross that bridge if it ever happens. In this instance, however, it was a deliberate action taken by Nvidia to lock out AA from ATi cards.

What is so grey about a Vendor ID lockout? You can't get much more black and white than that.

Why do you keep trying to bring ATi into the blame picture? Nvidia is mostly at fault for putting the block in there, the developer is partially at fault for allowing it. ATi and us, the consumers, are the ones being harmed here.

 

You've got to ask yourself why the vendor-id lockout hasn't been removed given that AMD has done the testing and qualification and says this is all that is needed and that there are no issue on their hardware. There must be some other reason, and it seems that is Nvidia not allowing Eidos to change their code, hence the Eidos legal team stopping the Rocksteady devs from removing the lockout.

As it is, the standard code given by Nvidia has a detrimental effect on ATI hardware, both in performing the first half of the AA pass whilst not getting any benefit from it, and leaving the only alternative applying AA to the whole scene instead of selectively, so yes, the Nvidia code is deliberately detrimental to ATI hardware - or should I say to consumers who own ATI hardware.

 

It's hard to have a conversation when ATI has no blame in this and you can't see how "out of the ordinary" this example is.

 

Detrimental effect? Meaning forced AA?

 

No, I quote:

 

Do you have performance numbers of Batman with no AA with the lock out and without?

Will investigate myself.

 

There was a site that compared CP AA and vendor-lock bypass AA, not sure if they did without AA though. I can't find that site link at the moment though sorry, I'm sure it's buried in this thread somewhere. Would be interesting to see if there is a noticeable change using Nv vendor-id but with no AA.