First, a little sheepish about the being considering the "SGI MIPS" interest for IOQuake3...<br><br>As far as graphics go, I've got 3 main systems I am interested in:<br><br>a) Indigo2 R10000 with Max IMPACT graphics + 4MB texture memory. RAM = 1GB and CPU = 195MHz<br>
b) Octane R10000 with MXE graphics (also 4MB texture memory). RAM = 1.75GB and CPU = 250MHz<br>c) Octane2 R12000 with V8 graphics (108MB texture memory). RAM = 2.0GB and CPU = 350Mhz.<br><br>Anything less than a) probably won't run it at all. Anything more than c) will definitely run it well, as is.<br>
<br>The MXE graphics, which have 4MB of texture memory and still play IOQuake3 at decent FPS, but it isn't exactly a beautiful 60 fps all the time as you can imagine, something more along the lines of 15-25FPS at 800x600. I actually haven't tried the Indigo2 Max IMPACT yet, but it is the same as MXE just with a slightly slower bus and 17% less clock speed on graphics card -- likely to be playable but not super. The V8 works great ~40-60FPS at 1280x1024@30bpp, depending on scene. It's bigger brother on a Fuel (R14000 @ 600MHz, 1.5GB RAM), the V12, plays extremely well in my opinion. I've got another Octane2 with V6 for medium range testing, and it seems to work well too. As far as servers go, I run IOQuake3 ded on Challenge L with 12xR10000 @ 195MHz and it works great.<br>
<br>Note that none of these support anything more than OpenGL 1.2 in hardware. No shaders, no multitexturing, nothing. As you can imagine, fill rate at the absurd resolutions that SGI machines love such as 1280x1024 becomes a real problem.<br>
<br>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.<br>
<br>As for the future:<br><br>My steps are small, but I've been working on a tiny library called libMIPS that basically is a runtime in-memory assembler. I was going to take some select instruction generation functions and add a MIPS dynamic compiler (vm_mips.c) . For example, to create a function to load r4 with the value 0xAABBCCDD, I'd write:<br>
<br>code32[0] = MIPS_lui(4, 0xAABB);<br>code32[1] = MIPS_ori(4, 0xCCDD);<br><br>function = (func_ptr)code32;<br><br>function(); /* execute these instructions */<br><br>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.<br>
<br>Vincent, I also have a 4x400Mhz Sun E420 + Expert3D (128MB) + 4GB RAM if you need some low end testing. I've compiled IOQuake3 using your makefiles (though I used Sun's C compiler, not GCC since GCC/sparc is pretty meh). My preliminary tests (aside Solaris's OpenGL bugs) show performance to be similar to SGI's old stuff. I run in a 800x600 window. <br>
<br>If I didn't answer any questions, please let me know.<br><br>Patrick Baggett<br><br><div class="gmail_quote">On Wed, Apr 9, 2008 at 7:28 PM, <<a href="mailto:monk@rq3.com">monk@rq3.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is mostly directed to those who have access to these platforms or<br>
know them well enough in relation to ioq3. I'm guessing...<br>
<br>
tjw and Mattias Nissler = LinuxPPC<br>
Vincent = Solaris SPARC<br>
Patrick Baggett and "Mare" = SGI MIPS<br>
<br>
You guys have probably seen some of the recent discussion about improving<br>
ioq3 in terms of graphics and other features. What are your thoughts?<br>
I'm assuming those listed platforms aren't going to have performance<br>
issues with things like UTF support and skeletal model support. But maybe<br>
some issues with, say, the semi-recent framebuffer work that added bloom<br>
effects?<br>
<br>
How much does ioq3/q3 chug along currently, 10 fps, 60 fps? Can your<br>
hardware handle stuff that will make the game look more pretty, or are you<br>
about your limit for pushing pixels?<br>
<br>
If the ioq3 devs decide to eventually set a cutoff for features as a<br>
legacy release, it'll probably be you blokes who can tell everyone what's<br>
practical to include as features and what won't work at all.<br>
<br>
Monk.<br>
<br>
---<br>
To unsubscribe, send a blank email to <a href="mailto:quake3-unsubscribe@icculus.org">quake3-unsubscribe@icculus.org</a><br>
Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50" target="_blank">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50</a><br>
<br>
<br>
</blockquote></div><br>