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.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).
2002.11.23 ~07 Blue sky: Q3VM SDL
This would be one interesting hack. However, large chunks of SDL would
need to be pared down. For example, the image routines would be limited
to load-from-file only, no load-from-memory or somesuch. Other SDL
subsystems may need to be left out completely due to Q3VM limitations,
such as Joystick (Q3 intercepts joystick movement and converts them into
special-case key events) and CDROM. I'm wondering how many SDL apps
could be portable to Q3VM afterwards.
This is a far-off blue sky, though. Much of the libc I have just
returns "not implemented" errors, so while various parts of SDL should
compile and link without problems, SDL won't work as expected (e.g.
select() currently always fails).
2002.11.22 ~00 A limerick inspired by PunkBuster
Originally I planned to have a four-line poem as a suitable .sig, but I
also wanted to capture the essence of my PunkBuster experience by
cutting off the last word with a PunkBusterism. I thought both A-A-B-B
or A-B-A-B rhyming pattern would be unsuitable, due to my plans for
omitting the final word (not enough "priming" for fill-in-the-blank).
A-A-A-A would have worked best. After wanting to mention "autoaim"
(aimbots), I worked through rhymes, coming up with "shame", which
perfectly describes a connection under the influence of Pb. Then I
made up the first line on the fly to fit the AABBA rhyme pattern.
This version is slightly toned down. My intended "distribution use"
version changes "incredibly" into a far more colorful phrase.
It's harder to stay on the Quaking way...
Had to reinstall PunkBuster again today;
The ping is a crying shame,
And llamas can still autoaim,
oh my gawd, this is incredibly g***ERROR***
^5client in distress - could not load pbcl.so
2002.11.20 ~08 Blue skies: vt100, ncurses, and Q3VM.
Firstly, I wanted a way to place random text on a random location on
the screen at random times. There is already a function in cgame for
this functionality. A problem arises if I need to shift the location.
If done in all-C, the module needs to be recompiled. Alternatively, I
could write a QuakeScheme wrapper so the position is adjustable from
Scheme... but if I wrap DrawString(), why not DrawChar()? And the
cell-measuring functions? How about the whole font system?
Then there's the cvars method, but then comes the question of having
more than one string to draw. Have a set of cvars like "string0loc",
"string1loc", "string2loc"? Or the dimensions laid out like "0:20:foo"
in a cvar? I can see this method getting very very messy.
I got around to thinking about cells-based positioning, like a tty with
an addressable cursor. Row 3, Column 42. First model that came to my
mind was vt100. One possibility presented by an addressable-cursor
screen is a full-screen text editor. In real life, there already is a
full-screen text editor with a Lisp back-end. Or rather, a full-screen
Lisp acting as a text editor.
Anyone moderately involved with text mode is likely to be familiar with
the curses library, which helps utilize an addresssable cursor terminal
by presenting a terminal-independent interface (an API). The curses API
is fairly well-established in the area of text mode, and so is a useful
basis for C-coding to a full-screen text mode in Q3. One of the free
implementations of the curses interface is "ncurses", which is part of
the GNU system and thus why its most familiar to me.
As an aside, the Q3 UI is based on a 640x480 units coordinate system
regardless of resolution (and scaled up to current screen resolution);
character cells are 8x16 units. This yields a textscreen resolution of
80 cells horizontal and 30 cells vertical.
If I can whip up the necessary glue code to attach ncurses to Q3VM,
other potentials open up. For one, ncurses also comes with a text
windowing system. In a pinch, the ncurses windowing system can fill in
as a half-baked forms GUI. Porting (or rather gluing in...) ncurses
also allows porting ncurses-based programs to Q3VM. Such as... err...
um... tetris??...
Well, here is one far-fetched possibility arising from getting in
ncurses: Q3nethack.
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