[quake3] Greetings

[Jorge Peña]

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 (*Or that's what I understood from Robert*).

monk gives some good reasons to just extend the base though:

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?)

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? (*Of course we could think of existing projects I guess...*) If we
work on the base engine itself, it would force people to adapt.

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.

On Wed, Apr 9, 2008 at 12:42 PM, Robert Beckebans <trebor_7 at gmx.net> wrote:

>  I would like to clearify a few things about XreaL because many people
> complain about the incompatibility with existing mods assets:
>
> 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.
>
> 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.
> 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.
> 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.
> 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.
> 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.
> The old renderer design distracts many experienced OpenGL programmers
> because it is way too CPU bound with todays hardware.
> 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.
> 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.
> However power has a price and the price is breaking assets compatibility
> this time.
>
>
>  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.
>
>
>  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 quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/quake3/attachments/20080409/c2557e34/attachment.htm>