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

[monk at rq3.com]

>>     I'm not on the ioq3 voting review board
>
> Yes, you are.

Oh geez, you let SPARC users vote?!? ;)


>> First, a little sheepish about the being considering the "SGI MIPS"
>> interest for IOQuake3...
>
>You get a gold star.

I like how he then lists, in great detail, some (not even all!) of the SGI
hardware he uses... I wonder whatever happened to that SGI engineer who
ported Q2 and part of Q3 to Irix.  Richard Hess or someone like that. 
Then he disappeared...

Man, where's the guy working to port ioq3 to the BeBox and BeOS R5?!? 
Jens Kalmark I think he was...


Anyway, so the main limitations will be with the OpenGL support for SPARC
and MIPS and the video hardware itself?  Linux/PPC (see what I did there?
happy now?!? ;) seems to be only limited by drivers, so that's probably
not worth worrying about too much.

If I read you guys correctly, things like UTF support and skeletal model
support won't be an issue.  It's mainly the more intense graphics that
would be a problem.

So if ioq3 were extended with some type of selectable/pluginable renderer,
the "legacy" renderer would work fine on the old hardware (as fine as it
does now, I guess) and those with newer hardware could elect to use a more
modern renderer, if they wanted to.  Extend, rather than replace.

Lord knows I don't think porting ioq3 to c++ and shoving Horde3D into the
engine is what anyone wants to do.  That seems more like a programming
investigation into rendering techniques rather than an attempt to
modernize some aspects of an engine.  All that talk about recreating
everything and going Windows only... meh.

Chris, I think the content creation toolchain isn't a huge issue,
platform-wise.  Most artists are going to need plugins/exporters for their
current platform of choice, be it Windows, MacOS, or Linux.  Whatever fits
with their current workflow.  Just because ioq3 doesn't work with AmigaOS
4 doesn't mean that a modeler creating content on that platform can't
create content that works with ioq3.

I appreciate the work and research you've done into 3D rendering tech and
tools, but I don't know if that stuff is directly relevent to ioq3.  Most
Q3 content creators that I know of (rq3, urt, nsq3, wq3, etc.) create
stuff in separate tools like gtkradiant for mapping and commercial
products like lightwave, maya, and 3dmax for models and animation. 
Integrating the tools or hooking them into the engine doesn't seem to be
necessary.

I also don't know that games are all going to wide-open outdoor terrain
and it's therefore imperative that ioq3 rush to support it.  Certainly, if
there's a need for that for someone looking for a game engine, they have
choices other than ioq3.  They could look to the Tribes engine, for
instance.

I don't think anyone here wants to rip out the ioq3 renderer and make it a
GLSL 2.0+ only engine.  Extend, rather than replace.  Maybe the SGI guys
can't run whatever new renderer gets added to ioq3, but they should still
be able to fallback to the existing, working renderer.

My thoughts, at least.

Monk.