State of the Graphics Industry Rant

[Galilee]

Was'nt there a problem with moire when using aniso in some games (like team arena) on R200?

 

[RussSchultz]

And the only reason why I'm "picking" on you, is because at the same time you're arguing, you decided to pulling the "f@nboy" argument on Doom.

No, I didn't pull the "f@nboy" argument on Doom, I told him that card comparisons aren't what the point of the discussion was about.

The original discussion was concerning the rant at that website which centered on how to compare, not the items being compared.

It seemed to me as if the ranter wanted an issue to be "OK" because it was "different" even though it had issues in its implementation.

Which then devolved into arguing over whether a particular product had issues...which, I'll repeat, was not the point of the original discussion.

IMO...you and doom are doing the same thing. Downplaying the "disadvantages" of "your companies" product, and going "over the top" on the disadvantages of the "other" companies product.

You seem to think I care which manufacturer made which product. I don't have anything I'd call "my company".

Yes, the NVIDIA S3TC implementation "sucked" when compared to its competitors implementation (though its strange to call something 'sucking' when its completely compliant with the specification).

I'm sorry if "one obviously is better" and "sucks" are too far separated on the spectrum for you to be 'even handed'. If you'd like, I'll just denote everything as "questionable" from now on.

 

[Joe DeFuria]

You seem to think I care which manufacturer made which product.

You seem to think correctly. And I'll explain why.

(though its strange to call something 'sucking' when its completely compliant with the specification).

The point is, if you think that's strange, then I would think it's also strange to call something "sucking" (R 8500 aniso implementation) when you only consider one facet of that implementation: quality.

I'm looking for consistency here.

To be absolutely clear: the fact that you apparently think it's "strange" to refer to nVidia's implementation as "sucking", and yet offered that description to ATI's implementation without such reservations...leads me to believe you care which manufacturer made which product.

And yes, I do believe that Doom also cares about which company made which product. As I said, it appears to me you are on opposite sides of the spectrum.

"That's my opinion...I could be wrong."

 

[walkndude]

why dont you use pm's to bicker with people Joe ?

 

[darkblu]

funny, Dave, you enumerate two (2) elements but you draw you '8500's aniso is not broken' conclusion only based on the first. check the other thing, too.

that was the point of what I was getting at - there appears to have already been the conclusion that the z rotation limiation was a 'bug' becuase it has been 'fixed' in 9700 however how can you conclude its a 'bug' based on a new implemtation? Are we to conclude that the bilinear limitation was also a 'bug' because its 'fixed' in 9700?

first, i never stated it was a bug, i deliberately used the word flawed signifying it was not implemented consistently according to the specs. whether the cause for this flaw was a bug or a trade off is of no importance to me. as to why it was flawed:

no matter how loose aniso filtering is formulated in both d3d and ogl, it is still defined as the elongation degree of the pixel's inverse mapping onto the primitive. if a pixel from a surface exhibits a given degree of anisotropy less-or-equal to the API-set anisotropy degree, it is supposed to get that filtering no matter what. it is definition-inconsistent that one pixel of anisotropy N gets the filtering while another pixel nearby of the same anisotropy N does not get it because it belongs to a bad karma-uv-mapped surface, it's the wrong aniso-day of the week, or whatever.

I don't think there is any basis for saying that this wasn;t a pure design limitation for 8500 based on what 9700 is able to do. This is also why I say that a far better comparison to make is between 9000 and 8500 - if it was a 'bug' then it would be more likely that they would have fixed it there; if it was an implementation limitation then its less likely they woulkd have risked a known and operable design to change it.

as i already mentioned, i don't care what the origin of the r200's af flaw was - it's not my concern. but for ati's own sake, i do hope they got af right in the 9000, as breaking basic api definitions is a sure way to piss off developers.

 

[Joe DeFuria]

why dont you use pm's to bicker with people Joe ?

This, coming from someone who has posted:

...and Droolscooper drives yet another happless thread over a cliff, his face contorted by that unnerving tic which seems to surface at any mention of the word Nvidia...

At least my "bickering" isn't blatant name calling. The mods here have no problem locking threads that they feel have "run their course", and I'm sure they will do so here if they feel it's at that point.

 

[Joe DeFuria]

do hope they got af right in the 9000, as breaking basic api definitions is a sure way to piss off developers.

Well, that's the trouble. Where's the "API definition" of anisotropic filtering?

(Edit)...and your statement brings up another important point: are these products for DEVELOPERS or are they for CONSUMERS.

Ultimately, they are for consumers. That's who buys them to pay for the IHVs salary. For these particular products, "technical correctness" is not as important as the end reslut of overall experience.

that one pixel of anisotropy N gets the filtering while another pixel nearby of the same anisotropy N does not get it because it belongs to a bad karma-uv-mapped surface, it's the wrong aniso-day of the week, or whatever.

...or if it's on the wrong "texture stage?"

I do understand your point, and the "desire" to have "technical correctness" of implemented features. But in reality, what matters is not technical correctness, but the end result, and how "distinguishable" it is from "technical correctness" to the target audience.

Put another way, if I only used my computer on Saturday and Sunday, then putting in an "ansio day of the week" implementation that speeds up aniso performance by 250% on Saturday and Sunday (because it rests Monday-Friday, only bilinear is available), is a great solution.

 

[darkblu]

Put another way, if I only used my computer on Saturday and Sunday, then putting in an "ansio day of the week" implementation that speeds up aniso performance by 250% on Saturday and Sunday (because it rests Monday-Friday, only bilinear is available), is a great solution.

put yet another way, the point in providing a consistent implementation of a given feature is that somebody else owning that same videocard could use it on different days of the week than you do <grin>

(Edit)...and your statement brings up another important point: are these products for DEVELOPERS or are they for CONSUMERS.

it may sound strange to you, but it's not an 'either-or' question - hw is both for developers and consumers, as i don't think consumers would buy those products if all they could do is use them as paperweight.

 

[Joe DeFuria]

put it yet another way, the point in providing a consistent implementation of a given feature is that somebody else owning that same videocard could use it on different days of the week than you do <grin>

Of course. And that's exactly why I've stated numerous times that its often personal preference or game dependent on whether or not the pros outweigh the cons for a particular implementation. Which is why I generally frown on labelling one implementation or another a "cheat".

One implementation or another might not be right for you, or a certain group of people...that doesn't mean it's not a valid implementation.

it may sound strange to you, but it's not an 'either-or' question - hw is both for developers and consumers, as i don't think consumers would buy those products if all they could do is use them as paperweight.

While I considered and understand your point, I basically disagree. Simply put....software developer's product is for consumers.

So we have two different vendors (hardware and software) both selling to consumers. Developers only ask HV vendors to support features that they feel will ultimately benefit the consumer, because that's how they make their money.

 

[Doomtrooper]

I can't believe Darkblu you are ranting over a very simple issue, its not that big of a deal and it certainly isn't grounds to exclude the card from a video card test...

The filtering quality is not even in question here, the quality is better than most cards on the market, works very well in 99% of the games..possibly flight sims may show a issue, or you run up to wall look up and start turning back and forth....it isn't something that stands out !!!

Do you have a card to test this or to judge yourself ?? The peformance hit doing it 'Nvidias Way' is too great so it isn't the correct way either..what is the use of having a feature if you can't realistically use it...and just stating that you support the feature on the box means you should be able to use it...

I really like to know where you are going with this...whats your angle

 

[darkblu]

put it yet another way, the point in providing a consistent implementation of a given feature is that somebody else owning that same videocard could use it on different days of the week than you do <grin>

Of course. And that's exactly why I've stated numerous times that its often personal preference or game dependent on whether or not the pros outweigh the cons for a particular implementation. Which is why I generally frown on labelling one implementation or another a "cheat".

that's the problem with personal perference - your personal preferences are not mine. that's why we expect the parties determinant for the satisfaction of our preferences to play by the established rules (read stick to API definitions), so sw developers could express their personal preferences in their products, so eventually we - the consumers, could enjoy what those developers produced the way we like it - you do realize the r200 deprived all those who prefer fligh-sims of proper visual experience, don't you?

One implementation or another might not be right for you, or a certain group of people...that doesn't mean it's not a valid implementation.

doh! it's quite invalid if the software was written with this feature in mind and the hw did something else. what's so hard to grasp here?! why do you think developers expect to see red where they meant read on the screen and the consumers, on their turn, might be quite uhappy if they saw somehting else than what the developers meant? why do you think the whole human society is built upon perdictability, stated in social-order-enforcing laws???

specs are out there for a reason!

it may sound strange to you, but it's not an 'either-or' question - hw is both for developers and consumers, as i don't think consumers would buy those products if all they could do is use them as paperweight.

While I considered and understand your point, I basically disagree. Simply put....software developer's product is for consumers.

So we have two different vendors (hardware and software) both selling to consumers. Developers only ask HV vendors to support features that they feel will ultimately benefit the consumer, because that's how they make their money.

cool. email this opinion of yours to JC and read the answer you get from him carefully.

 

[Doomtrooper]

you do realize the r200 deprived all those who prefer fligh-sims of proper visual experience, don't you?

Omg... you gotta be kidding me, you are ranting over a minor issue and you post CRAP like that....well using your logic then...

Nvidia deprived all those that like Quake of a visual experience...or doesn't that count...

Nvidia deprived all those that like MDK2 of a visual experience...or doesn't that count...

http://www.ve3d.com/3dpulpit/misc/aa_gf3v5/gf3_4xaa.jpg

 

[Bjorn]

The peformance hit doing it 'Nvidias Way' is too great so it isn't the correct way either..what is the use of having a feature if you can't realistically use it...and just stating that you support the feature on the box means you should be able to use it...

Aren't you going a bit far here ?
You get more then 1 fps when using aniso on a GF 3/4 card you know.

 

[Bjorn]

Nvidia deprived all those that like Quake of a visual experience...or doesn't that count...

Excuse me, but couldn't you easily get rid of the Quake3 problem ?

 

[Doomtrooper]

Ok over a 50% hit enabling anisotropic filtering, a Ti4600 is getting 50 FPS and thats without AA..so what would a end user do here...either turn it off or lower that sampling..either way it effects image quality..

 

[KimB]

Excuse me, but couldn't you easily get rid of the Quake3 problem ?

Very easily.

First, you could use DXT3 compression instead, generally using a tweak utility, that increases the memory footprint slightly, but improves visual quality quite a bit.

Secondly, you could just disable TC altogether.

Neither is hard, and later versions of Q3 shipped with TC disabled by default, if I remember correctly.

 

[Doomtrooper]

Nvidia deprived all those that like Quake of a visual experience...or doesn't that count...

Excuse me, but couldn't you easily get rid of the Quake3 problem ?

Huh..do you think the entire ppoulation of earth is on the internet...hell I still have friends that are not on the net.
Not everyone is tech savy, and it was quite a while before a fix came out for that issue as I had a GTS at that time.

 

[RussSchultz]

So, are those numbers with the old version of the 8500 anisotropic filtering (as shown in the cool colored number tunnel), or the new version?

(Since nobody bothered to answer if the new version that optimally non axis aligned textures suffered a speed hit)

 

[Galilee]

NVIDIA did "something" with the compressionbug:
Not perfect but better.

No compression:
http://www.stud.ntnu.no/~vidaralm/q3_nocompr.jpg

With compression:
http://www.stud.ntnu.no/~vidaralm/q3_compr.jpg

Update: It's dithering they applied.

 

[Doomtrooper]

Excuse me, but couldn't you easily get rid of the Quake3 problem ?

Very easily.

First, you could use DXT3 compression instead, generally using a tweak utility, that increases the memory footprint slightly, but improves visual quality quite a bit.

Secondly, you could just disable TC altogether.

Neither is hard, and later versions of Q3 shipped with TC disabled by default, if I remember correctly.

Chalnoth I laugh how you expect average Joe Shcmoe gamer to jump on the net that he might not have and start downloading a tweaker on his brand new card to disable a feature

I can see it now as I used to own a PC store...' Sir I would reccomend that you download this tweaker here, there is a flaw in that card that you just paid $400 dollars for...the sky on Quake is all screwed up and..'