Finger info for phaethon@icculus.org...



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.05.16 ~06 QVM-bytecode libraries

I was pondering the separation of the libc files into a separate directory.
This would mean altering the compilation scripts (bash scripts) to
deliberately reach into the libc directory, compile each file to assembly,
then explicitly link the resulting files. Then I wondered how I could cut
down such tediousness (i.e. editing a couple files to list every single
file affected).

One method that sprung to mind was using ar(1), creating .a files for each
distinct library packages, e.g. libvorbis.a, libc.a, libz.a, etc. These .a
files contain distinct .o files, each derived from an associated .c file
(for the most part). The .a file can also contain a symbol table, an
association of symbols to locations within the .a and .o files. So for
each library package, an associated .a file is created. Then if some
symbol "funcfoo" was needed, the linker (q3ld?) can look through some
existing .a file (e.g. "libmystuff.a"), find "funcfoo" is defined in
"foo_bie.o", extract "foo_bie.o", and link it into the resulting qvm,
taking into account adjusted offsets.

The end result is a simplification in adding new external sources. I would
no longer need to edit the compile scripts to list every .c file to look
at, every .asm file to link. Instead, I would need only to compile each
"library package" separately into .a files, then leave the tasks of
searching and resolving to the linker.

To do the adjusted offsets (of symbols) would mean needing some kind of
structured format for the .o files to keep track of "normal" offsets.
Using an already existing format, such as a.out or COFF or ELF, would allow
using standard ar(1) and ranlib(1) to create the .a files (and its symbol
table). Doing so would also save me the trouble of trying to come up with
an appropriate format then re-extending it repeatedly in the future :)
This could mean utilizing GNU BFD in some form.

At this point, I realized something chilling. The .a files are
self-contained; they don't "depend" upon outside files for its content.
In other words, it would be very much "drop-in". Binary drop-in.
Libraries could be distributed without source.


2002.05.14 ~01 Nightmare flashback

So I was just driving along and out of the blue came a flashback of a
nightmare I had several years ago, when I was in middle school (jr. high).
Well, more like a recall, but "flashback" sounds more dramatic =)

The details are fuzzy, but the major points were basically these: a world
(or city, rather, as my "world view" at the time was rather small) where
there is a central "operating antenna", resembling a tower radio antenna,
by which automobiles are able to run. All automobiles in existence had to
check through the antenna in order to run at all; those that didn't failed
to start. So far things are already deviating pretty wildly from reality.

The scary part is when the antenna failed. It just lost power suddenly;
looked like a major power outage (blackout) to me. In any case, the
result was that all cars stopped immediately (engines just choked to death)
and could not be (re)started. I was stranded. Mind you, most of my life
was spent in and around Los Angeles, California, driven around by my dad
to one extracirricular activity to another. This is a city where "mass
transit infrastructure" is a Bill-Clintonism ("it depends on your
definition of 'mass transit'..."). So being stranded in some remote
place with means of transportation seemed plausible at the time.

So, anyway, thus far, this "central automobile antenna" died and all cars
were rendered useless on the spot until at such time power was restored
(and I don't remember that happening...). And so I was stranded in some
remote pocket of the world (or rather, L.A.). Far away from home. This
is rather terrifying for a 12-year-old raised in a "traditional" nuclear
family.

Sounds crazy so far. And rather irrelevant. But as I pondered through this
nightmare, I found a parallel to the modern world. Not cars (yet), but
rather software. Think about it. The fascist licensing models used by a
disturbingly increasing number of software [of any kind] where authorization
to run, much less even to start (or even install), must be cleared through
a centralized inet server. Should the connection be severed or denied, for
any reason, the software dies, perhaps taking (live) data with it.

This would be different kind of stranding, but just as terrifying as in
my nightmare. In some ways, more terrifying. Denied the means to support
myself (or be supported at all) by an external force beyond my control.
Should the central server undergo a sudden failure in existence, no amount
of money thrown anywhere will help resurrect such bondage software. And
without source, no amount of time spent will help either. And at the rate
current US legislation is headed, no amount of technical genius would help
either (as it would be outlawed).

I frequently reflect back on my views of Free software over the years since
I was first introduced to GNU software and stumbled upon the *nix universe.
At first, I found libre software to be "cool", as the philosophy of GNU and
other free software oufits happened to overlap much of my thoughts and
philosphy that I had developed independently of the *nix community,
interestingly enough (e.g. the value of source, the value of sharing, the
crazed notion of claiming loss of money never headed your way in the first
place). Then I found it "convenient", as Linux easily stepped around the
2GB BIOS fiasco (PC hard drives) of the late 90s, and Debian GNU/Linux
magically fixed itself from a libc5->libc6 bung-up (I still have no idea
how it did that; I swear I f*cked up the upgrade!). Then it became
"practical", as libre software let me do what I want to do, rather than be
limited by the [original] author's notion of what ought to be done (cases
in point: Window Maker customization, sawmill/sawfish customization, three
simult XFree86 sessions, massive cheats hacking into snes9x (Super Nintendo
emulator) like rapid-fire and joystick macros).

In some ways now, I see libre software as "critical". When I was 12, the
notion of automobiles umbilically tied to the functioning of a single
operations antenna terrified me. Nowadays, the notion that software being
similarly tied to a centralized inet server is fairly terrifying. The
notion that the mere existence of my data, and/or my ability to use my own
personal data, being intimately linked to the market performance of some
company, is contrarian to the notion of personal liberty, never mind
conflict of interest. If I'm driving a Ford F-150, I really don't want my
ability to start and drive the truck to be intimately linked to whether
Ford Motor Co. will decide to continue the line or not, or whether they
might declare bankruptcy today/tomorrow/next week.

In today's world, I (among many) would consider silly the idea that a car
would suddenly fail to work any more simply because the associated car
company said so. I'm not certain if contemporary proprietary software has
reached this far, but, to me, this seems a very likely scenario given
current trends of "subscription" (more like "rental") software. Libre
software certainly is among the solution to ensuring that the free market
stays free, without any one company's dictate controlling the activities of
any other company beyond the force of "The Market"/"The Invisible Hand".


2002.05.07 ~17 "static" support in q3asm

Ogg Vorbis reference library makes a few uses of the static keyword for
some functions. Staticness is recognized by q3lcc, and it shows in its
assembly output; static functions do not have their symbols flagged for
exporting. The linker, q3asm, blithely ignores staticness, along the
lines of: else if (!strcmp(token, "export")) { } else ...
In effect, all functions are exported; static functions aren't static.
Although I already patched Ogg Vorbis to be static-less, WIBNI
q3asm properly understood the [not] exporting function symbols.


2002.05.07 ~04 Q3 libc

My reimplementation of various additional Standard C functions for Q3VM is
growing large enough to be its own project. I'm thinking of moving the
files into a directory of its own, in both the CVS and (home) web trees.
The game/ directory is starting to fill up with too many bg_* files.


2002.05.06 ~08 Spider-Man the Movie

Yesterday I watched the Spider-Man movie. Overall, I was very impressed and
satisfied. I think sticking to the original comics (story-wise) really helped
with the quality; this particular movie displayed a level of cause/effect,
consequences, and reflection deeper than the usually Hollywood cruft.

I am very *UN*familiar with the whole Spider-Man story. My exposure to
Spidey have been primarily limited to offhanded remarks, a handful of cartoon
episodes, and hours of watching "Marvel vs. Capcom" (1 and 2). Still, I was
quite aware the original Spidey was created a few decades ago, definitely
before 1985. In light of this knowledge, the "era-syncing" in the movie
really impressed me: cellular phones, car models (no years shown :),
ubiquity of computers (somehow everyone could afford LCD flat panels...),
and the newspapers listing of Help Wanted for computer jobs when Uncle Ben
browsed though it (Comp. Analyst, Comp. Salesperson, S/W Engineer, etc.).

The opening scenes in the movie (opening credits) were quite engrossing,
despite the fact it was minutes upon minutes of miles upon miles of CGI
spider webs. Later through the credits, though, are flashes and scenes
of characters, buildings, and swinging flight paths between buildings.
A look at things to come, sort of.

I do recall [original] Spider-Man resulting from the bite of a radioactive
spider. The movie slighty modifies the spider to being a genetically-
engineered spider (broken free from its cage), inducing a DNA alteration
in Peter (but overnight transformation is still pushing it, puberty or no
puberty...). I find this more plausible than $random_radioactive_object,
but I think the significant theme in this part of the story is $freak_spider.
Sort of reminds me of the way the ancient Greek mythos were passed by word
of mouth from generation to generation, with the details being updated with
whatever was contemporary at the time of telling -- radiactive then,
genetically-engineered now.

I certainly think the field trip scene vastly differs from the original
comics -- 40-ft scanning electron microscopes certainly weren't available
in '85 (at least one dedicated to arachnology). Although what arachnologists
need with a such a huge SEM is beyond me (direct DNA observation is about the
best I can think of). Still, the lab scene gave interesting foreshadowings
to Spider-Man's ability: insane jumping (hunting spiders), obscene web
strength (never mind the organo-vs-mechano webbing flamefests), and
short-term premonition ("Spider sense"). The gen-en'ing going around
in the movie certainly made me think this fantasy world would've somehow
gotten all these abilities wrapped up in one specimen. Oh yeah, and the lab
was decked out with LCD flatpanels and plasma screens.

Peter's first day of Spider P0W@HZ was enjoyable to watch. My particular
favorite is all the eye-candy slow-motion right before Peter dodges a
locker-denting punch. Also, the explanation for Spidey's wall-crawling
ability cleared up one of my biggest questions, even if it isn't the
original's: retractable bristles/quills (they reminded me of barbed bee
stingers, actually) on the hands that cling (in)to surfaces. After the
movie, I did some very raw mental calculation and concluded that each
"quill" would be sustaining roughly 0.5 to 1.5 lbs (220 to 680 g) each
if used as the sole means of support. Not too unrealistic, IMO.

The stretch of experimentation was also fun to watch and ponder. I suppose
the process of discovery and experimentation is something that piques the
interests of introverts everywhere. This paragraph may have been unnecessary.

Then there's the webshooter. I was very certain (original) Spider-Man had
to construct mechanical webshooters; something about fooling around with
formulas and one time really f*cking things up with his webs as a result.
The movie has "organic webshooter"; "built-in" webshooters as a direct
result of the spider bite. The rest of the movie flowed pretty well with
the organoshooters, but organo raises a few [other] questions for me.
Such as: that's a helluva lot of web -- eat hearty dude; normal spiders
have a web sac that contains liquid that turns solid upon hitting air --
does his arm have enough room for both sac and muscles?; how does Spidey
reel back into the rafters -- sucking the web back into his arms? And so on.

Costume. Peter goes to a ["pro"-]wrestling match to nab an 'easy' $3K with
his new superpowers. He goes with a dorky-looking outfit: pants, silk-
screened sweater(?), balaclava. This despite Peter having finished his
concept drawing of the outfit commonly associated with Spider-Man. Then
his uncle gets killed. This is the part of the story that had me notice
the depth of cause/effect and consequences was deeper than most of the other
movies out of Hollywood I've watched. Later on, out of the friggin' blue,
Peter somehow obtains the "real" Spidey costume... with raised embossed
lines and whitish plastic eye ports. This is just screaming "I am f*cking
expensive!". Yet this kid just starting college and working his way through
obtains this costume without anyone noticing. And it's tough material: it
takes a point-blank shrapnel grenade to even tear off half the face mask.
Seriously, the Spider-Man outfit literally pops out of the fscking blue.
One day he doesn't have it, the next day he's swinging around among highrises
with the trademark Spidey suit going crime-busting.

Green Goblin. Some reviewer said the GG (costume) was a bit cartoonish.
I agree somewhat. Much of the facial form is (understandably) exaggerated,
but little of the face inside is viewable, nor shows through (at least
Spidey's mask deforms as his jaws move). This would explain why the movie
had a few times the Goblin's mask's eyes open to show the person's eyes
underneath. And the movie's Goblin mask is (thankfully) much less scarier
than most clown faces. And in another one of those Great Unanswered
Questions... where the swutting heck does that costume come from? I've
never seen it exist anywhere but when Osborne gets all pissed and suddenly
appears in that costume/armor. At the end of the movie, I expected a Darth
Vaderish laying down of the mask next to the dead body. But the GG costume
just ups and disappears. Like the way it appeared. Really irritated me
for some reason. I expected at some time during the movie to see the entire
vacated armor in a closet or something.

Green Goblin's glider/flyer/whatever. Enjoyable back story to it (result of
human performance enhancement widgetry research [hovercraft airfoil], which
conveniently was done within the confines of Osborne's/GG's company Oscorp,
and thereby provided a convenient mechanism by which GG obtains a means of
transportation), except... good grief... I don't think even Star Trek had
devices so gaudily packed with widgets and whizbangs.

The Sadistic Choice -- love or duty with death(s) on the line. Seems every
superhero faces one. Is this some kind of running gimmick among all comics
or something? I know Batman faced one, I'm pretty sure Superman faced a
couple, and heaven knows how many the members of X-Men faced. When GG was
giving the speech on "The Sadistic Choice", I was wondering if he was talking
about the entire superhero genre in general. Actually, I think he was,
but it sounded more like he was preaching to some vague audience than to
Spider-Man in particular. The scene was borderline cliche for me.

The final showdown. About when the tides turn, I'm reminded of a quote
from some place -- when you have your enemy/ies down (but not out), don't
ever give them time to build up a second wind (especially by gloating or
excessive taunting). In any case, Green Goblin's final strike was about
as predictable as Wile E. Coyote's attempts as soon as I saw the glider
levelling with Spidey's back. Let's see... I face Spider-Man square on...
I try to sneak up my massively huge glider right behind him to try to impale
him full speed... all three entities are colinear... gee, I maybe I'll be in
the line of fire. Looks to me that Osborne never used a gun (rifle in
particular) seriously, otherwise the concept of "overpenetration" would've
dawned on him before calling for his glider. Or maybe he was going for
kamikaze: "I'll take you out even if it takes me out as well".

On the whole, an enjoyable movie, especially since I don't know enough to
be nit-picky, but knew enough to have a clue where the next few minutes
were likely to be headed. In the meantime, I'm pretty certain the first
dozen hits for Spider-Man on Google are inundated, so I'm avoiding hitting
up any Spidey-related info for a week or two.

This movie just screams sequel. I just hope the title won't wind up corny.


2002.05.01 ~09 Ogg Vorbis in QVM

Nailed the problem. It was a faulty ldexp() [re]implementation. Decoding
sounds MUCH better now. Now for the commit...


2002.04.27 ~04 Mod development using Scheme, prospect not good

My goal was Scheme in QVM mode. Unfortunately, the layers of interpretations
causes Scheme to be extremely slow, even in the JIT(?)-compiled. I wrote
a set of accessor routines in Scheme to modify the values of various C structs
involved with gameplay. On my K7/1200 (hardware which I consider to be
excessivly powerful for just a mere dedicatd Q3 server), in compiled QVM mode
(vm_game 2), just *loading* this file takes 30 seconds. In interpreted QVM
mode (vm_game 1), this explodes to 180. In native SO (vm_game 0), it's a
relatively speedy but still slow 3 seconds ('Hitch Warning' is 0.5s). And
this is just loading this particular set of procedures, not even getting to
the other support functions and then actually *running* any Scheme code.

Trying an entire mod in just extension form is out of the question. I feel
the optimal tool would be a Lisp compiler targeted to QVM bytecode, but I
doubt that exists, and doubt it'll exist until Q3A goes GPL, and even then,
I doubt any Lisp maintainers would really want to bother targetting QVM.

Another alternative is a Lisp->C compiler (like CLiCC), which then uses the
existing toolchain to compile the generated C file to QVM. This approach
may be a better one than tacking Scheme onto the mod as an extensible
language. At least the speed-critical/impaired functions (like, say, struct
accessors) can be made speedier. I'll need to look into this approach.

Still, QuakeScheme in its current form is still useful for "build-up" stuff,
implementing new features -- prototyping. The set of routines established so
far is useful in poking and prodding the structs, to see values were inserted
properly, or to see what values were inserted, or to force the proper values.
Although the Scheme code is slow, prototyping in Scheme precludes the need for
a C compiling. And despite a complete recompile taking less than six seconds,
not having to quit/restart Q3A means I don't have to rebuild session states
(players, bots, entities, etc.) for testing/debugging. Once the Scheme form
is stabilized, the routines can then be rewritten in plain C for speed.

CLiCC may help make that last part automatic, though... hrm.


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


When this .plan was written: 2002-05-16 03:18:36
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.