Raw source and immediate archive at
http://www.icculus.org/~phaethon/plan/Entries are currently sorted in: Newest First
Syntax (time and date in UTC, my local timezone is PST/PDT):
[YEAR].[MONTH].[DAY] <space> ~[APPROX. HOUR] <space> <space> [SUMMARY]
<empty line>
[CONTENT]
<empty line>
<empty line>
2002.06.23 ~08 FI CVS branch merging
Yay. My first shot at CVS branch merging. Branch "qs-tinyscheme" merged
into trunk. Now the version QuakeScheme built on top of TinySCHEME is in
the trunk. This should have actually happened a couple months ago, but I
forgot about it when the web CVS access stopped working for FI and I didn't
get to browse the CVS repository (and its ensuing branches) GUIly.
2002.06.23 ~07 FI decoys and count limits
A lot of credit goes to Inferna| on
irc://irc.enterthegame.com/#br for
giving me a push in the right direction.
Limiting the number of simultaneous instances of a projectile per player is
now implemented using an array of reference counts. The actual limit value
is stored with the projectiles definition in the weapons config file. This
limits some of the insane configurations I've been dreaming up, but for the
most part such restrictions are sensible for what amounts to a WF clone.
The decoy has been solidified. Now I can stand on my own decoy and shoot
it with just about whatever. Gauntlet is acting buggy, though. Currently
the number of deployed decoys isn't limited. In most MOCK cases, having
more than one decoy doesn't make a whole lot of sense. Still, I'd like to
mull over whether the coding design for decoys is "good" or not.
2002.06.23 ~00 Puter problems
My K7/1200 has been acting up lately. It may or may not be related to the
onset of summer.
In the K7/1200 (anticleia) are... were... three HDDs and an internal IDE
ZIP100 drive. Of the HDDs, they are labeled 4GB, 2GB, and 400MB. The 400
MB bit the dust, and now I'm down 400MB in swap space to 160MB (80 per
remaining drive).
OpenGL use has started to destabilize anticleia. This might be related to
using GATOS drivers, but the summer heat certainly isn't helping.
A long time ago, the PS/2 controller in anticleia fried. Dunno how. Plug
a keyboard (or even not) into the PS/2 port, and the keyboard buffer fills
with complete garbage. At least Linux doesn't accept the rubbish --
initial handshaking with PS/2 keyb fails, so the port gets ignored.
Perhaps related to this, APM sleep mode fails. Well, actually, waking up
fails. Nothing can get anticleia out of APM sleep mode, even pressing the
power switch (which is supposed to trigger the ACPI sleep signal or
whatever).
The fileserver/router, a K6-2/350 (penelope), has suffered from a series of
reboots lately. Most were related to using the CD-RW drive (jamming up or
whatever and taking down the kernel and CPU with it). I'm thinking of
switching around the ZIP100 and the CD-RW drive next time penelope reboots.
All in all, this has wreaked general havoc on my development efforts. I
normally have about 30 local shell sessions going (20 on penelope, 10 on
anticleia), all doing different things. A reboot means I have to take time
to go around and re-establish sessions. Sort of makes me wish for a
persistant-object/state OS.
2002.06.12 ~17 X-Wing nostalgia
It's been many many many years since I played Star Wars: X-Wing, the space
combat simulator. Never played it again ever since that hard drive crashed
(a whopping 345MB...). Recently, however, there appears to be a surge of
re-release/re-package at Fry's Electronics. A large number of old-ish
games repacked into a simple shrink-wrapped jewel case (instead of a
massive box large enough to hold a couple trans-Atlantic oil tankers).
Among the LucasArts games in said small packages were X-Wing, TIE Fighter,
X-Wing Alliance, Dark Forces (1), Rebel Assault II (where's 1?), and X-Wing
vs TIE Fighter. What I distinctly remember is the original X-Wing running
under MS-DOS. This X-Wing CD required Microsoft Windows and DirectX
something or other. This suggested (a) someone, somewhere, is doing an
authorized maintanence of this stuff, and likely to do so well past the
expiration of MS-Windos XP, (b) trying to get this to work under WINE will
probably turn out to be a fscking PITA. Similar thing with TIE Fighter: I
remember it originally ran under DOS only, and the CD cover stated MS-dows
as a requirement.
I decided to get X-Wing vs TIE Fighter, to get the basic feel of both the
Rebel and Imperial snubfighters in one package (I only got as far as the
TIE Fighter demo version before the hard drive went farming). It also
stated network play (at 8 max... oh well).
WINE 20020610. Installation went mostly well -- at least all the files
made it to disk. Startup was a problem; XvT (and apparently the other
space combat games) use a launcher app. The launcher kept wanting to
install DirectX no matter what. There was another executable, z_xvt__.exe,
which looked promising (weighing in at 1.7MB, over xwingtie.exe's 200K, I
figured this was the meat of the game). Intro played fine... sort of.
After six seconds, the WINE debugger popped up.
More strings(1)'ing. Found "skipintro" option. No more debug window, but
now the "Create Pilot" dialog appears. No keyboard input recognized.
Dammit.
Visit LucasArts support. Visiting X-Wing downloads to get topace5.plt
pilot file. Plop in and hope for best. XvT gets to main menu ("Data
Pad"), crashes. Try brute force, "echo foo > foo.plt". Starts fine, pilot
data repopulated, but name ends with a funny glyph. Probably the newline.
Try again, "echo -n foo > foo.plt". Start again, pilot data repopulated
with initial data, name looks fine. Keyboard still ignored.
Try an actual combat. Briefing works. Start mission. Says "Prepare for
mission launch". Crash. Presumably related to 3D gfx. Error messages
mention some WINE function with the string "MESA" in it. It maybe not even
be related to 3D per se, since the line after mentions a function about
DirectSound and setting Cooperative Level. WINE dies with error 254.
Probably I'll just wait for WINE to mature. Either that, or try to whip up
an SDL based engine, which would be an overwhelming task to do from
scratch. Pondering...
2002.06.09 ~17 Q3LCC-ZINX
Wow. I didn't expect zinx to solve it that quickly. With patches by zinx,
I actually manage to get .qvm files with the same md5sums as the
id-provided q3lcc. Way to go, zinx!
Now to update the page...
2002.06.09 ~14 Q3LCC-PH v1
http://www.icculus.org/~phaethon/q3a/q3lcc-ph/q3lcc-ph.htmlMy next major hack is showing progress. Since the sources to q3lcc
(modifed lcc for Q3 mods), I started my endeavor to modify the stock lcc to
see if I could make it Q3VM-compatible. A few weeks ago I had modified lcc
sufficiently to accomodate the widths of data types. However, that wasn't
enough -- Q3 consistently crashed on the resulting qvm files.
Some groveling through the assembly files (*.asm) showed an
opcode/directive not found in stock lcc: "pop". Comments in q3asm indicate
this is an opcode to discard the return value of function calls. One
pattern was that all CALLV (call to function of void type) were followed
by a "pop". I took this to mean that even void functions returned a value
(despite the meaning of "void").
What I also noticed where the some CALLI (call to function of unsigned
integer type) were followed by "pop", but most weren't. Some pattern
checking showed that the return values of CALLI were discarded if the
return value wasn't used for another operation immediately (such as for
assignement, comparison, or arithmetic). This pattern also held for the
other CALL* variants.
Groveling through lcc-4.1/src/bytecode.c led to a pretty evil hack tha
brute-forcefully checks if the return value of a CALL* is used. CALLV did
not need to be special-cased, as the return value of CALLV is never used.
I don't think qvm worked yet at this point. When I got this far, I sort of
back-burnered further modding.
A few hours ago, zinx on irc.openprojects.net piped up regarding sources to
q3lcc. Apparently my patches to q3asm have been making the rounds, as I've
been called upon by name regarding lcc. Apparently zinx was determined to
patch stock lcc to be qvm-compatible, and so I started sharing what changes
I had so far. To figure out what I had to change, I had to read through
the lcc sources again. Freshened up on the lcc source again, I decided I
might as well continue with my own quest. The big stickler was CNSTF4,
opcode for loading a floating-point constant. The canonical q3lcc outputs
an actual CNSTF4 opcode, but my patched lcc turns this into "ADDRGP4
floataddress; INDIRF4", i.e. loading the float value from the data segment
via indirection rather than placing the float value inline. In my search,
I found where float is parsed, in lex.c.
What I thought was happening was that when lcc reads in a literal floating-
point constant, it would type it as a double, then attempt to spit out code
for loading a 64b double indirectly, but that the data-width mods changed
the INDIRF8 to INDIRF4. Though I eliminated setting type as double (to
float-only) in lex.c, CNSTF4 was still coming out as "ADDRGP4; INDIRF4".
I decided to try compiling qvm with the changes anyway, and surprisingly,
Q3 didn't crash. I even went to the extent of eliminate any traces of the
original linuxq3a-sdk I had. Still no crash. "It compiles, ship it".
I'll bang on it some more later. In the meantime, zinx is busy tracking
down the CNSTF4 thingy.
2002.06.04 ~15 FI decoys
Weapons Factory has a feature called "decoys". These are solid objects
that are visually similar to the owner, and little else -- no health, no
armor, no weapons, no controls. The idea is basically to momentarily
deceive enemies, usually to get them to waste a shot or expose their
position(s).
Perusing the source code, I extracted decoyness from CopyToBodyQue(), which
replicates the player's body as a corpse that lies around. The player
entity is always within 0 to 63, and other game entities are 64 to 1023.
Since the player and their past-life corpse can coexist, CopyToBodyQue
copies all properties of the player (0-63) into a game entity (64-1024) so
that two separate (identical) bodies can coexist, but the player entity is
always under control by client (client 2 always controls player 2, etc.).
Basically I duplicated CopyToBodyQue() and changed some of the copied
properties so that the replica is standing (or at least not lying down).
The problem is that I can't seem to get the model to be solid. Splash
damage can destroy the decoy, but direct damages (bullets, rail, gauntlet)
pass right through it (including players!). One hint is that
client-prediction wants to clip at the decoy, but the server says to go
ahead and pass through. I'm thinking I should attack bg_pmove.c, but I'll
still poke around anyway.
Life: No Life found.
Project:
1. Project FI, Quake 3 mod (
http://www.icculus.org/fi/)
a. provide an extensible environment for a Q3 mod. The intended notion is that of "mutators" in Unreal Tournament.
b. FI:WFC, a more faithful reproduction of Q2WF for Q3 than WFA.
2. QuakeScheme
* Extensible language for Project FI.
* Builds on TinySCHEME (
http://tinyscheme.sourceforge.net/)
* Deal with idiosyncrasies of Q3VM not handled by most other Scheme impls.
3. QS GUI/widget set
a. Need to research advanced OO and GUI of Scheme derivatives and Common Lisp.
b. Replication/extension of boxy widgets in Q3TA (Q3 PR 1.27+).
c. Pie menus -- just to annoy theoddone33.
4. PalmOS stuff
a. PiNGer (gfx viewer)
* generalize interface to a "any-gfx" viewer (libpnm?)
b. ZBoxZ (file manager)
* beef up its appness: menus, dialogs, pen actions