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.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.
2002.06.01 ~16 'dows woes
Local gamehenger Chunky Kibbles ranted about Windows XP.
Reminded me of my wrastling with it's incestuous parent, W98.
So here's the gig. I play Tribes 2 under our favorite penguin's choice of
OS. For one reason and another, the T2 builtin VoIP are (a) incompatible
between T2.Linux and T2.Windows, (b) just plain sucks in general.
The T2 tribe/clan I'm in uses an out-of-game VoIP called "Roger Wilco", by
Resounding Technology(?), now a wholly-owned subsidiary of GameSpy Industry
(GSI), another company I have some serious beef against. To put a long
story short, RW is available only for Windows. Well, there's the "server"
end of RW (to relay packets) available for Linux, but that's about it. No
actual codec'ing under the penguin.
Cue WINE. It failed miserably.
Cue my hand-me-down laptop computer from my sister. This laptop suffered a
very dead screen when someone accidently stepped on its closed form while
unattended, cracking the LCD screen. No one fessed up. In the time since,
she has (a) gotten a desktop worthy of... Counter... counter-something FPS,
(b) stopped being a nomad requiring a portable. This machine I have dubbed
Polyphemos, after the cyclops who's (single) eye was poked out by Odysseus
in Oddyssey -- the screen does sort of look like someone took a pole
straight at it, albeit way off to the left side.
It's a Pentium II-based Celeron/400, with a meaty 64MB RAM, and 4GB HDD,
imbued with the curse known as Windows 98SE, and a Phoenix BIOS that is
hopelessly glued to the hip of FAT FS for Save-To-Disk. It has since been
sprinkled with the holy water known as Debian GNU/Linux, but it still
suffers from split personality, primarily because of the Save-To-Disk.
On the darker side of its personality, there was a mass of cruft collected
over two years of use by my sister. I wanted to reclaim much of the space
so that (a) lots of 'dows crap will be rid, (b) I can set up a Q3 server.
This, as far as I can recall, is the first time I voluntarily elected to
boot into Windows since 1997 (all other boots since being involutary,
forced, or otherwise accidental). I decided to start on diskspace
recovery. Calling upon skills lost and buried since 1997, I managed to get
to "Add/Remove Programs" and started picking on anything starting with
"Microsoft". Click remove. "Are you sure you want to remove" type dialog
box. Yes. "Windows now requires a reboot for the uninstallation to be
complete" type dialog box. No, I have more cruft to remove. Go on
selecting a few more, with the same cycle of Yes and No. Can't think of
anything else, so close the control panel thingy and reboot.
The programs didn't disappear.
They stayed there, in the dialog box and all the menus, mocking at my vain
attempts at removing them. The sadistic humor dawned on me. The only way
I was going to remove all this cruft was by individually relecting them for
removal... and rebooting after each and every selection.
After rebooting probably more times in two hours than everyone on lkml does
during an entire x.{odd-number}.y development cycle, combined, I came to
the issue of lookOut Express. For security reasons, I wanted this gone
gone gone. But, lo and behold, it failed to list itself in the Add/Remove
doohickey. I could probably attack the binary directly, but, knowing the
predecessor Windows 95, that would leave all sorts of cruft behind, perhaps
even more cruft than before deletion. So, at three in the morning local
time, I visited the only place where I knew others dabbled in the dark side
of the force, #linpeople.
The instructions I received weren't hope-inspiring, but it was something:
grab MSIE6 to install IE6 and OE6 so they appear in the Add/Remove, then
remove. I should note at this point that networking has not yet worked
under Windows. Under my sister's usage, it interfaced to a USB-to-Ethernet
dongle (borrowed from a friend, and returned since). Under Linux, the
machine uses a Linksys PCM100 PCMCIA card (which works great). Apparently
Windows doesn't know how to use this. I started the download of the 30MB
zip file at a *cough*whopping 22KB/s (of 150 cap) to my main desktop. In
the interim, I fiddled with other stuff. After a significant portion of
this zip file came through, I realized how Windows could be made to
recognize and use the Ethernet card. This was shortly after, out of
desperation, I reopened the box the Ethernet card came in. Sitting in
there was a floppy disk.
In some ways, I probably spent too much time in GNU land. I had LONG
forgotten that in Windows, device drivers are packed with the hardware,
rather than the operating system. Plop in floppy, and hope for the best.
It crashed once upon attempting to install the driver. I should probably
specify that the installer crashed, not Windows as a whole. That happened
a short while later.
Try again, says driver got installed... and needs reboot.
Reboot.
OK, so it continues with whatever the hell Windows does for driver
installation. Then came more sadistic jokes. BEFORE the shell even
started, IT REBOOTED AGAIN. No prompt! No shell! Poof, reboot! WTF?!
Navigate GRUB menu for the nth time...
Install Mozilla 1.0rc3. Reboot again...
Eventually the IE6 zip finishes. Now to get it get from desktop to this
laptop. Network Neighborhood? Claims I didn't enter a password for
networking.
Try a different tact -- pull over HTTP (using Mozilla and Apache).
That worked.
But there's nothing that understands ZIP. I have no idea why my sister
never bothered with that WinZip thingy.
Visit cygwin.com. More installations. Least I get bash now. And reboot
wasn't required. Nice change of pace for once.
Unpack ZIP, run. Dunno why I have to agree to a license agreement when I
want to wind up removing OE. IE6 and OE6 install.
The GRUB menu is starting to get annoyingly familiar and frequent.
Post-reboot rest-of-installation of IE6 and OE6.
Really, seeing GRUB again so quickly can gnaw on your bones.
Then I proceed to select IE6 *and* OE6 for removal.
*sigh* Maybe I should patch GRUB for animation or something.
Removing IE6 and OE6 only managed to restore the previous OE and IE, MSIE5
and MSOE5. These don't appear for removal. So I look for OE's base
directory, looking for uninst-something.exe. There isn't any. On a mad
(both senses of the word) impulse, I exported the registry via regedit and
sicced grep upon it for anything mentioning "outlook" and "uninst". This
actually turned up something useful, the command line to remove MSOE5.
The invocation was such: "SETUP50.EXE /APP:OE /UNINSTALL /PROMPT". Query
if I want to remove. Of course yes.
And of course, we meet our dear friend GRUB yet again.
OE was the last thing that needed to be purged. IE is of course an
inseparable and integrated (... humor me) component of the operating
system, so I leave it be. Defrag time.
I forgot what I did during the wait. Maybe I ranted on IRC, maybe I tried
stupid rocket-jumping tricks in Quake 3, maybe I read Slashdot comments
back-to-back, maybe I measured glacier movements, maybe I fell asleep.
Eventually the defragmenting finished. Then it was time to install Roger
Wilco. Never knew a sunrise could feel so strange.
Installing RW went fairly straightforward, as Windows programs go. At
least GRUB could remain sleeping.
Some minor wiring to set it up as satisfactorily as possible. Microphone
to laptop's soundcard, laptop's soundout to desktop's line in, old PS/2
mouse plugged into laptop and used as the "transmit" button (with my foot).
Then I find out I won't be able to actually test this setup since the next
tribe practice is in two weeks time, as next week is filled completely with
matches.
Sigh.
TODO: rant about RW with emphasis on porting
TODO: rant about GSI
2002.05.27 ~00 PiNGer.JPEG
http://palmboxer.sourceforge.net/What is now known as ZBoxZ was known as Palmboxer, prior to a sawfishian
(re)naming... incident. ZBoxZ is a GPL'd file manager application, with
several satellite applications (plugins, if you will). Among them is
PiNGer, an image viewer, to view files packaged in "boxes" (some sort of
PDB encapsulation of files), which supposed displays GIF (87 and 89) and
PNG images. So far only PNG works (as an aside, the GIF portion was based
on gif2png, but a source check against gif2png 2.4.2 shows the GIF code in
PiNGer to be inconsistent).
I spent the last couple of days banging on PiNGer for JPEG support. One
breakthrough discovery (for me, at least) is an alternative PalmOS library
mechanism called "GLib" (no relation to GTK+'s glib). The original library
mechanism, SysLib, requires all library functions to take a library refnum
as their first argument. Eyemodule (a Handspring Visor camera thingy,
http://www.eyemodule.com) already did a port of IJG's JPEG library
("libjpeg") to PalmOS using the SysLib method, requiring a mass of wrapper
code to expect the refnum argument. Unfortunately, Eyemodule's JPEG port
only covers the compression half (i.e. from Eyemodule image data to
JPEG-in-PDB).
GLib, on the other hand, doesn't require this refnum passing doohickey. I
suspect this is based on using one of the spare registers on the M68K. In
any case, porting existing *nix libraries is more straightforward, since the
necessary state munging is left to the compiler instead of the developer.
There are still other brick walls, like the 32K code segment limit. Which
libjpeg slams into at 130KB.
Cue a prc-tools hack, the multiple resources mechanism. The basic idea is
to divvy up the code into a bunch of <32K segments, then glue them together
with jump tables. The developer still has to mark how the code will be
split, but the glue stuff is done automagically by the tools. This method
comes with a cost: reaching across the boundaries is time-consuming.
What is not clear to me, though, is whether using both GLib and multiple
resources is canon. I've already marked libjpeg for the various sections,
and already set it up for GLib-style shared-library compilation, but
linking this to PiNGer and using a jpeg function causes catastrophe.
Then I tried regular static library (.a) linkage without multi-res. That
broke 32K easily. Then I split up PiNGer and relinked. Near as I can
tell, it falls over when it dereferences a function pointer to a function
in another segment.
Nonetheless, my meddling in PalmOS programming is enlightening me on
matters of Q3 modding. In particular, toolchains, library, C extensions,
limited environment, assembly.
2002.05.23 ~11 Shazbot
Wow. Hit the end of that search quickly.
Bad news:
http://zerowing.idsoftware.com/archives/gtkrad-macos/2001-November/000096.htmlWorse news:
http://www.timedoctor.org/gimps/byzakk/bugging.jpgHeartening news:
http://zerowing.idsoftware.com/archives/gtkrad-macos/2001-November/000104.htmlConclusion: time to start groveling through (stock) LCC source. :(
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
