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.04.03 ~07 "The CUSP emulator corpse stirs back to life.--More--"
http://www.linux.ucla.edu/~phaethon/cuspemu/Turns out that UCLA Computer Science Department (which is one of the few
universities that places CompSci under "Engineering") is *still* using
the crufty PITA POS known as CUSP for its assembly/machine-language course.
I'm not too fond of having had CUSP shoved down my throat, instead of
a real CPU.
A short background on CUSP (Carleton's Utterly Simple Processor):
* Developed at the University of Carleton (Ottawa, Canada) in late 80s for their assembly language course (they have since moved on to Real CPUs(TM)).
* Fictitious CPU, exists only in emulation.
* The only "official" emulator is binary-only (sourceless) MS-DOS EXE last updated 1992.
* Copyright encumberance causes... "special parties" for the UCLA CS-33 students.
A short dump of CUSP specs:
* 12-bit address bus, 24-bit data bus
* 4096 (i.e. 2**12) memory words (24 bits per word)
* 4096 I/O ports (8 bits per port), separate address space
* memory addressable 24-bit or 8-bit (but not 12)
* 1 24-bit general-purpose register
* 4 12-bit special-purpose registers
* 4 CPU condition flags
* 10 instruction addressing modes
* 1 instruction occupies only a single whole word
* Five devices:
- Keyboard, input
- CRT, output (monospace text, 14 rows, 38 columns)
- tape, input/output permanent storage (emulated as a file)
- printer (emulated as a file)
- timer (in emulated system ticks, not host time)
PHFC (expands to many thing: Officially "Phaethon's Hack For CUSP", but
my personal favorite expansion is "PHFC Handles F***ing CUSP") is my
(incomplete) GPL'd implementation of the CUSP emulator. For varying
reasons, I got dismissed (kicked out) from the CompSci program at UCLA,
so I have no chance of taking CS-33 again. So I don't have need of
completing the emulator.
PHFC is, as far as I recall, the first time I started a large-ish
programming project, using compilation in parts, autoconf/automake,
function pointers, and (meaningful) data encapsulation. As I said,
I'm not too fond of CUSP. This fact is reflected in my choice of
filenames and variable names. A few choice selections:
* cataplex.l (asm source lexical analysis)
* cramps.y (asm source grammar)
* spasm.c (assmebler, linker)
* phfc_bitch_and_die() (error messaging)
Just recently, though, a student taking CS-33 this quarter sent me e-mail
querying about PHFC, along the lines of actively helping development. I'd
really prefer handing off the project to someone else, since I'm not in
the mood to hack PHFC to completion (for whatever "complete" means).
But not many people would be both willing and able to take on the project.
On another note, turns out I had my old e-mail address on my PHFC pages,
which is no longer valid (much less its domain). I'm surprised he found
my current e-mail address at all. Well, OK, granted, it's the canonical
pattern of ${~username}@${domain} reflected in the URL, but this person
had determination to contact me [above mindless clicking].
2002.03.27 ~06 IRC snippet
This is gonna be a a classic for me. Victim's name obscured out of (little
remaining) respect.
21:55 < XXXXXX#blenderchat> anyone interesting in descussing modern philosophy?
21:55 < XXXXXX#blenderchat> anyone interested...that is
21:56 < phaethon#blenderchat> 42
21:57 < XXXXXX#blenderchat> 42? what the hell does that mean
2002.03.26 ~18 ZBoxZ dev access
http://sourceforge.net/project/memberlist.php?group_id=7522Woohoo!
In other news, I hacked on ZBoxZ proper some more. I converted the app's
preferences data structure from an array of chars to a struct. Inspired
by LispMe, I also added a "left-handed scrollbar" option that moves the
scrollbar over to the left side, for the left-handed folks. This way,
left-handed use doesn't cover half the screen face with the hand and
stylus. No, I'm not left-handed.
2002.03.26 ~01 PalmZLib, PiNGer
An interesting little experience combining my two favorite Palm apps.
In order to properly hack on PiNGer, I hit the PNG docs on www.libpng.org.
The format is surprisingly simple, flexible, and powerful. I'm surprised
no one created it earlier... everyone probably figured GIF was "good
enough" until The Great GIF Ymezth started.
Anyway, so I started hacking on PiNGer. Well, "hack" is probably an
exaggeration at this point... I just merely shuffled variables around and
introduced a boatload of data encapsulation. This will certainly help in
maintaining and extending PiNGer in the future. Of particular note is
how PiNGer accesses various system structs directly (i.e. not using
accessor functions), a deprecated method starting with PalmOS SDK 4.0.
I ran frequent compile, upload, run cycles to check effects equivalence.
Lots of crashes. Last time I remember having crashes this frequent was...
um... using my TNT2 with nVidia drivers 0.9xx-something-something.
LispMe's DatabaseManager functions (dm-*) came in handy for tracing
PiNGer's progress. PiNGer uses a "scratchpad" database as a buffer
holding the decoded image. After a reboot, I could use LispMe to dig
through the corpse of the scratchpad. I preferred this over dragging
the PDB to the desktop then dissecting it there. I think it was because
I could start whalloping on the db with Scheme code =)
The GIF decoder seems broken. For one, PiNGer can't decode any of the
remaining GIFs I happen to have. Two, PiNGer's GIF decoder advertises
having used pieces of gif2png (gifread.c in particular), but after tracing
the two sources, this doesn't seem true any more (maybe gif2png updated?).
Still, not like this is a big loss. I'd just as soon rip out the GIF code.
Creating an updated PalmZLib from zlib-1.1.4 was very straightforward.
Tom Zerucha's 1.1.3 patch for zlib->palmzlib fit snugly with zlib-1.1.4
(read: no serious rejects by patch(1)).
I found a free-speech JPEG compression-only library for PalmOS. It is
just a Palm-ified port of the JPEG reference library (libjpeg6b), but the
_de_compression routines were left unported. As it were, the library was
created/ported to accomodate a camera module for Handspring Visor. For
the curious, www.eyemodule.com[/developer/index.asp].
I also started hacking the ZBoxZ core. My greatest achievement there as
of this moment is getting the file's list to update on a scroll event
without causing screen flicker (which was caused by erasing the whole
screen then redrawing every little component). An HTMLized version of
the Palm OS Reference manual would be of immense help to me; I find
something profoundly disturbing in "flipping through pages" of a manual
on a screen.
I should also add my PalmOS work to my .project, and finally get around to
snipping my .plan to something smaller than a monolithic 26K text stream.
2002.03.24 ~23 PalmOS stuff.
- ZBoxZ (palmboxer.sourceforge.net) -
I found this while googling for "GPL graphics viewer". Based around
in-PDA (de)compression (zlib (with the buffer-overrun bug!) now on PalmOS!)
and the Palm serial port, ZBoxZ encompasses a set of useful doohickeys.
Among these doohickeys: PNG/GIF viewer, compressed archival (like tar.gz),
compressed executables and runtime decompression (like a compressed
filesystem), YModem over the serial port (almost-substitute for HotSync),
MIDI player, Fax xmit/recv (!), and a simple web server (!!). Emacs comes
to mind.
I plan to spend quite some time hacking on PiNGer, the image viewer
component. If nothing more than to get it to compile from source at all.
Oh, yeah, and ZLib[.prc] could use the latest zlib patches.
- LispMe (www.lispme.de) -
A new version, 3.1, got released a month ago, just after I gave up the
project for dead. It now has enough hooks to create Palm resource
databases ("Rsrc") within itself. To actually make a resource compiler
is nontrivial... after converting 8% of pilrc.h to suitable Lisp form,
ennui got the better of me and I gave up.
There should be an automated way of extracting the info from pilrc.h.
Or maybe I can just type it up from scratch based on the Palm OS docs.
It's not like the Rsrc format is a moving target.
2002.03.19 ~13 Oops... not tail-recursive...
Turns out my Scheme interpreter isn't truly tail-recursive.
I'll be banging my head against the wall a bit to straighten out this mess.
2002.03.15 ~07 More on Blender and MD3.
First of all, NaN (the company behind the the 3D modelling software Blender)
is going kaput. No word as to the fate of the software, although I do recall
a promise of Blender going open-source in the event of company's death.
In the meantime, www.elysiun.com appears to be the interim web site for
Blender users.
Second, I figured out a half-assed way to import MD3 animation, after looking
at various (other) Blender python tutorials. Link the script with the object
using FrameChanged. That way, whenver the frame number in Blender changes,
the python script will be re-run, which can then manually(?) move all the
vertices in the mesh according to frame number.
There really ought to be a way to just plug and chug the coords into an IPO
curve. It's a lot tougher to figure out with www.blender.nl (and its
accompanying python docs) demolished.
2002.03.11 ~12 Significance of data structures
After tampering with Scheme, Python, and object-oriented programming
paradigms, I've taken a different view of the data arrangements in my
mod. I've separated out "templated" information from "instantiated"
data, otherwise known in C++ parlance as "classes" and "objects".
The data type gentity_t describes the base properties of all objects
(entities) in the game. Player-specific data go with gclient_t, to
reduce space waste. There are 1024 entities, of which the first 64
are the clients (players, bots).
I extended gentity_t and gclient_t with unions of instantiation-specific
structs. Since an entity can only be of one "type" at a time, a union
is quite suitable -- only one of the extended structs makes sense at
any time.
The CVS repository of FI has been updated with this revised view of data.
2002.03.07 ~14 Q3 Extensibility
Ok, just got an interesting brainstorm courtesy of our local Chunky Kibbles.
One reason why I'm trying to tough it out with QVM is because of its cross-
platform nature. That is, compile-once run-on-a-lot. The limiting nature
of QVM makes it somewhat safer than the [unrestricted] native code form of
Quake 2, to paraphrase one of jcarmack's .plan entries (somwhere...).
2002.03.06 ~09 Q3TA menu docs update
http://linux.ucla.edu/~phaethon/q3tamenu/q3tamenu.htmlThis is something that I've been working on for... whoa... over a year.
It started when WFA cannibalized Quake 3: Team Arena's new menu/HUD code.
Originally, I set out to customize my HUD in Weapons Factory Arena.
I banged up this file to sort out what was available and how I could
combine the pieces for desired effects (analysis to assist synthesis).
As I became more disinterested in WFA, the scope of the docs expanded to
general documentation. Currently, its target audience consists of HUD
customizers and the poor sod stuck typing up all the .menu files for a mod,
but not those of the programming persuasion. I expect to gradually include
the coders in due time.
The significant update recently, though, is the section on uiScript. Much
of the initial substance is contributed by dementor (dementor@c:::::.n::).
While trying to figure out uiScript by groveling through the Q3 game source
tree, more of the menu puzzle fell into place for me. It's uiScript that
initiates complex actions within the mod from the menu UI (e.g. adding the
currently selected server to your list of favorite servers unless the list
is already full).
I consider this something of a kludge. Although the Q3TA menu system is
heavily data-driven, Turing-complete code can only be expressed in the
pre-compiled QVM files ("mod code"). Code cannot be created or extended
at runtime. I consider this a Bad Thing, as it puts limits on what can be
accomplished in the menus and HUD by those without access to the mod
source (mostly those who would be called "end users").
One thing I like about Tribes 2 is its extensible language. It is powerful
and flexible enough to allow different modules to sit on top of each other
simultaneously, the player mixing and matching on whim. Unreal Tournament
also achieves similar effects, however, almost all Tribes 2 code extensions
come with source, providing _me_ with an unprecedented amount of tweakage --
instead of working around a misfeature or starting over from scratch, I can
hack on the component directly.
This sort of extensibility is something I'd like to have for Quake 3.
2002.03.03 ~07
http://www.icculus.org/news/news.php?id=335D'oh.
2002.03.01 ~17 md3import bug-squashing
Got rid of the most annoying md3import bug, the "some polygons missing" bug.
List of vertices in Blender is zero-based, so that the first real vertex is
index 0. The method addFace() is used to connect the vertices (referenced
by index number) to create a polygon. A vertex index of zero is treated as
"no vertex", instead of vertex 0. See zero-based vertex list.
Workaround was to create an initial throw-away vertex, which goes into the
vertex list as #0. Then all the vertices in the actual model are then shifted
by one, with the end result that none of the model vertices will be indexed
zero. After all triangles are established, the initial throwaway vertex is
removed, and the rightful order is then restored.
I also put in FileSelector widget (point-and-click md3 import), and got MD3
tags to convert to Empty objects.
2002.03.01 ~14 MD3 import into Blender
http://www.linux.ucla.edu/~phaethon/q3a/md3import/md3import.htmlImporting works. The objects do look a little strange (a couple polys missing
and such), but otherwise I would call the venture a success.
No textures imported, the tags don't import properly, no exporting, animation
is NOT accomodated, yadda yadda. At least (most of) the mesh is there.
The step towards exporting to MD3 shouldn't be that big; all the bit-banging
stuff just needs to be straightened out.
On impulse, I started on a joint mini-project to create a rendition of The
Restaurant At The End Of the Universe, and I'm a little eager to start
swapping around prototype models without having to learn QERadiant. This
means I'll probably be getting around to an exporting of some kind soon.
2002.03.01 ~10 Analyzed MD3
I think I've finally figured out what all the bytes in a MD3 mean.
The output of my initial python program parallels the output of q3data
(which I've finally got to compile mere hours ago).
Shouldn't be too long to get Blender to import MD3 directly, even if the
objects come out a little strange.
2002.02.23 ~12 Q3TA Customizable Popup Menu
http://www.linux.ucla.edu/~phaethon/q3vchat/q3vchat.htmlThis is a hack I had envisioned since maybe September or October of 2001.
I couldn't establish a solid goal for the final form until I played a lot of
Tribes 2, and thus took much inspiration from the Tribes 2 vchat menus.
I actually scribbled most of the solidification/finalizing notes while waiting
for my car to be repaired. =)
This hack was inspired by my WFA peri HUD; the basic idea of the popup menu is
to throw all the parts of the popup menu onto the screen, but render most of
them invisible most of the time, selectively setting certain pieces visible.
This creates the illusion of several menus appearing at different times in
the same spot on screen.
Unfortunately, implementing the idea in this exact manner exceeded the memory
capacity of the menu system.
Fortunately, though, I found a workaround. Instead of creating all possible
pieces of menus, I instead use a single set of Editfields arranged in a
column. Since the HUD cannot obtain mouse focus, the Editfields are safely
read-only (to an extent). The Editfields can also be set to display the
contents of a cvar. The Editfields are given a patterned cvar name.
A description of the menu layout is provided in a plaintext file. Using this
file, a perl script automagically generates the ridiculous number of cfgs to
help create the desired effect. The collection of cfgs work together to set
the values of each of the Editfield-associated cvars and the bindings of keys
at appropriate times and depths of the menu. The resulting effect is a
popup menu that is traversed by keystroke sequences, much like the vchat ('v')
menu in Tribes 2.
2002.02.20 ~11 Ogg Vorbis/Q3VM decoding successfully.
I am HAPPY!!!!
My Q3 mod, Project FI, successfully decoded a short vorbis file into 16-bit
PCM. The test vorbis is a 12-second thunder sound effect from some Q3 map,
I forget which. The resulting PCM is rather poorly decoded; I'm guessing this
is because of my horrid log()/exp() implementation, perhaps in combination with
Q3VM's 32-bit-only floating point.
The Ogg Vorbis codebase is based on the source release of the reference
library version 1.0rc3 from Xiphophorus (read: copied and hacked). In total,
not much functional hacking to the vorbis source itself was required (had tons
of printf()s for debugging, though), but I had to spend considerable time on
supporting code, math functions especially. I assumed that the Vorbis code
is correct, and that my own stuff needed fixing.
By-products of this effort:
* A saner and somewhat more robust, if more space-consuming, malloc() system.
* Expansion of the math library.
* Cleaning up of the expanded math library.
Now to get all this stuff into CVS...
2002.02.20 ~03 Icculus's Razor
More fitting for a cookies/fortunes file, but oh well:
"If it takes more than two minutes on Google to find an ISO, your distro is no longer qualified to be called 'modern'." -- Icculus
2002.02.18 ~12 FLAC
While perusing the Ogg Vorbis mailing list archives, I came across FLAC, Free
Lossless Audio Codec (for context, the discussion started with a suggestion of
a lossless mode to Ogg Vorbis, then a possible merge with FLAC). I may look
into FLAC, instead, as its decoding can be done with integer-only arithmetic
(read: faster in QVM than Vorbis).
2002.02.17 ~02 just after reading chunky's .plan
echo 'set nocompatible' > ~/.vimrc
Ha.
2002.02.17 ~01 Ogg Vorbis integrated?
Trying a complete decoding of a test ogg to a test.raw finishes without
crashing (ov_read()). But the numbers come out all wrong. I think it might
be because the Q3VM 32-bit floating point values don't have enough precision
to decode properly, but I'm not so sure.
2002.02.17 ~12 Ogg Vorbis integration progressing
Good news: TestVorbis1() doesn't crash.
Bad news: It doesn't exit, either.
2002.02.15 ~08 V-Day
There's something missing from Valentine's Day.
Christmas : Scrooge :: St. Valentine's Day : ???
2002.02.15 ~07 UDF
UDFFS makes a lot more sense for file storage on CD-RW discs, than using
ISO9660, ext2, or some other filesystem designed for extensive rewrite/deletes.
Although UDF support in GNU/Linux has a rather high suckage quotient, using UDF
sure beats out ISO9660 (mkisofs(1) and whatnot). Using ext2fs on a
Write-Few-Read-Many just doesn't feel right.
2002.02.12 ~06 NOOOOOOOOOOOOOOO!!!!!
phaethon@gamehenge:~$ uptime
1:10am up 4:33, 11 users, load average: 0.00, 0.14, 0.25
^^^^^^^^
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2002.02.11 ~08 shells shells shells
Why, yes, I do need 18 simultaneous shells open. Why do you ask?
2002.02.10 ~06 AOL 7.0
Hrm. Got an AOL CD ("All-new! AOL 7.0"/"Try it now for 1000 Hours Free (for
45 days)!") by snail mail. It's addressed to "Current Resident", so apparently
this came as a result of some kind of carpet-bombing campaigns, and not because
I'm still on AOL-TW's "list of people to send a CD".
Intriguingly, the provided "password" is "KNOW-THANKS". Phoenetically, that's
exactly how I feel about AOL, minus a few choice colorful words sprinkled
before, after, and in the middle of the phrase, along with explicit suggestions
of what they can do with this CD.
In any case, now I have another layer of protection (if rather busily colored)
between my hot drinks and my desk, and the provided DVD-style cover (after
removing all labelings) is well-suited to housing my more precious CD-R discs
(i.e. Debian CD, backup of ~)
I probably wouldn't be as annoyed at these AOL mailings if the text didn't talk
down to me like I'm a dull-witted, Windows-using, bandwagon-hopping luser.
2002.02.04 ~10 ogg vorbis
The OggVorbis reference library is rather hefty. Gonna take a bit of hacking
to get this to work in QVM. So far, it reports my test ogg as 16-bit 22KHz.
That looks about right. Currently, my mod is dying horribly somewhere in
the Vorbis codebook initialization.
2002.02.04 ~09 minor research
I should start collecting stats on how long it takes people to finally adjust
to writing the new year's number.
There also needs to be a unit of measurement to measure the level of
embarrassment experienced by a person realizing that they've been using the
wrong year for over a month.
2002.01.31 ~23 more CD-RW discs
OK, postpone that MD3-in-Blender trick. The Q3 MDL format is a bit trippy.
Importing from MD3 maybe easier than exporting to. That, and I gotta
relearn python.
Got a 20-pack of CD-RW from Costco. For once I may actually be able to do a
true backup of my system.
2002.01.30 ~10 blender, python, .md3
For my next trick, importing and exporting Q3 MD3 (model files) to and from
NaN's Blender Creator (
http://www.blender.nl/).
2002.01.30 ~07 not hacking gcc
Please quit asking me to hack gcc to compile directly to QVM. Please.
2002.01.29 ~08 -o loop
I dunno just exactly what causes this problem, but it's reliably reproducable:
generate a romfs image
burn directly to CD-R/CD-RW
mount -t romfs /dev/scd0 /mnt
mount segfaults, kernel oopses <- the problem
(drive remains inaccessible until kernel is killed (read: reboot))
Then (after a reboot), doing the same mount command causes segfault and kernel
oopses. Reboot again, then throw in a "-o loop":
mount -o loop -t romfs /dev/scd0 /mnt
And everything's all hunky-dory. No segfault, no kernel oops, and I can read
stuff directly off /mnt.
This is on a K6/2-350 with 192MB RAM, linux 2.4.17.
My laptop has a DVD/CD-ROM drive, where doing the "-o"-less form on the same
disc doesn't cause an oops. Celeron/400 32MB RAM, linux 2.4.17.
As near as I can tell, it's romfs barfing. Might be a combination of something
in romfs with one of the modules involved in driving an IDE/ATAPI CD-RW drive.
Since I've figured a workaround in the meantime, I don't feel like hunting
down the root cause. If this crops up in 2.4.18, I'll probably go a-hunting.
2002.01.28 ~22 CD-R spindle
Bought a spindle of 50 CD-R blanks. These CD-Rs look shinier than CD-RWs.
It's burning time.
Rewriting at max speed wedges all other apps on my system. Probably doesn't
help that the bulkier swap drive is on the same IDE cable as the burner.
Trying to mount romfs from CD in CD-RW drive causes kernel to oops. Hrm.
Doesn't happen on CD-ROM drive.
2002.01.28 ~09 Growing wiser in the matters of CD-based storable media
After much more reading, I now know the (physical) difference between CD-RW
blanks and CD-R blanks, and why CD-RWs are, therefore, more expensive.
The phase-change nature of CD-RW does a number on my "intuitions", but, hey,
if it works...
I recall the first generation of CD-RW being rumored to be good for only 3 to
5 rewrites. The CD-WRITING HOWTO implies that current effective number of
reuses are either widely varying or indefinite (or both...).
I should get a spindle of CD-R. It's cheaper and faster, and arguably more
permanent and more readable by (other drives). I'm also running out of
coasters. A mug of hot cocoa leaves a nasty mark on even fake wood, and AOL
took me off their "People To Annoy With Free Trial CDs" list or something.
Maybe it's because of that "@linux.ucla.edu" e-mail address of mine...
2002.01.27 ~08 first burn go boom
Ran my first real CD-RW writing session. It looked like it finished properly,
but upon trying to mount the newly written disc, kernel oopsed. IDE driver.
Very bad. Reboot :(
2002.01.27 ~00 playing with CD-RW
Being new to CD-RW (or any non-ROM optical storage), I read up on and played
around with 'cdrecord' and 'mkisofs'. Decided to give dummy-writing a go to
see how long it would take.
# dd if=/dev/zero bs=1M count=650 | cdrecord dev=0,0,0 -dummy -
After it did the normal 10-sec countdown warning and started, I C-C'd it after
6 minutes since it defaulted to 4x speed and I calculated it would take over a
half-hour to "write".
The WRITE LED stayed busy.
I pushed EJECT.
WRITE LED stayed busy.
I waited.
WRITE LED stayed busy.
Played a round of Quake 3.
WRITE LED stayed busy.
Played a few rounds of Tribes 2.
WRITE LED stayed busy.
By now, the WRITE LED stayed busy for three hours (more than enough time to
write even in half-speed). As an IDE/ATAPI CD-RW, I figured all I need to do
is tell the hardware to give it a kick to the interface. A reset. But I
didn't want to reboot. Check hdparm(8), canonical tool for doing untowards
thing with the IDE system. Lo and behold, drive reset:
# hdparm -w /dev/hdc
WRITE LED went non-busy. CD ejected. CD-RW responded to bus queries, et al.
Happiness.
Then I tested with a 10MB chunk of zeroes and speed=10 (16x10x32 drive).
12 seconds. Then 65MB. 51 seconds. Multiply. 8.5 minutes.
Should test if it'd buffer underrun next.
(20 minutes later)
Yep. 8.5 minutes, and no buffer underrun.
2002.01.26 ~19 Hardware additions to home system(s).
Purchased yesterday:
LG CD-RW (16x10x32), US$79
K-Byte (generic brand?) 512MB PC133 SDRAM, US$58
TDK 5-pack CD-RW data[1] blanks (rated for 10x), US$8
Before
Penelope - mini-tower, K6-2/350, 64MB RAM, 6GB+10GB+42GB HDD, Matsushita CD-ROM (4x)
Anticleia - mini-tower, K7/1200, 256MB RAM, 2GB+1GB HDD, IDE ZIP100
After
Penelope - mini-tower, K6-2/350, 192MB RAM, 6GB+10GB+42GB HDD, LG CD-RW (16x10x32)
Anticleia - mini-tower, K7/1200, 512MB RAM, 2GB+1GB HDD, IDE ZIP100, Matsushita CD-ROM (4x)
Penny's mainboard (VIA MVP3 chipset) can only handle 128 max per DIMM, thus 192MB and not the expected 320MB.
[1] damn the RIAA
2002.01.25 09UTC FI alpha release 00000
My Scheme interpreter stopped puking in QVM mode. I'm ecstatic enough to just
throw together a mod release based on what I have now.
Of all things, one (but frequently visited) switch()'s case fallthrough in the
Scheme interpreter was causing Q3VM to corrupt its opstack. I thought this
problem (fallthrough-causing-corruption) was fixed a while ago, but now I'm
making a mental note to avoid any switch() fallthroughs in future mod code.
For future reference, CVS tag "fi_00000".
2002.01.24 ~23 .plan Makefile
Fellow gamehengers tell me there's some sort of automatic .plan-update notifier
doohickey running that announces when a gamehenger's .plan is updated.
My .plan is decomposed into individual file per entry that gets mashed together
with a Makefile. This provides me with the following flexibilities:
* Create .plan from pieces (duh).
* Selective choose n most recent pieces for the actual .plan.
This helps cut down on byzantine .plan sizes.
* Change the order of entries at whim (newest first or oldest first).
* Work on entries remotely then upload to gamehenge without having to lug around a complete copy of my .plan.
* Meditate on the meaning of using .plan as an online diary.
As for the auto-notifier, I hope it didn't flip out on my first dozen test runs
of my Makefile.
2002.01.24 ~22 q3asm-turbo3
(later that day)
OK, got it to work the way I wanted it.
The problem hinged on the combination of lcc's output of values and the way
atoi() functioned. Floating-point values are expressed in the .asm files as
positive decimal value forms of little-endian IEEE-whatever-thingy
floating-point format interpreted as an integer. This meant the decimal value
could range anywhere from 0 to (2^32 - 1). However, there were explicit byte
vales of "-1" in various places as well (which made me keep atoi() for a
while). Signed values are capped at 0x7FFFFFFF in atoi() (as it should), but
the float-point values were frequently surpassing that limit. So almost all
the floating-poing values were coming out as 0x7FFFFFFF, since they were
expressed as Very Large Decimal Values. (I have problems expressing my
technical thoughts...) The end result was that a whole lot of math functions
came out insane.
The workaround was to create a new function that converts to something larger
than 32 bits (long long on gnu-x86 is signed 64 bits), then smash it down to 32
bits in a "proper" manner. This might prove unportable, but like
relnev^WPeople's Linux-Centric Modifications To the Quake 2 Game Source, I'm
more concerned about making this work correctly on linux-x86 right now.
Thus ThingThatConvertsDecimalToSigned32SoThatAtoiDoesntCapAt7FFFFFFF().
At last, nice speedy 2-second linking that comes out correcty.
2002.01.24 ~18 q3asm breakage
q3asm unpatched apparently comes out horribly broken under linux-x86. As far
as I can tell (AFAICT), it has something to do with bit-shifting and
sign-extensions. With the help of a hex dumper, all 32-bit values over
0x7FFFFFF in the proper qvm output comes out as 0x7FFFFFFF in any q3asm I try
to compile from source.
Maybe there's some Secret Spidey Switch in GCC that needs to be activated?
In the meantime, I'll just grovel through the q3asm source and see if I can
make it work right without special GCC switches.
2002.01.23 ~00 q3asm-turbo
http://www.icculus.org/~phaethon/q3/q3asm-turbo/q3asm-turbo.htmlIn the course of trying to debug my Scheme interpreter (which fails horribly
in QVM bytecode form), I got very annoyed at the tremendous wait time for a
complete compile cycle to finish, with q3asm taking up more than 60 seconds.
This long of a wait for each tiny tweak.
So I set out to speed up q3asm.
I hacked q3asm to support a chain-and-bucket hash table, where symbol values
were to be stored during the symbol table construction pass (pass 0). By
just using this hash table for lookups alone, linking (q3asm life time) shrunk
down to 28 seconds.
After spotting a singly-linked list insertion sort in pass 0, I diked that
out, and linking time dropped to 3 seconds. I nearly did very aggravating(?)
things to my pants.
After groveling through the source, I concluded that sorting the symbols list
(by value) never did anything worthwhile in q3asm, anyway.
Then I sought to optimize the foonting turlingdrome out of q3asm. With the
assistance of GNU profiler, I hand-optimized various heavyily-called
functions. Or at least I think I optimized them.
q3asm-turbo2a regularly reports 1 second elapsed compiling the game/
module of my mod. But my Scheme interpreter is equally broken in unmodified,
turbo1, and turbo2a, so I don't know if the modified q3asm actually works
correctly. But it's swutting fast :)
2002.01.22 ~00 FI demo floating
So out of both altruism and ego, I provided a demo of an older version of FI to someone on IRC.
Already someone else is nabbing it, viewing it, and commenting about it.
So I made a new demo based the current CVS version, and linked both demos in my web site.
2002.01.21 ~00 ln .plan .diary ?
Seems everyone else is using their .plan as a kind of online journal.
I think I'll give that a shot as well.
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
* The initial extensible language for Project FI.
* Subset of R5RS (
http://www.swiss.ai.mit.edu/~jaffer/r5rs_toc.html).
* Deal with idiosyncrasies of Q3VM not handled by most other Scheme impls.
* Planned for eventual scrappage in favor of Common Lisp (but looking less likely with each CVS commit).
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)
* Needs serious code cleanups
* port to PalmOS SDK 4.0
* generalize the interface to become "any-gfx" viewer (libpnm?)
b. ZBoxZ (file manager)
* beef up its appness: menus, dialogs, pen actions