Dave-
It doesn't - thats their issue. I think these were the points they were trying to convey.
So Valve isn't trying to license this engine...? I was under the impression that they were but if you say they aren't then I guess that would make sense. They don't care about engine licensees at all, but if someone happens to be willing to work with that they have they can license it, I guess if that's what's going on it makes sense. So Gabe isn't going after Sweeney and Carmack.
Oldfart-
The way it went was nVidia uses 16 bit color for DXTC1, ATi uses 32 bit color.
It's not 16bit color, it's 16bit interpolation. S3TC works on compressing in a grid, it removes data out of the center of a square(to simplify it a bit). The creators of the technique and nVidia utilized 16bit accuracy to interpolate the data and extract the missing portions(again, a simplification). The original textures used were not 16bit color, nor were the textures ouputted 16bit color, they used 16bit interpolation to extract the data that was held inside the compressed information.
I forget the numbers, but it was something like 6:1 vs 3:1??
6:1 and 4:1.
Many claimed it was a Q3A bug
There was a particular issue with Quake3, they were compressing alpha textures and lightmaps. That should not be done on any hardware with S3TC, even ATi's image quality suffered too much due to this.
but they certainly had a bug/image quality issue that some of the nVidia fan base would not acknowledge
Following your logic the R8500 had a bug/image quality issue, it did not support FP24. The Radeon was even worse, it didn't even support PS1.0 or VS1.0. It also used fixed function T&L, relied on a crude method for EMCM and EMBM. Do you want to 'acknowledge' these bug/image quality issues? What about the Voodoo3 not supporting larger then 256x256 textures? Was that a bug or image quality issue? How about the Voodoo1's 800x600 resolution limit, was that a bug or image quality issue? You are talking about a feature that nV didn't have implemented. Some of the shaders Maya uses require FP32 support to render properly, does that mean the FireGL has a bug/image quality issue since they can't handle FP32? This is the same thing you are saying now. I would say that they were missing a
feature that nV had. But hey, what do I know, I'm just the biggest nVidiot on the net who for some strange reason was telling people to buy the Radeon over the GF2 back in those days......
BFG-
Uh no, you admitted that the static clip planes were a cheat, however you never admitted that the other seven cheats found by FutureMark were cheats, nor have you admitted that the other "optimisations" and questionable driver bugs in other games are cheats.
They cheated in 3DMark2K3, the reason I didn't address in particular the rest of the accusations is that you have a bunch of them lumped together in a take it or leave it fashion.
You were not only claiming that shader subsitution (which was in my list) was a driver bug, you also later tried lump it into the compilation process to claim it was normal when in reality in was being modified at runtime, something that isn't normal by any stretch of the imagination.
You claim nV uses shader replacement all over the place, that I take issue with. I never said that they didn't use shader replacement under 3DMark2K3, I only commented that ATi did the
same thing. You want to bash nVidia on that one you better bash ATi too.
The sole purpose of such an action is to defeat any applications that expose driver cheating so again I'll ask the question, why go to such trouble to implement something that according to you isn't needed?
You familiar with Linux at all? You know how they have two different batch of drivers, one of them is open source and seriously limits functionality while the other is proprietary and closed and has full funtionality. Why do they do that? Because they don't want people to be able to take a close look at their architecture which the drivers would give a good glimpse in to. Now they are at the point where they are working on a compiler for their hardware that would likely expose a great deal of detail in to how their shader architecture works in great detail. By trying to encrypt the information as much as possible they reduce the odds of anyone being able to reverse engineer it and use the information to gather insight in to their design. Now if nVidia had always been open with their driver architecture I would say that this line of thought was a stretch, but they have always been very protective of their drivers much to the dismay of the Linux community.
Because there was both a performance gain and less texture swapping in Quake III when DXT1 was used instead of DXT3.
6:1 v 4:1 compression, of course memory useage changed.
So they both sucked ass and couldn't really be compared to the other vendors using 32 bits. Right?
On one side, on the other side the other vendor didn't support S3TC 3/4/5 which sucked ass compared to theirs.
You're grasping at straws as you know exactly what I mean by "initial". By the time the Radeon/GeForce/Voodoo5 benchmarking was in full swing nVidia was using 16 bit compression and gained an unfair advantage by doing so.
How was it unfair? Was it more unfair then the V5's inablity to do trilinear filtering? Was it unfair to pit the V5 against the R100 and NV1X when the V5 had superior FSAA? What about the V3 not being able to run the highest quality textures? It was a factor that should have been and was looked at by numerous sites. The site I was writing for more then any other IIRC.
Right, so according to you an nVidia hardware level problem that exists through three generations of boards and reduces image quality to gain performance isn't cheating
It was as much a cheat for nVidia as the R300 core boards not supporting PS 3.0 is. I have two games that it impacted, one of them I fixed myself.
but a software problem that exists in a single ATi driver and when removed in the next driver not only fixes the issue but also improves performance is a cheat?
It's as much a cheat as what nV has been experiencing in most of the recent benches.
And yes, Radeons support S3TC/DTXx just fine and even DXT1 looks great on them. I use S3TC (wrapped to DXT1) all the time in Quake III based games and in UT as well.
The original Radeons supported S3TC1(DXTC is the exact same thing, bit for bit, MS licensed the technology from S3). They didn't support the other levels.
Please explain what you mean by this and what your stance on the position is.
It is another hack in the same mold that ATi's and nVidia's current AF is, the same way that PowerVR's box filter trilinear approximation is, the same way that most other hacks are. It reduces IQ and improves performance. The difference between a hack and a cheat is they aren't rendering anything 'wrong' per se, they are simply reducing the workload to get a comparable(although always with lower IQ) effect. The brilinear filtering isn't doing pure bilinear or pure trilinear(although not quite as bad as PVR's) and it is reducing the amount of proper AF filtering even further(although not as bad as the R200 core boards) reducing the overall IQ compared to a proper full implementation, but improved compared the image not using technique would provide. Actually, in the case of the PVR hack I tended to chose bilinear filtering over the box filter psuedo trilinear as at least with bilinear you had a lot less noticeable mip transitions(in terms of quantity, although the transistions themselves on an individual basis were far more noticeable with bilinear then the approximation).
Facebook
Twitter