[mapesdhs]

It's worth mentioning that, unsurprisingly, the various Quake ports for SGIs are not remotely optimised for SGI gfx tech. They are, "quick and dirty ports". Who knows what natively written code might be capable of, properly exploiting what each different system can do, baring in mind how different they are (O2 vs. MGRAS vs. VPro vs. REx vs. IRx). Some systems have certain inherant limits, such as texture fill rates on O2, but certain aspects could be better optimised nonetheless, or unique features added (fade LOD on RE/IR would be cool). Still, the results are interesting, but it's hard to know how useful they are. In other words, performance results for Quake3 on SGIs may only tell us how Quake3 as it's been written behaves on SGIs, it probably shouldn't be used as a guide for anything else. This for example was the unfortunate down side of sending an O2 parts kit to Gamers Nexus for assembly review (just for fun really); despite my explaining beforehand about O2's market focus and unique arch, they focused way too much on running Quake1, also missing entirely that the resolution and quality settings they were using were ludicrously high compared to consumer gaming hw of the day (the Indigo2 parts kit review was better).

Alas so far I've not had time to do any Quake3 performance testing, but then it's less applicable than Quake2.

Ian.