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.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.
2001.02.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
2001.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 (late 23rd hour UTC) .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 (~23rd hour UC) 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 (~18th hour UTC) 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.
2001.01.23 - 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 - 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 - 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/)
Primary goal: provide an extensible environment for a Q3 mod. The intended
notion is that of "mutators" in Unreal Tournament.
Secondary goal: FI:WFC, a more faithful reproduction of Q2WF for Q3 than WFA.
2. QuakeScheme
The initial extension language for Project FI.
Subset of R5RS (
http://www.swiss.ai.mit.edu/~jaffer/r5rs_toc.html)
Dealing 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).