New CATALYSTS!

I'm very fuzzy on the OpenGL control panel thing. I know that with NWN with both the 3.6's and the 3.7's I can set the texture preference slider to High Performance and get 32-bit textures, whereas setting it to High Quality (or any setting in between) seems to revert to 16-bit texture display in the game. It looked like a simple muckup in Cpanel to me--no biggie--and since you can work around it--it's hardly a matter of life and death. But I tried to get into a thread on R3d to explain to people that I had been able to work around it--but those of us in that thread who didn't want to lynch Catalyst Maker--Heh...--were the minority over there and they locked the thread. (I think CM got his feelings hurt--he shouldn't have--there might have been only 16 bug reports of this made, but there were far fewer than that in thread who were rude and uncouth--maybe 2-3 who kept ranting rather mindlessly.)

But as CM explained the bug had been identified--and was already fixed in an internal build--would it be improper of me to ask what caused it? Does it affect anything other than NWN? It almost looks like an application-specific optimization for NWN which went a bit awry (and...uh, I've made it plain I see nothing improper about application-specific optimizations for games, so this is *not* a loaded question.) Just curious as to how this might have escaped the 3.7 beta testing prior to release--of course, it might have been known about all along, and if so I was just wondering as to the reason it wasn't fixed. I'm not concerned about it--just curious.

I want to add to Catalyst Maker and the other guys how impressed I've been over the last year with the Catalysts. This bug, as minor as it is to me, is the most major bug by far I have seen in the Catalysts since last year--and that's a very high compliment. The commitment you guys are making to driver development is an example to the industry--I never expected you to be perfect--but neither would I a year ago have expected you to be as consistently good as you've been. What I really like and appreciate just as much as the quality you've been producing is how well you listen to your customers (the OpenGL triple-buffering option for 3.7 is but one example--the accelerated driver production schedule is another.)

Love and Kisses (yuck!),

WaltC....

 

Hmmmm, it seems that I am the only person that owns a Radeon 9800 don't use FSAA or AF at all.

 

You're weird

I play all of my games with 4x AA and 8x AF enabled. Resolutions are usually 1280x1024 or 1600x1200. Looks awesome.

 

/me nudges RaolinDarksbane

Except I have an R300.

I keep telling people that AF makes the IQ bad and anything other than QCX makes the IQ bad.

 

The 3.6's produced a horribly banded sky on my 64MB 9100. Is this a result of a driver bug, a game bug, or the game compensating for the limited onboard RAM? If it's the first, has it been fixed?

As for this "16-bit OGL bug," do you all mean recent Cats just default to 16-bit textures in all OGL apps? I haven't really noticed any banding with Wolf: ET, but maybe I'm not looking hard enough.

 

I too don't notice it in Wolf ET, in UT2003 it's only noticable in certain maps like CTF Magma (sky).
...........................

As for not using AA/AF when you own an Rx0....
It was the sole reason I upgraded from a Ti4200 a year ago (-10 days)!

 

Hi Bambers - are you talking about these tweaks:

Code:

SkipProgramFlows=0
DontThreadLoad=1

or:

Code:

Interior Cell Buffer=32
Exterior Cell Buffer=64

With these settings the problem isn't solved.

 

Bugger. There's just no way Bethesda will do anything to fix this given their patch history.

OpenGL guy, sorry to be a royal pain in the a.. over this, but if you guys have any intermediate tweak, please let us know.

 

My guess is that performance increase announced for OGL is actually due to the 16 bit textures being forced, not some driver tweak

 

This particular bug was in 3.6 (and before?), so that wouldn't account for any increase in this release.

 

This is why I was hoping CM would address this more directly and put it to bed until the 3.8's...

I've only noticed this with NWN version 1.31, but you can force 32-bit textures by simply moving the texture preference slider to High-Performance--some people say it doesn't work for them--but it works consistently for me in NWN (haven't looked at anything else.) I would imagine that doing an application-specific bit of coding for NWN to force 16-bit textures just to gain performance would not result in the ability to select 32-bit texture support in the Cpanel at all--let alone from the opposite Cpanel setting at which you would expect to find it. So that's why I think it was a legitimate bug rather than a deliberate attempt to slide something in under the radar. Something like this is just too obvious.

Other people state that the High-Quality texture preference Cpanel position works correctly with other OpenGL games, so I think this was likely a bug introduced with an app-specific optimization for performance added to the drivers in conjuction with the NWN 1.31 patch release from Bioware (although, certainly, the game patch may have nothing to do with it.) I only bring up the 1.31 beta patch because that's when I first noticed it.

Since ATi has already fixed the bug, they know what games are affected by it and could definitively answer whether the bug is app-specific or universal, and I think they should say something along those lines along with their already-stated pledge to correct it in the 3.8's. Just to let people know, if nothing else. Otherwise people are likely to draw the same conclusions you've drawn here...

My only suggestion to CM and the guys going forward is that they not only prioritize on the number of bug reports they receive, but additionally on the nature of the bugs reported. Even though they got relatively few reports on this issue, the nature of it is such that everybody is affected by it.

 

Good to see you here Terry

 

well it looks like it's not app specific, as I posted here:

http://www.beyond3d.com/forum/viewtopic.php?t=7756

happening to me in Homeworld 2 demo which is openGL. it's very noticeable in the background, defintely 16-bit.

edit: never mind, looks like an issue with the game itself as apparent on nv cards as well....

 

Afaik, this bug affects every newer OpenGL-game. Someone said, that games that use OpenGL 1.3 or newer are affected. Can't say anything about that but it's sure that this affects every Q3-game out there. Or atleast I've read ~30 people complaining about it. QW seems to be fine. So it isn't a bug that you can only see in NWN.

 

Out of curiosity guys, in games other than NWN does setting the tex pref slider to HP fix it for you?

 

Doesn't do anything for me using HP in other games (don't have NWN though either, so I can't compare).

 

Jeese CatalystMaker! Do you have an account on every board on the web?!?!

(Sorry Terry, I've just ALWAYS wanted to ask someone else that for a change. )

 

Not sure if it's the 3.7s or not but the Jedi Academy demo hard locks my system on mission reloads quite often. Settings are 6x AA/16x AF, 32-bit everything, trilinear, 11x8 resolution, Vsync enabled, etc.

Sacrifice also still exhibits the same Z errors that've made the game unplayable on R3xx hardware for the past year.

 

Did you try enabling triple-buffering?

 

hmm, I've been having strange problems when quick-loading in RTCW, also QIII engine. Half the time or so, suddenly the framerate will plunge to 13-15 (from 90ish).

Triple-buffering doesn't help, but, wierdly enough, it gives me a massively jumpy framecounter (as reported by the RTCW framerate counter), at the exact same time as FRAPS is reporting rock-steady FPS.

Sometimes, as well, when I quickload, RTCW won't be slow (at its normal 90, as reported by the ingame framecounter), but FRAPS will be claiming that the framerate is 13-15 (when it obvioiusly ain't, as opposed to the prior case when it obviously was).

this is all w/ AA AF and vsync.

also, the Dawn demo now appears to be broken (something about my card not supporting nv_point_sprite). I'm guessing it needs a new opengl32.dll.