[quake3] How far can SGI MIPS, Sun SPARC, and LinuxPPC go?

Zachary Slater zakk at timedoctor.org
Thu Apr 10 08:12:48 EDT 2008


Patrick Baggett wrote:
> First, a little sheepish about the being considering the "SGI MIPS" 
> interest for IOQuake3...

You get a gold star.

> 
> I personally think IOQuake3 shouldn't drop/compromise support for older 
> platforms in favor of new graphics candy. I figured IOQuake3 was focused 
> on being a stable, mature, and bug fixed version of retail Quake3. It 
> certainly does so in the backward compatibility. I just don't care for 
> new graphics. Trying to retrofit new graphics onto what was designed as 
> a fairly fixed function (at the core) graphics engine kind of seems a 
> step in the wrong direction. Some people may enjoy seeing stuff like 
> that done, but I'm just trying to have something to play with. Quake 3 
> everywhere, basically. SGI's graphics cards weren't really designed for 
> heavy texturing, so these games are usually fill-limited -- they're 
> optimized for things such as line drawing, NURBS eval (max evaluators is 
> 36, compared to GL's 8), and display lists (actually compiles some 
> display lists into GPU microcode.) Quake3 is pretty taxing on them as is.


Completely agree though I still want a pluggable renderer. Older 
hardware/geriatrics like me can stick to the base graphics. Then when I 
want to play Monk's new all-singing-all-dancing topless version of rq3, 
I don't mind seeing some new graphics. Though I kinda already miss the 
blockyness of quake2's software renderer + aq2...

Definitely not the jigglyness in the gl renderer though. That was terrible.


> As far as extending IOQuake3 to use things such as IPv6, SMP, I think 
> that is a great idea. IRIX supports IPv6, and I've got a number of 
> dual-processor machines that I wouldn't mind testing with. I've been 
> working to optimize and trim Quake specifically for IRIX actually 
> (dubbed unsurpisingly, irixquake), and some of the things I've been 
> researching include running sound/sound mixing code on its own thread. 
> It isn't fully complete right now (bit hacked, actually), but for 
> software quake, the benefits are decent enough. This isn't really an 
> issue for devices that do hardware/kernel mixing, or under Win32 where 
> DirectSound automagically creates a thread for you, but when you're 
> running on a dual processor 250MHz machine, it helps to use every ounce 
> of CPU you have available. Also, the standard sound card in most of the 
> SGI machines does no mixing/spatialization in hardware. It's just a DMA 
> device, really.

I wish I still had those indies I used to have :(

Better SMP will be coming with SDL 1.3 (Ryan Gorrodododon I'm looking at 
you!)


> Patrick Baggett
> 

-- 
- Zachary J. Slater
zakk at timedoctor.org
zacharyslater at gmail.com



More information about the quake3 mailing list