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.12.20 ~23 Rise of the Triad GPL'd
Well, crap. RotT went GPL, and my hands are already full with the Q3
toolchain, two Q3 mods, and SMPEG.
2002.12.20 ~11 bummer... q3as == Quake 3 Advanced Server mod
I planned to split q3asm into two distinct tools, "q3as" for just the
assembling, and "q3ld" for just the linking. Apparently the term "q3as"
is already used to describe a Q3 mod oriented towards server admins,
Quake 3 Advanced Server. I have no idea what it does in particular, but
it came up during discussion of the other Q3 mod I'm working on
(Q3Matador,
http://q3matador.dragon-rider.org/), in the context of
planning additional features.
I don't know what I should/could rename the assembler-only tool to be.
First thoughts are "qas", "asq3", and "q3vmas". Whatever it is, I plan
on reusing the naming pattern for the linker tool.
2002.12.19 ~08 MSN TV ad
Several weeks ago, I was watching TV, and for the first time saw an
advertisement for MSN (Microsoft Network). Before I had cable TV
installed two weeks ago, I didn't watch any TV. At the time, I was
watching TV at someone else's house (cable TV at that).
First the laughing part. While this ad was running, I was chewing on
pizza (jalape?os & ham, as I recall). I reiterate this was the first
time I ever saw a MSN ad on TV. As the voiceover rattles on about the
benefits of MSN, they said, and I quote, "with advanced Microsoft
technology". At least I wasn't sipping milk nor soda at the time.
Thankfully I didn't snort the chewed-up stuff out my nose (jalape?os).
But chewed-up pizza looks rather nasty. I think I went on laughing for
the next two minutes.
Next, the disturbing part. I didn't realize this until I pondered on it
for the prior... uh... 10 minutes. The TV ad sports a male, in a
brightly-colored suit, resembling a giant butterfly, covering up
pictures of scantily-clad women. With the wings of the suit. Something
just doesn't jibe here.
And I just realized something else here... The MSN mascot goes around
eliminating any attention-grabber (boomboxes, lifesize images of women,
etc.). Covers up said attention-grabber. Presumably to draw attention
to the brightly-colored winged suit, and person within. And while
covering said attention-grabbers, thrusts chest out at a child.
Repeatly steps into the line-of-sight of said child, and thrusting out
chest. This MSN character turned his back on a picture of a nubile
woman and thrusts his chest out at a (underage) girl. Then chases after
said girl, running ahead of her, repeating the chest-thrusting actions.
OK, so this MSN person goes around eliminating distractions, tries very
hard to draw attention to himself (q.v. bright-colored butteryfly suit),
constantly places himself in the child's line of sight, turns his back
on a picture of a naked of-age adult in favor of aiming at a child,
repeatedly thrusts out his chest at an underage child, AND STALKS HER!
Um, hello?! What is MSN about, again?
2002.12.10 ~09 Q3VM /dev/tty
Well, it's done. In the cvs repository for my Q3 mod, there is now a
(dumb) terminal emulator. Currently the tty devices is capable of some
sane reads and writes (i.e. open("/dev/tty", O_RDWR) acts as expected).
The tty device can provide uncooked key input, but no line-buffered
input yet (as expected by various command-line code). Local echo is
implemented, and could be toggled if the termios functions were done.
Writing to /dev/tty works as expected. Text falling off the bottom of
the tty region scrolls the text as expected. Scrolling the other way
not yet tested. Only a subset of command characters yield non-character
effects: BS, NL, CR, LF. Other command characters produce glyphs.
Backspacing past first column not tested.
Reading from /dev/tty produces an octet stream of characters. Raw
keycodes and key release events are not reported via /dev/tty (but
instead in /dev/keyboard).
Also supports ioctl(), and I made up a bunch of TIOC_* constants to fit
the idiosyncrasies of Q3VM. For example, the cgame module needs to
explictly blt the tty content every frame, by calling ioctl() with a
request value of TIOC_DRAW (this should be renamed to TIOC_RUNFRAME or
something later on...).
Later I plan support for some of ECMA-035 (character sets extensions)
and ECMA-048 (control characters and escape sequences).
2002.12.07 ~02 Q3VM devfs
Well, another layer thrown in. This time to simulate kernel-level calls
for file I/O. POSIX is hardly an optimal model to copy, but it's has a
long-established tradition, and been documented to hell and back.
I finally settled on having a separate /dev/keyboard, to allow for
eventual reads of raw key events (press and releases). Key release
events are not handled by /dev/tty; the tty device only handles byte
streams, not structured data or release events. I'm wondering if I
should have a separate /dev/mouse devices instead of integrating mouse
events with the keyboard device.
The keyboard device isn't actually _used_ yet, but it's a stepping stone
towards getting /dev/tty to work as expected.
BTW, doing /dev/null was very easy. Every function returns 0. :)
Also, being the easiest device, it also doubled as scaffolding for the
other devices.
SUSv2 demands a /dev/console. It just demands the device exists, not
that it does anything in particular. I'm thinking of implementing this
as a replica of the currently extant chat box (the three text lines at
the top of the screen that gets spammed with everything), as the sink
for writes to stdout and stderr.
2002.12.01 ~05 glib removal
I got glib-1.2.10 ported to Q3VM, but didn't commit the relevant source
tree. I planned not to until I can figure out if there are any
licensing conflicts. I finally got around to poring through the LPGL
and the Q3A Game Source License (Q3AGSL) back-to-back and side-by-side.
My understanding is that the two licenses conflict with each and declare
the ability to copy (and other copyright activities) is revoked due to
each other, that is, both of them point at each other and claim license
violation.
Or at least I think this file called "QIIIA Game Source License.html"
applies to the mod source...
The wording in the license sounds rather like some kind of model creator
or map editor program, rather than the baseq3 mod source. The major
sticking point in my reading is where the Q3AGSL prohibits
reverse-engineering (section 2f), but the LGPL requires RE ability
(section 6).
I wonder if this applies to baseq3 mod source itself, since Q3AGSL
section 2j prohibits preparing or developing derivative works based on
"the Software", which describes just about every Q3 mod in existence.
Obviously those Q3 mods aren't illegal, so either I'm reading this
license wrong, or this is the wrong license.
2002.11.30 ~06 Blue Sky: Q3VM... ".qso"?
I got into a conversation over the limitations of Q3VM and wishlists for
it. The discussion came down to having a scripting interface for
modding, much like my idea for using Scheme in my own Q3 mod. I
mentioned that one of my gripes about Q3VM is the complete inability to
have third-party add-ons. All that is available is the .qvm file.
Nothing else can run as code text.
One useful addition would be a shared-object mechanism, to load
third-party code. Trustworthiness precautions mean there would need to
be a tiered syscall mechanism. Or something like that. The idea is
that first-party modules (i.e. from the mod team, in the distribution
paks) can have willy-nilly access to all traps, while third-party
modules (non-pk3; on the host filesystem) shouldn't be allowed
access to all traps (such as the traps to change wall textures...).
These ideas still apply to my Scheme implementation. Currently I have
all client-side traps wrapped in Scheme, but all loadable programs
shouldn't have that much access to traps. This pretty much follows from
OS rules of thumb that userspace code shouldn't have all the access that
kernelspace code does. Restricted access helps limit rogue programming
and helps thwart malicious code (*cough*cheats*cough*).
Perhaps I can glean something from various real CPU architectures. I
recall the M68K having a supervisor bit, and the x86 having rings (rings
of what, I don't remember).
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. Q3VM libc
* Implementation of Standard C Library for Q3VM bytecode.
* Implementation of a subset of Single Unix Specification v2 (SUS v2).
* Help import third-party library into Q3VM.
4. 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.
5. Q3 compilation toolchain
[X] q3lcc sources (official version out with Q3A SDK 1.32)
[X] q3asm - get static to work, dammit.
[ ] q3as - assemble-only (.asm to .o).
[ ] q3ld - link-only (.o/.a to .qvm).
5. 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