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