[quake3] Rendering System..

[Robert Beckebans]

Well I think adding C++ to the Q3A architecture just f**** up everything.

That is what I figured when I rewrote Quake2 into C++ before I began 
with the Q3A source. Or just have a look at Overdose. It is way more 
easy to break things completely instead of extending it. The team got a 
C++ coder who thought rewriting in C++ is fancy and Overdose is more 
broken than before. (I think it was a good choice not giving him access 
to the XreaL SVN)

First of all you need a renderer for your type of game. I decided to 
keep everything designed for indoor rendering in XreaL like in Q3A.
When you replace the renderer to support terrain rendering like in 
FarCry or Crysis then please don't provide basic level editing support 
with some closed-source world editing tools that break everything. You 
need to care about the network code, (bot code) and first of all 
collision code as well. Well all together I think it is pretty pointless 
to write a cool terrain renderer on top of Q3A if you break everything 
that your engine is not much more usable than a basic map viewer because 
collision detection and entity interactions are completely messed up.

On the other hand it would be cool to have a map format that does not 
require pre-processing like BSP space-partitioning.

I think it is not a problem to add Unreal Tournament 3 graphics to the 
Q3A engine with a complete engine overhaul like I did.
The key problem is really Q3A shaders language which was a very early 
attempt for material scripting in games at all. I think it is not 
possible to support it completely with a modern renderer design. However 
it is not a problem to write a powerful renderer without C++.

I think even the an id Tech 5 style renderer with virtualized textures 
can be implemented without too much trouble in pure C.
The problem are the tools to create the content that really need to fit 
to the engine with all required aspects.

Chris do you have a demo of your Nvidia Scenegraph based renderer? I 
would like to try it.

Chris Bunting schrieb:
> 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?!? ;) 
>
>
> ---
> To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
>