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.29 ~19 Objects in TinyScheme
Attempting GUI in Scheme. The easy way out is to translate the .menu
syntax into S-expressions. This gets sticky when it comes to widgets
performing special actions. In the TA menu system, special actions are
done through "script" actions, using keywords and commands interpreted
by the UI system. This means the set of actions that a menu item can
perform is limited by the commands recognized by the underlying C. And
even then, allows only simple sequences, no conditional nor looping
constructs.
I feel a replacement of the UI system is in order. I intend to use
Scheme as the implementation language for a new UI system, using an
object-oriented widgets set as in most modern GUI systems. I find
SDL_gui to be a useful scaffolding and template, as it is immature (less
code, easier to follow) and lacks the luxury of a preexisting "toolkit"
library (contains code for low-level input and output handling).
Researching OOP in Scheme led me to YASOS (Yet Another Scheme Object
System). While looking through and reading about yasos, I learned some
finer details about OOP and encapsulation, and just how badly C++
mangles the whole picture.
The problem at hand, though, is that TinyScheme can't support yasos
directly, lacking "define-syntax". SLIB can provide a working
"define-syntax" implementation, but I'm having a bitch of a time getting
SLIB to work in QuakeScheme. I could either try to get an almost-yasos
system going in QuakeScheme by whacking up some of the yasos code, or
try to get QuakeScheme to play nice with SLIB.
A yasos-less alternative is to use a different objects system. There
aren't a whole lot of those around. The author of TinyScheme has some
notes on a TinyScheme-specific object system, but (a) the resulting GUI
system would be implementation-specific, (b) the notes are "theoretical
ramblings".
In any case, having a working OOP system would help with widgets and
associated inheritances.
2002.12.25 ~12 Q3A bot files
The runtime files that reside in botfiles/. They munch ass. Seriously.
Mr Elusive ought to be hurt in a very painful manner for using such a
sadistic file syntax.
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.
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