Alright so the questions are whether or not we should fork, because it would require us to keep up with the bug fixes etc. from the base ioq3. Also, if we do go through with this, it's almost certain that compatibility will be broken (<i>Or that's what I understood from Robert</i>).<br>
<br>monk gives some good reasons to just extend the base though:<br><br>1) the code would always be up-to-date, no need to merge in fixes<br>
2) you don't split mindshare between the "original" and "new" (marketing<br>
thinking, 'ere? one-stop shopping?)<br><br>So just to be clear, by 'just extend the base', do you mean to just work on ioq3 itself, not fork it or anything but work on it directly? In other words, ditch the whole 'we just want to be the original Q3 engine with bug fixes, optimizations, etc'. For the reasons you mentioned, that would be a good idea. The question then would be, what about all the people who just want the base, original Q3 engine with bug fixes etc., where will they go now? But then again, is that really a problem? How many people actually want that? (<i>Of course we could think of existing projects I guess...</i>) If we work on the base engine itself, it would force people to adapt.<br>
<br>Or we could always just do something like this: get to a point in the ioq3 engine where we can agree we've worked on it enough, and feature freeze it. Then fork it and focus everything on the new engine, while occasionally even patching the original ioq3 engine if need be. If we develop optimizations and other things on the new engine which can benefit and are compatible with the original ioq3 engine, we can patch it. Just an idea.<br>
<br><div class="gmail_quote">On Wed, Apr 9, 2008 at 12:42 PM, Robert Beckebans <<a href="mailto:trebor_7@gmx.net">trebor_7@gmx.net</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;">
<div bgcolor="#ffffff" text="#000000">
I would like to clearify a few things about XreaL because many people
complain about the incompatibility with existing mods assets:<br>
<br>
XreaL was not initially based on the IOQuake 3 project at all. I merged
it later with IOQuake 3 because I don't want to maintain so much
platform dependent code. It is a different project with complete
different project goals.<br>
<br>
Another thing: adding advanced rendering stuff like per pixel lighting,
VBO based scene management (the Q3A geometry per vertex processing is
crap) requires many changes to the shader scripting language that
aren't obvious for most non-OpenGL gurus.<br>
You might be able to hack it together that it works somehow with the
Q3A .shader language but you won't be able to redesign the renderer
with newer rendering techniques without breaking compatibility in a few
ways.<br>
If you compare the material languages of Q3A and Doom 3 then you can
see that Doom 3's material language is designed for a more modern
renderer because most keywords work on a per-object base instead on a
per-vertex base.<br>
You can add per-pixel lighting to the IOQuake 3 renderer while sticking
with the old shader language and get it to work with Q3A's geometry
tesselation at runtime but it will be highly inefficient and slow.<br>
Q3A's renderer design was good when it was released but GFX programming
evolves really fast. Much faster than many other disciplines around
game programming.<br>
The old renderer design distracts many experienced OpenGL programmers
because it is way too CPU bound with todays hardware.<br>
It really does not matter to upgrade to a newer GPU with the old
renderer design. You will be always CPU bound by the geometry
tesselator when you try to put a few custom models into your map with
many polygons. That's usually not a problem when you have a renderer
that uses VBOs in a clever way. It's not clever to update VBOs every
frame like in a very early IOQuake 3 patch. You need static VBOs that
are created at map load to speed up the rendering performance so 200
000 or 500 000 triangles per frame will be no problem. Q3A even
pre-tesselated bezier curves at map load and post-tesselated them into
triangles in the renderer backend every frame. Most of my OpenGL coder
friends who saw that piece of code just said: WTF. It was a good idea
in 1999 though.<br>
I implemented a more modern renderer on top of Q3A that supports all
that per-pixel lighting crap, efficient VBO geometry management and
even directional light mapping with Doom 3 maps.<br>
However power has a price and the price is breaking assets
compatibility this time.<div><div></div><div class="Wj3C7c"><br>
<br>
<blockquote cite="http://mid56178.63.150.173.150.1207766683.squirrel@mail.rq3.com" type="cite">
<blockquote type="cite">
<pre>Other than that I think it is a very good idea to create a second,
more progressive version of ioquake3. I'd love to contribute to that,
e.g. by adding per-pixel lighting, ambient occlusion, etc.
</pre>
</blockquote>
<pre>I would wonder if a fork is a good idea? This is the situation we
currently have with XReaL et al. Forks with extra goodies. But everyone
tends to go back to the base ioq3 for bugfixes and to build with.
Would people keep a fork sync'ed up? And how would the fork distinguish
itself from other fork projects? Would the fork start breaking
compatibility or lose the ability to run on other operating systems and
platforms?
If the base ioq3 were extended, it would be valuable because:
1) the code would always be up-to-date, no need to merge in fixes
2) you don't split mindshare between the "original" and "new" (marketing
thinking, 'ere? one-stop shopping?)
3) it would force any extensions to take into account the many platforms
that ioq3 already runs on (one of the great values for us in ioq3 over,
say, XReaL or one of those .NET ports)
4) it would force any extensions to take into account being able to run
existing baseq3 media, i.e. XReaL supports neat things but does NOT
support older lightmapped maps so our existing content (and pretty much
all existing Q3 content) is not available for use in that engine
If you extend ioq3 and it doesn't hurt backward compatibility, is there a
good reason to fork? If people just don't like that idea, ok, I get it.
But forking seems like it would just require more maintenance and might
end up splitting attention.
Anything the list discusses that they don't want to include in the base
ioq3 or can't come to a consensus on, they can always publish as a patch
like is currently done, I'd think.
Monk.
---
To unsubscribe, send a blank email to <a href="mailto:quake3-unsubscribe@icculus.org" target="_blank">quake3-unsubscribe@icculus.org</a>
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>
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br>