[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

QuakeForge state of the code address

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!

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

QuakeForge 0.1.1

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

What needs to be done for QF 0.1.1:

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

 - There's another generic report of a segfault.  It may be the above bug.

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

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

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

 - 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

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

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

0.2 development

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.

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.  ;>  Currently the shared objects must be in the dir
you run from--taniwha is working on a path cvar which will be searched.

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.

Celembrity advice

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

Here's what he's had to say so far:

 - The SVGALib code is an evil hack.  [We knew this.]

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

 - He says he's going to see about merging Q3A's X11 mouse code into our
   tree.  It'll do us wonders.

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

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

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

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

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

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.

Joseph Carter <knghtbrd@debian.org>                 Debian Linux developer
http://tank.debian.net   GnuPG key  pub 1024D/DCF9DAB3  sub 2048g/3F9C2A43
http://www.debian.org    20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3

<Crow-> who gives a shit about US law
<jim> anyone living in the US.

Attachment: pgpQpNWEBROw3.pgp
Description: PGP signature

Reply to: