Bjorn said:
Ok, read the update. But doesn't the question still remain. Should it really be different from game to game ?
Might as well ask, "Shouldn't all 3D games be alike?"...
All 3D games do things differently from each other in some regard. IHV drivers which work properly in displaying FSAA'ed fonts in one 3D game fail to do so in another--and the IHV implements what's known as a bug-fix in its drivers specific to the application that fixes the problem. That's because 3D games are coded differently, even 3D games which use the same game engine. It's important to remember that even using the same engine such games are different pieces of software, put together by differing individuals (programmers) who have techniques, approaches and preferences that are often as unique as fingerprints.
I remember with my GF3/4 (not sure which) I used one of Unwinder's RT versions which provided for, among other things, the ability to force AF on various texture stages, up to all four, as I recall. I experimented with the option in several pieces of software and found that there were few, if any, that benefitted in IQ improvement from the default setting of 1st stage AF to setting it up for stages 2-4 additionally, in any order. But I did in several games as I recall notice a measurable performance hit when going beyond 1st-stage texture treatment. So I wound up going back to driver defaults of 1st-stage AF treatment.
Ideally, we'd all be able to set our driver control panels to Application Preference and adjust whatever settings we'd like from within the application. But unfortunately most 3D games, especially older ones, don't allow for that. So, the IHVs compensate by designing in overrides to force the settings we want by way of the control panel. When they do so, they have to try and predict the most likely settings for the bulk of games which can only be controlled through the control panel. In this case ATi made the choice of doing it for the first stage only, and as it turns out this is a very good choice, as as far as I know, UT2K3, because of the unique way in which it layers textures in the game, is the only game for which this isn't sufficient. If 3D games were coded properly in this respect we could set each one up internally and never have to leave the game to return to the control panel to change settings--since we could set up all of our games individually from within.
So with respect to UT2K3 and the current Cats, to get full trilinear it is necessary to turn it on from within the game, using the UT2K3.ini, because of the difference in which UT2K3 layers its textures compared to most other 3D games (if not all of them.) Folks should understand that because all 3D games are programmed by differing individuals the only thing an IHV can do through the control panel is attempt to force a setting in a game based on an estimation of what all programmers will do.
In UT2K3 the Cat control panel instructs the driver to treat only the first texture stage. But when UT2K3 itself instructs the driver, it tells the driver to treat stage one and stage three (or whatever the other stages may be.) It's really that simple. [What's so very different about the Detonator behavior here is that when UT2K3 tells the nVidia driver "Give me treatment on stages 1 & 3" the driver is hard-coded to ignore that command, and substitutes something else.]
The point is not that full trilinear in the game isn't possible from the CAT control panel, the point is that it *is possible* to get full trilinear from within the game itself from the CATs. The only difference is in the instruction provided the driver.
In a sense, I blame Epic since they are bound to know that their texture layering scheme differs from most games, even from other UT2K3-engine games like Unreal 2. I'd like to see them do up a little GUI for people to adjust the .ini settings--as it seems so many seem to find it overly complex as a text file. It's really a problem of assigning responsibility to the developer for the support of IQ settings within its game, I think. But as long as developers continue to skimp in this area, the IHVs will have to plod along as best they can, making correct guesses when they can and doing per-application bug fixes when they can't.
