[stormy]

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.

Just to add to your information Ian, in regards to Quake 3 - as you said it is a 'quick and dirty port' with zero optimisation. There are two parts to optimisation for the game Quake 3 (which was written differently to Quake2) Firstly it is the QVM, the Quake Virtual Machine, which does all the background tasks and game logic. This QVM can use a native MIPS compiled version, but on the versions we have it hasn't been compiled and it 'drops back' to emulation mode. So that breaks SMP (multi processing) which is usually enabled with r_smp 1 in the config file. So we don't have any SMP available.

Then we have renderer specific optimisations, as you mentioned there aren't any. The Vpro has a terrible bug with the Quake 3 Skyboxes which absolutely *tanks* the fps to single digits. So to be fair in benchmarking, we really should be using 'r_fastsky 1' to avoid the bug in Odyssey hardware. Because benchmarking with that bug is clearly unfair for the hardware. I don't know if the bug is Odyssey driver related, or Quake engine related.

I hope to try and compile a more native and enhanced version of Quake 3, with the help of the Sgug software compiler environment & the help of the guys over on the ioQuake3 forums (They are always eager to help) But I just haven't had the time to dedicate to doing this yet.

For your information, here is a great explanation of how the Quake 3 engine works:
https://fabiensanglard.net/quake3/qvm.php