3DMurk03 new cheats ?
- Thread starter nelg
- Start date
The problem is with the Drivers and NVIDIA wanting to make the FX appear faster.
AF can be fixed with this cheat if the detection scheme is skipped.
Taking screen pics between your Geforce 4 (maybe Geforce 3 too) and Geforce FX card will show differences that NVIDIA is trying to make the FX appear faster.
The old Application setting in the drivers worked well but was slower in games (plus UT really sucked with that setting).
AF can be fixed with this cheat if the detection scheme is skipped.
Taking screen pics between your Geforce 4 (maybe Geforce 3 too) and Geforce FX card will show differences that NVIDIA is trying to make the FX appear faster.
The old Application setting in the drivers worked well but was slower in games (plus UT really sucked with that setting).
Ahem...Himself said:
http://www.beyond3d.com/forum/viewtopic.php?p=124473#124473
I think its worthwhile to continue to investigate until we know for sure, rather than haphazardly labelling it a cheat.
radar1200gs said:
The only way this could be a problem with the silicon is if something in the silicon is recognizing when "3DMark.exe" is being run instead of another .exe file. I cannot describe how horrible an engineering design this is. And I can see no way in which the silicon could "accidentally" be noticing the filename, which is what would have to be the case if it was indeed a bug and not an intentional part of the design.
Nazgul said:
Maybe I am mistaken but have you or has anyone for that matter provided evidence that proves beyond doubt that the NV3x line of cards (the silicon) can detect wheather 3dmark is running or not?
I'm sorry for not reading the ENTIRE thread but I just want to know if there is any hardcore evidence presented.
madshi said:
Well, people want proof of these things. To suggest something and provide no evidence of it is like calling someone names. Everyone knows that name calling is just a whole bunch of adjectives, verbs and nouns without any basis whatsoever (in most cases anyway).
Tokelil said:
I wouldn't say something along the lines of a driver passing a value across the GPU to a certain register that will activate something along the lines of poor IQ.
No really, I wouldn't say it's impossible.
I just want proof of such a thing occuring.
K.I.L.E.R said:
Just what would constitute "proof"?
Note that US courts simply require "shown beyond reasonable doubt" in order to sentence someone to death.
"Proof" as such only exist in formal logical systems.
If we were a jury, would we say that it had been show beyond reasonable doubt that nVidia....
Of course, we are not a jury here. We are, for the most part, consumers. For us the question is the reverse -
Do we trust nVidia NOT to have cheated and thus made this comparitive data invalid?
Entropy
radar1200gs said:
The responce was a glib one, because that doesn't explain what is occuring here - or at least, its highly unlikely to.
If the silicon were buggy then it would exhibit the same issues in all usages of Anisotropic filtering so the driver would be coded to use the 'fixed' route on a gobal basis (since they are the interface between the API calls and what the hardware needs to do), it would be relatively stupid to put in specific 'game' work arounds for something that would generically affect everything.
gokickrocks
Regular
deleted post
DaveBaumann said:
Thanks Dave, I needed that to form an opinion on the matter. :? The 3dmurk_8x is clearly better than 3dmark_8x in a way that the shots at tech-report doesn't really reflect IMO.
Anyway, I'm now left wondering whether nVidia added some detection to force Application mode to Quality mode? They might have felt that it didn't degrade image quality... (not an excuse, just a possible explanation)
But the Quality mode wouldn't selectively apply it to texture in that fashion.
radar1200gs said:
Man, you are really confused about some things....don't you realize that unified driver packages contain lots of individual drivers and configurations for the different chips they support...? If you download a set of unified drivers and install them for nv20--hey, you aren't even running the same drivers that are set up for an nv3x gpu running the same Detonator version. The unified driver means "all drivers in one package"--it does not mean "one driver for everything." (Think about it for a minute and you'll understand why.) Looking at a GF3 tells you ....nothing about the 3D Mark 03 320/330-Detonator/nv3x issue. Might as well be running a Parhelia and making comparisons...
LeStoffer said:
I think this one is an older driver cheat that's been in the code for awhile and overlooked--but maybe not as people say it doesn't happen with the GF4/3. It just seems like tying driver recognition to the executable name is an older, less-technically adept method of cheating dating back a couple of years. Certainly it's not in the same league with the kind of camera-track cheating nVidia was nailed doing in 320. Just almost seems like a left-over cheat somebody forgot about...perhaps it had to do with the nv30 fiasco--as it does seem apparent on the 5800U according to TR, even with the 330 patch--which I don't think dealt with name-recognition cheats at all(?)
Similar threads
