shader competition results

Joe DeFuria said:
No, because any user who switches their control panel from the default "application preference" surely knows how to switch it back.

Not everyone realizes that that's where the problem lies though. I didn't realize that AF was the problem with frogger until I read it on this forum.
 
Humus said:
Not everyone realizes that that's where the problem lies though. I didn't realize that AF was the problem with frogger until I read it on this forum.

But Humus,

"We're talking about people whose job it is to know how to properly program in 3D." ;)
 
Chalnoth said:
And the disappointment of the GeForce4 MX was only due to comparison to other nVidia products. Nobody else had, at that time, as good of low-end parts.

Didn't ATI have Radeons at the time, including at the low end? The Radeons all had better image quality features than the GeForce4 MX (or other GeForce2 core chips). Their main problem was that they were slower.
 
Joe DeFuria said:
Humus said:
Not everyone realizes that that's where the problem lies though. I didn't realize that AF was the problem with frogger until I read it on this forum.

But Humus,

"We're talking about people whose job it is to know how to properly program in 3D." ;)
It's not the programmer's fault if a forced feature breaks the application.
 
Xmas said:
It's not the programmer's fault if a forced feature breaks the application.

I'm not saying it's the programmer's fault that a forced feature breaks the application.

It's actually the user's fault. It would be the IHVs fault if the "application preference" setting breaks the application.

It would be the programmer's fault for relying on forced features to provide aniso / AA, if the programmer wishes for AA / aniso to be supported.
 
Yes, but you argued that "any user who switches their control panel from the default 'application preference' surely knows how to switch it back", which is true. But this doesn't mean that the user will understand that this is where the problem lies. In fact, I think more users will quickly browse to their favourite forum and start to spam "GAME X DOESN'T WORK!!!! ATI DRIVERS SUCK!!!!!111!1", alternatively "GAME X DOESN'T WORK!!!! GAME X SUX!!!!11!1". So the problem will be put back on the shoulders of the IHV and the developer to deal with, regardless if they are guilty or not.
 
ET said:
Didn't ATI have Radeons at the time, including at the low end? The Radeons all had better image quality features than the GeForce4 MX (or other GeForce2 core chips). Their main problem was that they were slower.
The low-end Radeons of the time were no better. They were of the original Radeon line, had lower performance, and the GeForce4 MX had the anisotropic filtering and anti-aliasing of the GeForce4 Ti line, so no, they didn't have better image quality features.
 
Joe DeFuria said:
It's actually the user's fault. It would be the IHVs fault if the "application preference" setting breaks the application.
"User error' is such a copout. It's an excuse for developers not bothering to make the changes necessary that would reduce the occurence of user error.

In this case, it would be just so incredibly simple to just not force anisotropic when point sampling is enabled. That would prevent this problem from occurring in the first place.

And, I am willing to bet, it would reduce image quality on zero games.

So, if making a very small, very simple change will prevent problems, while at the same time have no drawback, why in the world is it not done? And how is it not ATI's fault when it isn't done?
 
Chalnoth said:
The low-end Radeons of the time were no better. They were of the original Radeon line, had lower performance, and the GeForce4 MX had the anisotropic filtering and anti-aliasing of the GeForce4 Ti line, so no, they didn't have better image quality features.

I have a Radeon 7500 here, and it supports 4x AA and 16x AF. Granted it's a bit enhanced over the original Radeons, but how much worse were they? I think that the main argument would be "had lower performance".

Although I kind of look at it from a developer's POV, too, and the Radeons definitely had features that allowed developers to produce a better pictures. Unfortunately, due to being less popular cards than the GeForce family, they were rarely used, since it's easier to just program to the lowest common denominator, the GeForce. I'm talking about EMBM, volume textures...
 
ET said:
I have a Radeon 7500 here, and it supports 4x AA and 16x AF. Granted it's a bit enhanced over the original Radeons, but how much worse were they? I think that the main argument would be "had lower performance".
Primarily, the GeForce4 MX supported multisampling AA, as well as full trilinear anisotropic filtering that I would consider better-looking than anything ATI has yet offered (i.e. you don't have the off-angle problems of the R200 and R300...remember that the off-angle problems were really bad on the R200, and while I'm not sure as to the exact improvements of the R200's AF over the R100's, I've heard there were improvements).
 
Chalnoth said:
Primarily, the GeForce4 MX supported multisampling AA, as well as full trilinear anisotropic filtering that I would consider better-looking than anything ATI has yet offered (i.e. you don't have the off-angle problems of the R200 and R300...remember that the off-angle problems were really bad on the R200, and while I'm not sure as to the exact improvements of the R200's AF over the R100's, I've heard there were improvements).

Wasn't the off-angle problem in the R200 just for the fast AF version, not full AF which still existed? Does the 4 MX have two such levels of AF? (I guess I could just try this tomorrow at work, but I'm sure I'll get an answer here before then.)
 
ET said:
Wasn't the off-angle problem in the R200 just for the fast AF version, not full AF which still existed? Does the 4 MX have two such levels of AF? (I guess I could just try this tomorrow at work, but I'm sure I'll get an answer here before then.)
No. Just like with the R300, the "off-angle" problem is an artifact of the anisotropic degree selection algorithm. As far as I know, the 4MX has the same anisotropic options as the 4Ti cards (with which there is little visible difference between "performance" and "quality").
 
Chalnoth said:
As far as I know, the 4MX has the same anisotropic options as the 4Ti cards (with which there is little visible difference between "performance" and "quality").

I just checked the AF options on both a 4Ti and 4MX cards, and while the 4Ti offers up to 8x AF, the MX offers just 2x, like the GeForce2. The Radeon 7500 offers up to 16x. I'd imagine that even with some problems in sampling direction, the Radeon offers better AF than the GeForce4 MX.
 
Chalnoth said:
"User error' is such a copout. It's an excuse for developers not bothering to make the changes necessary that would reduce the occurence of user error.

Correct, like developers not putting in code that detects that AA or Aniso is forced on, and displaying a mssage or exiting the program with a message.

In this case, it would be just so incredibly simple to just not force anisotropic when point sampling is enabled.

I bet my solution is even simpler.

So, if making a very small, very simple change will prevent problems, while at the same time have no drawback, why in the world is it not done? And how is it not ATI's fault when it isn't done?

You are assuming this is a small, simply change, and it DOES have a draw back where there will be items that don't get filtered that the user wants filtered.
 
Joe DeFuria said:
I bet my solution is even simpler.

A solution requiring hundreds of people to do something is never simpler than a change in one central location.
 
Joe DeFuria said:
Chalnoth said:
"User error' is such a copout. It's an excuse for developers not bothering to make the changes necessary that would reduce the occurence of user error.

Correct, like developers not putting in code that detects that AA or Aniso is forced on, and displaying a mssage or exiting the program with a message.
I presume you're being sarcastic here.

It'd certainly be an interesting programming challenge for the developer to work out whether either of those was switched on behind their (collective) backs.
 
Joe DeFuria said:
Chalnoth said:
"User error' is such a copout. It's an excuse for developers not bothering to make the changes necessary that would reduce the occurence of user error.

Correct, like developers not putting in code that detects that AA or Aniso is forced on, and displaying a mssage or exiting the program with a message.

In this case, it would be just so incredibly simple to just not force anisotropic when point sampling is enabled.

I bet my solution is even simpler.

Have you ever tried to fully detect when AA or Anistopic filtering is forced on? Its very hard, (I know because SH2PC is meant to detect AA but still fails in many cases).

Some drivers simply don't AA to any buffer that can be locked, others use post-process AA (in the flip, usually by a filtering blit) so any locked buffer hands back a non-AA results. Our AA detection code in SH2PC (which basically consisted of rendering a white triangle on a black background and checking if AA had been applied) used to get it wrong with just about every driver change.

For Anistropic different drivers give different results based on angles, texture stages, other settings, etc.

So I can assure you, the people to fix this issue are the IHVs, the USER or the API owners (who could allow us to override the forced settings) not the devs.
 
Simon F said:
Joe DeFuria said:
Chalnoth said:
"User error' is such a copout. It's an excuse for developers not bothering to make the changes necessary that would reduce the occurence of user error.

Correct, like developers not putting in code that detects that AA or Aniso is forced on, and displaying a mssage or exiting the program with a message.
I presume you're being sarcastic here.

It'd certainly be an interesting programming challenge for the developer to work out whether either of those was switched on behind their (collective) backs.

'Interesting programming challenge' wouldn't be how I'd describe the SH2PC teams experience trying to detect AA (so we could shut the post-processing filters off that broke when forced AA is on), my description would involve more swear words :)
 
DeanoC said:
Have you ever tried to fully detect when AA or Anistopic filtering is forced on? Its very hard, (I know because SH2PC is meant to detect AA but still fails in many cases).

I thought we're specifically talking about point-sampling shaders here...where computational results change if filtering is enabled?
 
Back
Top