website/sotc/2000/0222

108 lines
5.5 KiB
Text
Raw Normal View History

<!-- 22 Feb 2000 -->
<P>I'd like to say first off that based on the feedback I've gotten from
my last State of the Code update, I'll probably be doing these more
often. They'll also be showing up on the webpage soon I hope. I'm
keeping archives until that happens. This one's a bit long because a
lot has happened and I should have wrriten this about Friday night.
Sorry for the delay.
<H2>0.1.1 update</H2>
<P>In general, the update for 0.1.1 is coming along nicely. A lot of the
changes I have been working on have actually been committed to thre
tree. If you grab the Release_0_1 tag out of CVS right now, your
version will still say it is 0.1.0, but it should have most of the
bugs fixed. All in all, a very good thing. Here's what I've still got
to do with it:
<UL>
<LI>Report of a segfault somewhere. This should be fixed now, but if
it's not fixed I need to know.
<LI>I don't like my current fix for noclip in unstable and I don't
want to backport it. In a few days I hope I will know if there is
a better solution. I'll fall back on the working solution I have
in unstable if I can't find a better solution. If I change what
I'm doing, it'll be tested on unstable first for quality control.
<LI>Report the backtile isn't getting drawn around the classic
statusbar in the -3dfx target. It gets drawn for all the others
and testing this target isn't easy for me to do, so I haven't done
it yet. Will soon.
</UL>
<P>That's it! Tentatively, 0.1.1 can be ready to roll as early as this
weekend. You can still grab the Release_0_1_0 tag for the current
release, but please grab the current stuff and "test" the hell out of
it. 0.1.0 was pretty good, but 0.1.1 should fix every known issue I've
been told about since then. Break it if you can, please!
<H2>Unstable updates</H2>
<P>If you have been living under a rock and don't know it, unstable works
again! Mostly. Mercury has, in fear for his mortal life, undone many
of the changes made to unstable which caused so much breakage before.
The only target not working again is the SDL target because nobody
else but me seems to be building -sdl and just because I build it
doesn't mean I understand that target. (Remember, my areas are the QF
build system and some of the stuff deep in the engine core!) If you
can fix it, step up and do so.
<P>Win32 support. xC and Endy have Win32 "working" again under VC++, for
some versions of working. xC is working on the problems, but could use
a hand if you can help him. Here's what's broken:
<UL>
<LI>asm code in software (gas2nasm problems?)
<LI>software renderer isn't at the moment
<LI>qw-server seems to be having issues
</UL>
<P>The protocol breakage between the QW clients and server has been
fixed. We are still (unfortunately) compatible with Win32 2.3x clients
with all the problems that invites. We'll probably so remain until
we're done with the merge because we don't want to change the protocol
on win32 people until we know we can support them. Currently we just
don't have enough win32 developers with their hands in the code to
make sure it remains working.
<P>I've begun working on QER/QSG colored lighting in QF. It's the first
QER feature I'm working on in the hope that we'll eventually be
working from a common codebase. That's up to them of course but we all
know the QF tree is superior to the q1source tree. Still, they may not
want to have to work around software renderer limitations, so we'll
see.
<P>The merge continues at impressive speeds. The merge hall of fame has
a new face today as taniwha has proven his insanity by filling the CVS
list with commits of merged files.
<H2>Project relations</H2>
<P>We've been talking to QuakeWorld Forever about their secure QuakeWorld
implementation. I will probably at some point be helping them
implement public key cryptography. I've explored the best way to do
this (Netrek uses a similar strategy) and have a few ideas. We'll see
how they pan out.
<P>As I mentioned above, I'm implementing some QER features and Endy from
QSG has been picking away at a few of our Win32 problems. I generally
consider these two groups to be closely related, but we're going to be
working with them more to make this a truly multi-project effort and
ensure some standardization and compatibility between our projects.
<P>If you haven't heard, you've lived under a rock for quite some time
now. QuakeLives is and has been almost since the project's inception,
in violation of the GNU GPL. They tell us that they did not and do not
have Copyright infringement problems with that license, the GNU GPL.
They demanded we remove any statement saying otherwise from our
website. (Mercury says he left QuakeLives because of GPL
violations---this is noted on our news page.) Since we can prove
otherwise, we've refused.
<P>Speaking of QuakeLives, the MegaTF website was distributing copies of
a release marked 2.54 without source. Slade of QuakeLives told us that
MegaTF was distributing "warez" and later denied making that
statement. We've got logs if anybody cares enough to read them,
naturally. At any rate, Ambush has removed the offending binaries
until he has some idea where things really stand with QuakeLives. He
is not retargetting MegaTF in the meantime. Talk to him, not to us,
etc.