[quake3] Greetings

[monk at rq3.com]

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

That's what I mean, yes.  I am used to referring to vanilla Q2 and Q3 as
"baseq2" and "baseq3" instead of, say, VQ2 and VQ3.  Just a habit I can't
break.  So in reference to ioq3, I view the original fork/tree to be the
"base" in my strange mental realm of obtuse terminology.


> 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.

I think that idea makes the most sense, now that I think of it a bit more.
 There's only so far that some of the older hardware platforms can go. 
Get to a certain featureset for ioq3 and then freeze it as a legacy
release, then try to take it further.

Backport any important security fixes, but beyond that, leave the legacy
release alone?  I guess it's forking, but in the opposite direction.

In the end, if Tony, Tim, Thilo, Ludwig, Zak, Jorge, etc. don't really
like the idea, then it won't work.  I'm not thinking anyone really wants
to turn ioq3 into the type of engine that Chris or Tr3b described where
pretty much everything has been ripped out and it's a whole new custom
engine.  I think everyone here is vested in having ioq3 work, more or
less, with all the q3 stuff that's already out there.

If that can be done AND support for some new media or graphic effects is
possible, at the possible expense of performance or support on some older
hardware platforms, I think that's the win-win situation.

Not everything is about the graphics, too.  Cameron from Hermitworks will
hopefully submit some patches for UTF support and a supporting tool,
deluxe mapping which is something one of the RQ3 mappers is hot-to-trot on
even though I keep forgetting wtf it is, and skeletal models with
supporting toolchain.  Hey, that stuff will probably work just fine on the
ol' 420 MHz SGI Octane I keep referring back to.  And that helps extend
the engine with modern features.

I'm assuming it won't break support for existing media, too.

Someone added a resolution-detection bit that uses the new SDL base in
ioq3 to auto-detect available resolutions rather than have coders just
hard-code in some common ones and hope for the best.  Would it be possible
to auto-detect certain hardware characteristics and expose functionality
based on that?  Have the engine scale the abilities based on what is
available?

Remember Tenebrae?  http://tenebrae.sourceforge.net is a bit dead now
(screenshots still work), but it added D3-class graphics without losing
support for legacy Q1 media.  Back in, what, 2003, 2004?  So it might be
possible.  Maybe we won't get 500 fps, but most games now seem to be
locking in to either 30 fps (games developed to be ported to/from consoles
and TVs) or 60 fps (games assuming LCD refresh rates for either computers
or game consoles/HDTVs).  So while things might be slow and inefficient
from a conceptual standpoint, it might not be too much of an issue
overall.

I don't write long emails to try and push my agenda on y'all.  Well, ok,
not primarily.  ;)  I am just trying to convince people of what I think
would be a path that would benefit both the ioq3 project and the people
who use ioq3, be they coders or mappers or players.  And it's just my
opinion.

However, I think maybe a year or two ago, most of the major coders on this
mailing list wouldn't even entertain the idea.  So the fact that there's
some discussion is heartening.

We're all on this list because we like Q3.  The code, the mods, the
gameplay the engine provides.  If the only way to add graphical goodies
that are 3 generations past Doom 3 is to rip everything asunder and be
left with only 20% of Q3, I don't think anyone will want to do that.

But certainly, ioq3 should be able to be extended to a certain degree
before it no longer becomes practical to work within the quake 3 codebase.
 If ioq3 reaches that point, then so be it.  But getting up to there, I
bet the engine can be polished up quite a bit.  We won't know until it's
tried, though.

Monk.