<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body 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.<br>
<br>
<blockquote
cite="mid56178.63.150.173.150.1207766683.squirrel@mail.rq3.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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 wrap=""><!---->
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 class="moz-txt-link-abbreviated" href="mailto:quake3-unsubscribe@icculus.org">quake3-unsubscribe@icculus.org</a>
Mailing list archives: <a class="moz-txt-link-freetext" href="http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50">http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50</a>
</pre>
</blockquote>
<br>
</body>
</html>