mirror of
https://git.code.sf.net/p/quake/website
synced 2024-11-24 05:01:23 +00:00
61 lines
3 KiB
Text
61 lines
3 KiB
Text
<!-- 14 May 2000 -->
|
|
<H2>The new QuakeForge tree</H2>
|
|
<P>The new QuakeForge tree is an effort based on the QuakeWorld
|
|
cooked up by a few developers who had all come to the conclusion
|
|
that the current tree had some inherent limits we didn't like.
|
|
|
|
<P>First, the build system. It's not very portable and lacks a key
|
|
feature called header dependency. Without them you often times find
|
|
yourself needing to recompile the entire project just to test a
|
|
little change. I should point out that a compile takes about five
|
|
to six minutes on my PIII and most of our developers do not have
|
|
that sort of machine for development.
|
|
|
|
<P>Second, there are tons of bugs in the source. Not just the ones
|
|
we're responsible for - those are easy to fix! The ones buried deep
|
|
in Id's code, often with two or three layers of workarounds on top
|
|
of them to keep the problems from affecting most people in common
|
|
situations. We have been adding to the workarounds because we
|
|
didn't know the cause of the bug either. And then it hits one of us
|
|
what the original problem was. Sometimes trying to fix these
|
|
problems the right way in our current tree is very difficult.
|
|
|
|
<P>Third, the merge. One of our goals from the beginning was to
|
|
have a single binary which could act as a client, a server, or both
|
|
depending on what the user needed, including for single-player and
|
|
co-op games. At the time, merging the two source trees together
|
|
seemed like the best plan of attack. It hasn't been, and it adds to
|
|
the problem above as well as making bugs caused by us more difficult
|
|
to track down.
|
|
|
|
<H2>Single player support</H2>
|
|
<P>No, we're not abandoning it. Far too many people want it,
|
|
including many of the project's developers. How we're likely to get
|
|
it into QuakeWorld's model is kinda complex. I can explain it most
|
|
simply by saying "emulation". Not like what you do to get Mario on
|
|
your PC, but rather having the server be smart enough to recognize
|
|
the differences between a NetQuake game and a QW game and adjusting
|
|
a few things as needed to make it all work.
|
|
|
|
<P>That sounds like a royal pain in the ass, which is why we didn't
|
|
try before. It's actually nowhere near as hard as we thought it
|
|
would be. Ender and Tonik have both made major strides in this area
|
|
already.
|
|
|
|
<H2>Mega2k?</H2>
|
|
<P>As QSG Standards version 1 call for the features Mega2k needs to
|
|
be available, they will be. In fact, I've already implemented them
|
|
in the new tree. Later this week I hope to be able to produce
|
|
tutorials for how these things were done for people who might
|
|
benefit from them.
|
|
|
|
<H2>QuakeWorld Forever</H2>
|
|
<P>Yes, the rumors are true. QuakeWorld Forever and QuakeForge are
|
|
merging! The new tree is pivotal in this merge as trying to combine
|
|
QuakeWorld Forever's features with the current QuakeForge tree would
|
|
set back their development about two months. This is unacceptable
|
|
for them and for us. The new tree is right from the beginning
|
|
easier for the QWF developers to work with, making this very serious
|
|
problem seem almost nonexistant. I'll post more details as soon as
|
|
we have them.
|
|
|