> On the other hand it would be cool to have a map format that does not require pre-processing like BSP space-partitioning.<br><br>Hmm, I think that'd be something for me, because in the raytracing patch we're already building a very optimized acceleration structure similar to the BSP in a few seconds at load time. It's a kd-tree: splitting planes are axis aligned, which makes it a special form of a BSP.<br>
<br>In radiant there's the option to build a low-quality bsp for "map-debugging". Does anyone know if that sets a flag in the map header we could react to and build a BSP at runtime? Any other ideas?<br><br>
Stephan<br><br><br><div><span class="gmail_quote">2008/4/10, Robert Beckebans <<a href="mailto:trebor_7@gmx.net">trebor_7@gmx.net</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well I think adding C++ to the Q3A architecture just f**** up everything.<br>
<br>
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)<br>
<br>
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.<br>
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.<br>
<br>
On the other hand it would be cool to have a map format that does not require pre-processing like BSP space-partitioning.<br>
<br>
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.<br>
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++.<br>
<br>
I think even the an id Tech 5 style renderer with virtualized textures can be implemented without too much trouble in pure C.<br>
The problem are the tools to create the content that really need to fit to the engine with all required aspects.<br>
<br>
Chris do you have a demo of your Nvidia Scenegraph based renderer? I would like to try it.<br>
<br>
Chris Bunting schrieb:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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, <a href="http://q2e.svn.sourceforge.net/viewvc/q2e/OverDose/code/OverDose/renderer/r_shader.cpp?revision=228&view=markup" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://q2e.svn.sourceforge.net/viewvc/q2e/OverDose/code/OverDose/renderer/r_shader.cpp?revision=228&view=markup</a> <br>
<br>
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.<br>
<br>
Chris<br>
<br>
<br>
----- Original Message ----- From: <<a href="mailto:monk@rq3.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">monk@rq3.com</a>><br>
To: <<a href="mailto:quake3@icculus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">quake3@icculus.org</a>><br>
Sent: Thursday, April 10, 2008 3:48 PM<br>
Subject: Re: [quake3] How far can SGI MIPS, Sun SPARC, and LinuxPPC go?<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'm not on the ioq3 voting review board<br>
</blockquote>
<br>
Yes, you are.<br>
</blockquote>
<br>
Oh geez, you let SPARC users vote?!? ;) <br>
</blockquote>
<br>
<br>
---<br>
To unsubscribe, send a blank email to <a href="mailto:quake3-unsubscribe@icculus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">quake3-unsubscribe@icculus.org</a><br>
Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50</a><br>
<br>
<br>
</blockquote>
<br>
<br>
---<br>
To unsubscribe, send a blank email to <a href="mailto:quake3-unsubscribe@icculus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">quake3-unsubscribe@icculus.org</a><br>
Mailing list archives: <a href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50</a><br>
<br>
<br>
</blockquote></div><br>