[BoardBonobo]

[quote="Doomtrooper"]

1) Although ATI's FSAA is not the fastest, it delivers better IQ
2) The Geforce 3 Ti 500 was faster than a 8500 on its debut BECAUSE all Nvidia did was raise the clock speed, shrink the die..did not add any new features at ALL besides a new name and enjoyed USING the same drivers they had been working on for a entire year on the Geforce 3 ..Then 4 months later releases another chip call the Geforce 4...I wonder how Ti 500 owners felt
3) The Geforce 3 can't do truform at ALL ??
4)The Geforce 3 and 4 can't do multiple Pixel shader effects due to lack of support of PS 1.4.
5)The Radeon 8500 has a SUPERIOR anisotropic filtering...since you base everthing off speed alone then ATI's implementation is better.
6)Geforce 3 and 4 still can't properly uses texture compression ??

Those are all good points but

1. In what way is the FSAA IQ better on the Radeon. Any high level of FSAA slows the Radeon down too far to make it any use.

2. That's totally undeniable The GF3 and on to GF4 was just a big marketing coup for nVidia. Lot's of cash for that R&D budget.

3. TRUFORM is a feature that isn't required on a card that can push enough polygons to produce a to produce smooth models anyway. And in any scenario that requires real time generation of (here I'll use JC's example) shadows it is totally useless, the stencil buffer can't be truformed and recalculation would wipe out performance. It could also be the reason the R200 is slower than it shoud be. Scanning each vertex in order to tesselate it could be the reason the R200 stalls, that little problem that JC pointed out. So maybe n-patches isn't such a hot feature after all. And may have even been the feature that crippled the R200.

4. That's never going to be a problem. PS 1.4 will only ever be used in some nice demos by ATI (and mighty tasty they are too!) . DX9 and PS2.0 will completely swamp it. I didn't really see the point in ATI investing the time in that at all.

5. As the index of this site shows, nVidia may finally be getting their thumb out of their ***es and concentrating on Aniso quality for the latest driver release. Hi res. game play with good Aniso and 4x FSAA that'll be fun (Dungeon Siege can only get better).

6. The texture compression bug seems to be either fixed or mightly improved in the latest driver releases. And who's got time to stand around admiring the sky in QIII. Sure way to get your ass fragged!!

7. I'm heading for a total flambé with this post but it's all fun and games

And I've got a copy of Dungeon Siege now if you want some more benchmarks...

SurfMonkey

[Dave Baumann]

A couple of points here:

Scanning each vertex in order to tesselate it could be the reason the R200 stalls, that little problem that JC pointed out. So maybe n-patches isn't such a hot feature after all. And may have even been the feature that crippled the R200.

The tessellation unit is something that sits before the vertex shader – if N-Patches aren’t used then it won’t even be called for; i.e. it won’t ‘scan the vertex’

4. That's never going to be a problem. PS 1.4 will only ever be used in some nice demos by ATI (and mighty tasty they are too!) . DX9 and PS2.0 will completely swamp it. I didn't really see the point in ATI investing the time in that at all.

ATi developer support have been investing in it – they even went to the trouble of adding PS1.4 into the Lithtech engine themselves, so they said at last years ECTS. There was lots of talk of NOLF2 so its going to be interesting to see if that uses it. There have been a couple of other developer who have talked about using it as well.

5. As the index of this site shows, nVidia may finally be getting their thumb out of their ***es and concentrating on Aniso quality for the latest driver release. Hi res. game play with good Aniso and 4x FSAA that'll be fun (Dungeon Siege can only get better).

I’m sure the performance will go up but I don’t think its going to fundamental change how they are doing it so they are operating within certain confines; I don’t think its going to end up at 8500 speed doing it.

[Sharkfood]

1. In what way is the FSAA IQ better on the Radeon. Any high level of FSAA slows the Radeon down too far to make it any use.

Same with the GF3 and GF4. As neither card has "FSAA" but instead "HRAA", you are technically specifying modifications to IQ that the GF3/4 isn't performing (namely texture antialiasing) so FSAA on the 8500 and HRAA on the GF3/4 are two opposing features that cannot be directly compared.

NVIDIA did the right thing though. They have carefully labeled their IQ enhancement technologies away from the standard naming conventions of previous knowledge. Coining "HRAA" or "Accuview" rather than "Full-Scene Antialiasing"- I'd say ATI needs to do the same with their anisotropic filtering-feature.. like "SharpIQ" or something since it does more (and less) than simply adding additional texture samples/filtering (different method, LOD shift, etc.etc.).

In essence, I could make a videocard today that had about the power of a GeForce2, put a checkbox in the display properties labeled "FSAA" and all it did was perform a 2x2 box/post filter and did so with no performance hit. All the Anands and Tom's of the world would publish their fancy AA performance graphs and all things would be equal, right?

It's only going to get worse as more and more different/innovative methods to improve IQ are devised in consumer 3D hardware. If it means an end to Toms/Anand fancy graphs throwing totally incomparable IQ as if "equivalent", I'm all for it.

[Chalnoth]

Originally Posted by Sharkfood

Even if comprehensive testing is performed, it's readily apparent these "hidden/unsupported" registry entries arent functioning properly in Direct3D. Using either tool and verifying the registry settings *they think* are correct for this rumored/unsupported functionality, you see a small benchmark change, but NO change in visual quality. Is this a supported function in your book?
http://shark_food.tripod.com/nfs/nfs.html

Yes, it is true that there is no official driver-level forcing of aniso, but you can enable aniso through some games (Not many have the option, unfortunately...but at least most games today have an option for trilinear...many games don't even have that...). Additionally, the aniso *is* there and *is* working through the reg hacks (I actually use NVmax...though probably not for too much longer...). And, unlike the site claims, there is indeed a difference between 4x and 8x in those screenshots. I didn't even have to look that hard...one swap between the images in different windows made it obvious. Still, the difference will certainly not be seen in all situations. Remember that the max degree of aniso is only applied in situations where it is needed, and not all scenes need the higher degrees of aniso (which is why nVidia's 8-degree is frequently compared to ATI's 16-degree...there simply aren't many surfaces that need 16-degree aniso).

[Sharkfood]

...). And, unlike the site claims, there is indeed a difference between 4x and 8x in those screenshots.

Would you mind pointing out *where*?

The Quake3 shots were offerred as a control- which means those do indeed show a visual difference. I am unable to see *any* difference whatsoever between Morrowind and NFS at 4x->8x... nor anything else in Direct3D for that matter.

[SvP]

In morrorwind shots there is a difference between no-af and 8x-af shots. The first small "concavity" seems a little bit clearer ...

[Crusher]

You know, the talk about texture compression on the GeForce being "broken" seems grossly exaggerated to me. I've been using a GeForce 2 GTS 32MB card for two years now, and while I'll be the first to admit that the sky in Quake 3 has always, and probably will always, look like utter crap with texture compression turned on, I've seen screenshots posted in other threads here that are just horrible. Looking at these screenshots, even I would be turned off from an NVIDIA product, if in fact that is what the game actually looked like.

The truth is, as bad as the sky looks in Quake 3 with texture compression enabled, at no time is it even close to the level of degredation shown in these dubious screenshots. Even when I've tried to make the game look butt-ass ugly (320x200x16, 16 bit textures, TC enabled, etc.), I can't even come close to the gut-wrenching sights depicted by the screenshots I've seen here. And there is another side to the issue as well... these screenshots are used to try and show how much better other manufacturer's products are compared to NVIDIA's when it comes to texture compression. However, the screenshots from the competing products doesn't look any better than the typical scene I'm used to seeing on my card. In all your arguing about which is better, you forgot the simple fact that the sky in Quake 3 with texture compression enabled looks like shit no matter what. Quake 3 is an old game, and while I have nothing but respect for John Carmack, it seems you all have forgotten the possibility that the type of texture compression used in Quake 3 is old, ugly, and meant strictly to improve performance. It was never meant to look good.

In contrast, I urge you to look at a little game that I rarely hear anyone on these message boards mention--EverQuest. I assume that the main reason this game isn't discussed is that it is old, and the code is so hidden that you can't tell what it's doing. I'm not going to stand here and say that it's a graphical wonder either, it's certainly not. It does, however, allow you the option of using texture compression. It doesn't say what type of compression it's using, and perhaps one of you can figure that out, but I will say that on my GeForce card, you'd be hard pressed to tell the difference visually speaking, between having the texture compression enabled or disabled. When running in 32 bit color, the sky is seamless and without banding. The latest expansion includes high resolution textures for the older areas of the game as well, and those all look pretty damn good, even with texture compression.

Which brings me to another concern I have...

I have never programmed with OpenGL, and I'm not familiar with which extensions are a part of the API, and which are added to it by the different manufacturers and require hardware-specific function calls. I have worked some with Direct3D, however, and from what I've seen most, if not all of it, is completely abstracted from the hardware manufacturer. You call DrawPrimitive() and it draws a primitive, and it's up to the hardware driver to implement it correctly. I find it a little hard to believe that a software programmer using D3D can implement something that works properly on an NVIDIA card, but doesn't work as well on an ATI card, and it was being caused by their code. I would go so far as to wonder how it would even be possible to tailor to one type of card in Direct3D. Even if it were possible, how likely would it be to occur? Imagine the lengths someone would have to go to to pick and choose so many specific routines to make one card perform considerably well compared to another.

I think a more likely scenario is exactly the opposite. That is when an average developer creates a game using only the most abstract, basic code possible, fully utilizing what Direct3D provides them. I could very easily see how this type of situation would show a drastic difference in perofrmance and visual quality between two different video cards, due to their different (possibly bugged) implementations of these functions. In fact, I wonder if the only reason we don't see this kind of difference in all video games, is because the more capable/talented developers take the time to alter their code to work around the problems existing in the generic implementations, implementing certain functions differently for different hardware in order to and balance out the performance disparities.

[Sharkfood]

SvP-

there is a difference between no-af and 8x-af shots. The first small "concavity" seems a little bit clearer ...

The post read as:

there is indeed a difference between 4x and 8x in those screenshots. I didn't even have to look that hard...one swap between the images in different windows made it obvious.

I am hard pressed to find *any* difference between 4x and 8x in the NFS or Morrowind shots whatsoever... nonetheless "obvious" ones. Would you disagree?

Crusher-

In contrast, I urge you to look at a little game that I rarely hear anyone on these message boards mention--EverQuest. I assume that the main reason this game isn't discussed is that it is old, and the code is so hidden that you can't tell what it's doing.

Oh my GOD! Don't even get me started on Everquest. NVIDIA cards have always had an absolutely horrible time with the texturing in EQ. Where were you a year ago when I was posting V5, ATI and GF3 shots of EQ??? It's true some of these issues have been fixed in Luclin as the newer higher detail textures have been "nerfed" to disallow the compression problems, but prior to the high-detail Luclin textures of recent, it was absolutely GHASTLY to play this game on my GF3.

The borders near texture boundries were blocky, 2x2 and 4x4 pixel squares that caused them to line up incorrectly. The "blotches" of brown to white never lined up correctly in Everfrost or similar zones and it was a god aweful mess. Not to mention the "black pixelated" polar bear skins from disgusting errors in the TC.

EQ was the "poster child" for what is wrong with NV+TC for the longest time. It's just a good thing they completely revamped ALL the textures with Luclin, and did so in such a way to address faultering points in NV texture compression... as the textures before hand were near flawless on every card EXCEPT the GTS/GF3.

Cheers,
-Shark

[SvP]

Would you disagree?

No, because there is no difference between 4x and 8x shots. And if there is, the dust on my screen has greater impact on difference between 2 shots

I misinterpreted your last statement and thought you were talking about "af in Direct3D in general", but you were talkkig about "4x af -> 8x af in Direct3D in general".

[Sharkfood]

No, I'm talking about having working, supported anisotropic filtering in Direct3D.

Not some registry "hack" with "unsupported, undefined behavior" much like I've had for the past year with the GF3 and now the GF4. There have been very similar issues with the "hacked, unsupported, undefined behavior" registry tweaks with anisotropic filtering in Direct3D and will likely continue to be until the feature is ready... surely it is not at current.

THAT was the point- it's not ready for primetime and never has been. You can poke registry values, download tweakers/hack toys, and run benchmarks until you are blue in the face. It means nothing and you are simply shooting in the dark. This is *not* what I define as a "supported" or "delivered" feature- nor could I fathom someone considering it as such.

Ciao!
-Shark

[Crusher]

but prior to the high-detail Luclin textures of recent, it was absolutely GHASTLY to play this game on my GF3.

Then I can only assume you did something to your video card or driver settings to cause it, because I've been playing EQ for almost 3 years, and it's never been "ghastly". The color banding in the sky used to be terrible, but that was because of the 16-bit color limitation... it didn't look any worse on my GeForce 2 than it did on my Voodoo 3. With the option to use 32-bit color, that's gone. The only other noticably-bad image problem I have seen is with FSAA enabled. Their overlay GUI, which was written back in the GLIDE days and doesn't appear to have been updated much since then, has never looked great with FSAA enabled. When the first FSAA enabled GeForce drivers came out, the GUI would bleed and blur all over the screen. I suspect a good part of that was because of the drivers at the time, but I think part of it has to do with how they're rendering the GUI. Now, about the only remanants of that is a slight blurring of the text on the default buttons. At this point I could go into an hour long rant on their inability to prevent the rendering of polygons that are obviously out of view, and their aggrivating insistance on forcing you to use some of the new "high detail" models that look like they were designed by a blind person with 7 fingers, and because of the ammount of memory the models and animations consume, no normal computer on earth is capable of running the game adequately, let alone with FSAA enabled... but I'll try to restrain myself from going off on that tangent more than I have.

[Sharkfood]

Then I can only assume you did something to your video card or driver settings to cause it

lol. There was absolutely nothing "done wrong" as it was posted on their forums at least a dozen times a month concerning these very issues. In fact, VI even went so far as to declare TC should be left OFF when using NVIDIA videocards (by name). lol.

The color banding in the sky used to be terrible, but that was because of the 16-bit color limitation... it didn't look any worse on my GeForce 2 than it did on my Voodoo 3.

We aren't talking about 16-bit banding. lol. Would you label Q3 skies as 16-bit banding too? hehe. No, like I said- the blatant and obvious *errors in textures*, as in the example I already gave (black-pixel splotched polar bears, which were supposed to be all white, but on NVIDIA cards had a collage of random black pixels on them).

Well, and your statement about the V3 given it's post-filter having *no* effect at 16-bit supports the mythical nature of claims already, so there is really little point to continue...

Their overlay GUI, which was written back in the GLIDE days and doesn't appear to have been updated much since then, has never looked great with FSAA enabled.

And if you were to venture outside of one particular manufacturer's version of videocards, you'd also see this is a platform specific issue. It work(ed) marvelously with the V5, as well as the 8500 with AA enabled.

, no normal computer on earth is capable of running the game adequately, let alone with FSAA enabled... but I'll try to restrain myself from going off on that tangent more than I have.

Not to defend the obviously piss-poor coding on the part of Verant, I play it quite comfortably on an 8500 at 1024x768x32, all Luclin models enabled, 2xQAA, spell particles on and spend lots of time on Luclin as well as in larger guild raids of 60+ people in ToV and ST... Sure, it will occasionally dip to 18-22 fps, but for the most part the game remains totally playable. I can't say the same for my GF3 or Ti4600 though- not to mention the completely unreadable chat window when AA + AF is enabled.

Cheers,
-Shark

[jb]

1. Anisotropic filtering. The GeForce3/4's implementation is clearly more complete, supporting all angles of surface as well as trilinear filtering.

2. FSAA. The GF3/4's FSAA far exceeds the performance of the Radeon 8500's, due to the use of a superior method. (Update: Yes, the 8500's FSAA does look better in certain limited situations, particularly when alpha tests are used, but those situations are rapidly decreasing, as games are starting to use alpha blends instead. I do know that Morrowind uses them, and alpha blends are very apparent in the UT2k3 shots we've been seeing).

The problem I have is you say one is more complete thus better which is fine. But then the other one which is less complete and has known issues wins because its faster? I dont get it. Limited cases? Couldn't you say the same thing about ATI's looks worse only in limited cases? Sorry but I think its a double standard. Your forgeting that ATIs FSAA was suppose to be programable by the devloper. And if it every will work that way, then that would be neat. Also dont forget that the alpha blend does blur a bit

3. Pixel shaders....

How many more quote do you need to see from develeopers saying they enjoy the power and flexibility of PS1.4? Like it or not that is an advatage for the ATI 8500.

4. Truform...

And now we have a feature that is actually used in games that requires developer support. I have seen that we have 15+ games that use turfrom now with plenty more on the way. Dose not matter to the gamer which method is better. Alls that maters to the gamer is that they can see a difference that makes the game look better for them. Sure RT pathes or other froms of HOS my have more advatages, but who cares until they are in a game that makes use of them.

[Sharkfood]

Crusher-

Yes! I happen to have a couple old shots of pre-Luclin EQ on my HD from events of days past. Some that show at least the mipmap distortion that occurred prior to the Luclin trilinear/new textures!


You can see these two spots that 2x2 or 4x4 distortion that occurred during mipmapping. It was indeed ghastly. I focused in on it with these two parts. I'm still digging to see if I have any shots of polar bears... there must be one here somewhere.

[Simon F]

Originally Posted by OpenGL guy

Applications do funky things... developers get these weird ideas in their heads that make life for driver developers tough. Best we can do is take care of the problem on a case-by-case basis unless they fall into a general theme.


Now, you may say that the application can do whatever they want as long as they follow the rules of the API. Well, that's true, but if you want things to work well, then it helps to put some effort into optimizing your code so that you don't do silly things.

Hear Hear! Rarely are such true words spoken. Other's that are a "joy" are multiple "begin scene, end scene" calls per scene (err, hello?) and marking fully opaque textures as transparent.

[Doomtrooper]

4. That's never going to be a problem. PS 1.4 will only ever be used in some nice demos by ATI (and mighty tasty they are too!) . DX9 and PS2.0 will completely swamp it. I didn't really see the point in ATI investing the time in that at all.

Again for sake of being somewhat objective, for a DX9 part the card must support PS 1.0-2.0 to my understanding, so to say Ps 1.4 will never be used is wrong
We have not seen what Unreal Tournamanent supports for shaders as Sweeny said it s really a Dx7 engine with Dx 8 features overlayed into it.
That comment about demos is simply wrong Monkey....NWO is a PS 1.4 game with over 100 titles being released over the next year supporting 8500 features, be it shaders or truform (MANY titles already support truform).
http://www.ati.com/playati/gamemaker/nwo/index.html

Q: What feature of the Radeon 8500 do you like the most? And why?

A: That would be the 1.4 pixel shaders without a doubt. This is still beyond what any competitor has and really makes a difference. There is also a certain smoothness to playing on the 8500 that I like.

[Doomtrooper]

4. Truform. If you really like technological arguments, then Truform isn't really any more advanced than the RT-patches available in the GeForce3/4. The only thing that the GF3/4 are missing is the control point generating hardware (The 8500 generates control points from normals, and then uses the same bezier patches that you would use on a GeForce3/4 for interpolation). I've also argued that I actually prefer RT-patches, as they are far more flexible. Obviously RT-patches simply cannot be implemented into existing games, and backwards-compatibility isn't trivial to implement with them, but they are a significant step forward in implementing very high-poly scenes (largely since once the minimum hardware is assumed to have them, geometry LOD becomes absolutely trivial).[/quote]


Will you say the same thing about Nv30 or will it be 'ok' because Nvidia supports n-patches with Nv30...or how about displacement mapping...will you also say thats 'easy' to implement in hardware and really 'no big deal'.
If a feature can bring more realism to a game that is done in hardware I really can't see what your arguement is..developers like it and last time I looked you were not coding for a developer

[Typedef Enum]

As an aside...You want to talk about a joke of a test release? NWO had to be the dumbest release in quite some time.

I still can't get the stupid thing to work correctly, and I know I'm not the only one. I went back to VoodooExtreme/ShackNews, just to see if I was the only guy having problems, and saw a slew of issues. I think Matt @ 3dgpu even stated on their front page that he couldn't even get the thing to run.

[Doomtrooper]

Originally Posted by Typedef Enum

As an aside...You want to talk about a joke of a test release? NWO had to be the dumbest release in quite some time.

I still can't get the stupid thing to work correctly, and I know I'm not the only one. I went back to VoodooExtreme/ShackNews, just to see if I was the only guy having problems, and saw a slew of issues. I think Matt @ 3dgpu even stated on their front page that he couldn't even get the thing to run.

A great example when a game is developed and optimized on a certain platform..besides some weird shadow glitches runs smooth on my 8500, I do remember Dronez having graphic issues and Aquanox on a 8500...hmmm..refer to Jeff Royles comments

[Crusher]

Well, I can't say I recall seeing anything like that in EQ, but my memory isn't perfect and you claim that was from a year or so ago. It looks to me like it's over-compressing the mipmaps in your screenshot... more like jpeg artifacting than noise. Or perhaps you were using a lower quailty mipmap setting in the D3D driver settings, and that caused some problems. If I could find a place to upload some images to, I've got a couple of screenshots I just took with texture compression on and off... it's pretty clear to me that it's working fine, with no noticable difference in the image quality. Perhaps with the new textues they're using mipmaps generated on the fly, or maybe they're just using a different compression format. I have a hard time believing the texture itself makes much difference (apart from the color format of course). If they're using the same texture compression format, they should have the same artifacts, regardless of size or style.

[Chalnoth]

Originally Posted by jb

I dont get it. Limited cases? Couldn't you say the same thing about ATI's looks worse only in limited cases? Sorry but I think its a double standard. Your forgeting that ATIs FSAA was suppose to be programable by the devloper. And if it every will work that way, then that would be neat. Also dont forget that the alpha blend does blur a bit :)

Alpha blends are just plain superior to alpha tests. The difference is particularly obvious when lots of alpha textures are used in the same scene (such as when there's grass or something of the like...). All that the alpha blending is doing is applying the usual texture filtering to the edges of the textures as well. Also, alpha blends are vastly superior to alpha tests when viewed at large distances, particularly on older hardware that doesn't support anisotropic filtering. The only bad thing is that alpha blends aren't always trivial to implement in software (they aren't order-independent, and thus alpha textures must be drawn last...in back to front order).

And if you think it odd that I think this is a limited case that can generally be ignored, think of it this way. Multisampling is most certainly the way FSAA is going. I'd be rather suprised if the R300 didn't support multisampling AA, actually. The NV30 most certainly will.

[Crusher]

A great example when a game is developed and optimized on a certain platform

Again, I don't see how you can make such claims so easily... it's not trivial to bend Direct3D to a specific video card, and I can't imagine too many developers restrict themselves to one card when they're testing their code. If you create a vertex buffer, set a directional light, set a texture, and draw the triangles in Direct 3D, and it turns out to be faster or look better on Card A than on Card B, how is that the programmer's fault? You seem to be suggesting that they buy computers that only have NVIDIA cards, and use some special hidden NVIDIA function calls inside Direct 3D. That's getting to the point where you have to wonder why they even use an API if they're going to try and get that specific with their code. As I said before, I think it's much more likely that if a game has a drastic performance change going from one card to another, it was made using just the basic rendering calls in a way that should theoretically work fine on anything... and they are just content with leaving it that way, whereas in some situations, developers want to equalize performance more, so they manipulate their code to get rid of the performance difference.

For example, say you have two cards that can both support vertex buffers with 16,535 verticies. Developer Alpha and Developer Beta are both making games, and plan to support both of these cards. They both make vertex buffers that have 16,535 verticies and render them, and for both developers it turns out to run twice as fast on one card than the other. Maybe Developer Alpha just concludes it's an issue with the driver, and since they're behind schedule already, they choose to leave the code as it is rather than spend days trying to troubleshoot someone else's problem. Developer Beta has a little more insight into what the problem could be, and a little more time to work on fixing it. They might try to split the vertex buffer into 64 smaller vertex buffers, and in doing so find that it brings the performance of the second card to roughly the same level as the first card. It might have been a hardware issue where the card can't render large vertex buffers efficiently, or perhaps it was a driver issue as Developer Alpha thought. When the games are released, the public might look at both games and accuse Developer Alpha of tailoring their code to one card, when in fact it was Developer Beta who tailored their code. Then, after a while, a driver bug is found and fixed in the second card that was having the performance problems. With the new drivers, Developer Alpha's game runs much like Developer Beta's game. Since the method Developer Beta used to skirt the problem still works, they don't need to patch their game, so the public never knew they did anything to begin with. Their code is still split to support the two cards differently, and it might not be quite as efficient to use 64 buffers instead of 1, but they're content.

Or, maybe it's as you say, and the lazy developers just tailor everything they do to the one and only video card they ever work with, and don't give a damn about the other cards out there. None of us will ever know for sure, but I think my theory sounds a lot more down-to-earth.

edit:

That's not to say it's never happened... I doubt people who developed tech demos (e.g. DMGZ) for NVIDIA cards cared too much about whether or not things were working properly on other cards. Likewise, apart from making sure things were at least getting rendered, I doubt the guy who wrote the VillageMark program spent a large ammount of time making sure it would run as fast as possible on anything not made by Imagination Tech. Same for ATI, Matrox, S3... but in terms of actual games, or truely independent 3rd party benchmarks, I don't see there being any incentive to ignoring one card over another, or intentionally making your program run better on a particular card.

[jb]

Or, maybe it's as you say, and the lazy developers just tailor everything they do to the one and only video card they ever work with, and don't give a damn about the other cards out there. None of us will ever know for sure, but I think my theory sounds a lot more down-to-earth.

Every play a game called Tribes2 on a non-nVidia card? What about the trying to play the oringal Unreal (or tribes) on anything other than a 3DFX card? Thats 3 games that we designed to run on one brand of card and had horrible issues on other cards. Developers would love nothing more to have the time and knowledge to ensure that every card works eqaully as well. But fact is most of them just can not do that....

[Dave Baumann]

Likewise, apart from making sure things were at least getting rendered, I doubt the guy who wrote the VillageMark program spent a large ammount of time making sure it would run as fast as possible on anything not made by Imagination Tech.

Not necessarily the case - I don't know how many times this has been said on these forums before but the guy that wrote Villagemark even took the trouble to contact NVIDIA's dev support to ask their prefered method of vertex buffering when using T&L and implemented that.

[Crusher]

Never played Tribes 2, but I've played both Unreal and Tribes on my GeForce 2, and they both run quite well these days. However, I don't see how that relates to this argument, since we're not debating whether or not a GLIDE game that is ported to another API can run as well as it did on a 3dfx card. We're talking about games developed under a single API running on different cards that all support that API, yet somehow being tailored to one card manufacturer over the others. That wasn't possible with GLIDE.

And kudos to the programmer of Villagemark. Makes me feel better about it being labeled a benchmark and not just a tech demo. My argument still stands without that example, though. I'll agree there is some basis for assuming tech demos are designed for specific hardware, but I don't think most games or developers do that, and I think it's a pretty hefty accusation to make with no proof. The more I study 3D programming, the more credit I have to give the programmers out there. It's not something an idiot can do, and I think it's unfair to accuse them of making mistakes only an idiot would make, and it's equally unfair to claim they're favoring a particular video card when doing so can only hurt their sales and reputation. The days of being able to sell a video game that only runs on one type of card died with the Voodoo 2.