Rendering System.. Was Re: How far can SGI MIPS, Sun SPARC, and LinuxPPC go?

[Chris Bunting]

Hello,

The talks about a plugin rendering system is the main reason why I've 
mentioned a C++ port. If supporting varied plugin renderers were possible 
with C, we would already have an OpenGL base renderer, OpenGL supporting 
shader 2.0/3.0 and then a DX 8/9/10 renderers.. But it's not worth the 
trouble for a C based engine.

If you are really familier with the Q3 codebase, it takes maybe 60 minutes 
to rip out all of the bot/ai code. It's takes less than 30 minutes to remove 
the small bits of network code. Network code is easlily replaced with 
Rakknet or OpenTNL (GarageGames). But then, with the network code and bot 
code removed, the rest of the code is based around OpenGL and all of the 
hard coding. Most of the Q3 engine is full of opengl calls. The reason I 
mentioned Hord3e is because it's extremely small, offers all of the same 
rendering power and more if you want to use the built in pipelines and such. 
There is also a linux build of Horde3D and also and SDL conversion for 
linux.

There are a lot of options but a plugin rendering system with c instead of 
C++ / Classes / Real plugin support is just going to make it hard. For every 
good idea there is a big drawback it would seem. There are a few commercial 
engines I like but they just cost way to much for a personal project of 
sorts.

It seems there are a lot of people with older systems. So I don't know what 
type of features they can actually support. If I was going to start over 
again, I would replicate only a couple of Doom3 style features mainly based 
around a shader system as this would help give Q3 the rendering results 
simular to COD4. Xreal and Evolution both have a simular shader 
implementaion. But the Quake 2 engine, A branch of Quake 2 Evolved called 
OverDose has a small, clean Doom 3 style shader system, 
http://q2e.svn.sourceforge.net/viewvc/q2e/OverDose/code/OverDose/renderer/r_shader.cpp?revision=228&view=markup

Some sort of shader support is really the only thing that Ioq3 seems to be 
missing. You can do a lot with shaders as there is code for just about 
everything if your OS supports it. Otherwise, you just default back to the 
base renderer if your card/driver doesn't support it's features just like 
stock q3 does.

Chris


----- Original Message ----- 
From: <monk at rq3.com>
To: <quake3 at icculus.org>
Sent: Thursday, April 10, 2008 3:48 PM
Subject: Re: [quake3] How far can SGI MIPS, Sun SPARC, and LinuxPPC go?


>>>     I'm not on the ioq3 voting review board
>>
>> Yes, you are.
>
> Oh geez, you let SPARC users vote?!? ;)