website/sotc/2000/0214

173 lines
8.1 KiB
Text

<!-- 14 Feb 2000 -->
<P>I could give a long speech full of lies, half-truths, and shameless
attempts to get you to support my agenda's various components, but
dammit Jim, I'm a coder not a politician!
<P>So instead I'll just talk about what's going on with the tree so
people who don't hang out on irc know what the fuck is going on for a
change. Maybe Palisade or someone should see that relevant tidbits
make it to the website's news page. What's here's mostly for other
developers and non-novice users so I'm going to feel free to go into
technical details of things the average non-coder may be confused by.
Tough. =&gt;
<H2>QuakeForge 0.1.1</H2>
<P>It's not out yet. In fact, it's not even close to out yet because
I pretty much have become the stable release manager here because like
an idiot I stepped up to the plate when someone needed to in order to
get 0.1.0 out the door.. First lesson: Never volunteer yourself to
do a job that nobody else wants---you'll find out quick why they don't
want it and you won't be able to get them to take it later. ;&gt;
<P>What needs to be done for QF 0.1.1:
<UL>
<LI>There's at least one reproducable bug in at least UQuake
I can find.. go to the start map and walk over to the hard
hallway. Wait for the message about hard skill and take a
hot bath. It's quite likely that when you die, you'll sig11.
Don't try this in an OS less than any good unix folks---a
sig11 is death to your box in win32. I _don't_ know what's
causing this per se other than that it seems to be
reproducable in cases where that center message is on the
screen. However the seg is in Sbar_DrawFace()... I'll
probably add some sanity checks to that routine and see what
happens.
<LI>There's another generic report of a segfault. It may be
the above bug.
<LI>qw-client seems to work fine. At least, I haven't gotten
reports of bugs. qw-server also hasn't got any reports of
problems yet.
<LI>I have a report that under the -3dfx target the oldstyle
status bar is missing the background tile and therefore has
a "void area" around the edges of the statusbar. I _thought_
I fixed this before release but then I only tested UQuake and
then only the -gl and -ggi targets. It's a minor fix and I
know how to fix it if it's still broken.
<P>Mission packs in -gl target all work already, save
hipnotic. -gl dies saying the scrap texture is full. There's
already a fix for this in the code, I just need to enable it.
Currently unstable allows four scrap textures whereas stable
allows only one. Four is overkill (all hipnotic needs is two)
but I figure there's got to be at least one other mod out
there that needs the extra space for tiny textures.
<LI>UQuake noclip mode... If you've tried it in -gl or -3dfx,
you know that if you walk outside the map you get a very
doom-like result (ie, the engine doesn't know what to draw so
draws nothing) rather than quake's nice "void" color. I fixed
this in unstable, the fix was again minor.
</UL>
<P>When I'm satisfied that things are working okay, I'll call it 0.1.1
and make sure archives get made. I'll also upload Debian packages
(since I do that) to potato and woody. They may not ever see potato,
but I'll try since the above would really be just a bugfix release.
Someone who cares will have to make rpms, win32 binaries (if that's
possible in the 0.1.x tree, it may be now and not have been when the
release archives were made I don't know..)
<P>&nbsp;<BR>As a side note, there is talk (since so many of QF's
coders are Debian users and developers) of modifying the UQuake
console version string in 0.1.1 to read "QuakeForge Quack (B-Finn
edition) 0.1.1" or something similar in honor of one of #debian's
most memorable and amusing trolls, B-Finn who always wanted "HELP
FOR PLEASE TO INSTALL QUACK"... He made it clear that he meant Quake
and was obviously trolling (that, stupid beyond belief, or someone's
sick idea of competition to megahal...) It probably won't happen,
but then again ....
<H2>0.2 development</H2>
<P>If you hadn't noticed, a lot is broken lately. Understatement of
the entire 20th Century I realize. We've begun working on the shared
object support. Linux svgalib and X11 work, sortof. X11 is being
broken again because of the seperate input/video things being LAME(!)
and broken anyway, but the results will be cool.
<P>You can thank Mercury for breaking the tree with what he knew was a
badly designed module solution, but he did lay the framework needed to
do it right. He's also getting stuck fixing it which is of course
poetic coder justice or something. ;&gt; Currently the shared
objects must be in the dir you run from--taniwha is working on a path
cvar which will be searched.
<P>&nbsp;<BR>Bad news: Someone broke qw's protocol. Client or server
we don't know, but it's broken. Unintentionally, it will be
repaired. At least, as soon as someone else fixes it or I get a
working -ggi target, timestamped server console, and about an hour to
work on it in.
<H2>Celebrity advice</H2>
<P>Good gods, where to begin? If you don't know it you must have
been living under a rock or something: Zoid has taken an interest in
QuakeForge(!) He's asked for cvs write access and has been hanging
around to answer questions, offer suggestions, and generally remind
us that he thinks we're all insane. (He's right, of course..)
<P>Here's what he's had to say so far:
<UL>
<LI>The SVGALib code is an evil hack. [We knew this.]
<LI>He has no idea why we're merging the two code trees. He
points out that a single player QW game won't work too well
because of the physics differences. Probably we'd have an
easier time of it if we just merged obviously common stuff
like the renderers and called it good.
<LI>He says he's going to see about merging Q3A's X11 mouse
code into our tree. It'll do us wonders.
<LI>The way we're doing input (and probably by this time next
week video and sound and who knows what else) modules is
pretty much exactly how Quake2 does them. He's offered some
ideas and opinions to all of us working on them.
<LI>The brightness control in gl targets.. Just gamma correct
the pallete, not too hard to do. This will work for MANY (not
all) cards and has the advantage of being cheap. No framerate
loss is cheap. =&gt;
<LI>The pixel splatter after a cshift or in certain places
(like the start map's lava) are related to t-junctions. He
explained it to me and if someone is bored and wants to play
with it I'll dig up the irc log. Essentially we need to clip
textures before thee video card has a chance to fuck up
trying to draw them. This only needs to be done at
t-junctions which is why the problem is some places and not
others.
<LI>He's admitted that Quake2 is essentially Quake1 with
shared object renderers, colored lighting (GL only, it's just
not colored in software), and not really a whole lot more
than what we have now in uquake that is #ifdef QUAKE2'd..
[This leads me to believe that it is possible, even
reasonable that we might be able to make QF able to read and
play a game of Quake2.. That would ROCK IMO...]
<LI>Surprisingly, Zoid thinks we should break the QW protocol.
He's got good reasons too: The smurf attack possible with the
current server, the exploit or two which will down any QW
server out there, and the time cheat problem. Turns out that
win32 people running qwcl 2.3x for anything longer than abou
t a day or so are likely to be caught for cheating because
they actually are! They might not even know it either. The
2.40 (source) release fixed this problem, but a 2.40 server
is backwards compatible with older clients. [We'll be
working with QSG to make sure that the protocol changes in
question are supported by everyone. The client will be able
to be compatible with both 2.40 and the new protocol real
easily so we'll probably maintain compatibility there.]
</UL>
<P>We're obviously thrilled Zoid's taken such an interest in our
project. We're very grateful to have him working on the project
where time permits him to and for the advice he's offered to us.