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.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.
2002.04.21 ~03 Documenting MD3 and MD4
http://www.icculus.org/~phaethon/q3a/formats/formats.htmlPartly I was bored, partly the forums at quake3world.com had me realize
documentation on MD3 and MD4 formats is pretty sparse. My documentation on
MD3 format were based on the files from the Q3AToolsSource package, and my
personal experience wrestling with the format for my Blender MD3 import module.
I have no personal experience rangling with MD4. My words on MD4 are mostly
shots in the dark, based on patterns from MD3 and Blender. Still, it's best
to get familiar with MD4 at some level, even if I am spewing hogwash as
I look over the header files.
2002.04.15 ~00 TinySCHEME
Poking around with Google, I came across TinySCHEME. It's a really tiny
Scheme implementation without all the setjmp/longjmp doohickeys I've had
problems with in other Scheme implementations. TinySCHEME is derived from
MiniSCHEME, (heavily) modified to work as the extension language to a mini
web server frontend. TinySCHEME compiles into QVM bytecode with some minor
modifications and a few extra libc function reimplementations.
I may wind up using this as the primary Scheme core.
In other news, I finally got around to slicing down the size of my .plan,
now that I have attained "hugest fscking plan file":
phaethon@gamehenge$ ls -s * | sort -n | tail -5
8 theoddone33
12 vogon
16 chunky
24 yoda
36 phaethon
2002.04.13 ~10 Depressed over tail-recursion
I'm still depressed that my Scheme implementation isn't properly
tail-recursive, and that I still haven't figured out how to make it T-R.
It's been a real showstopper.
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
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