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.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.
2002.11.18 ~07 Q3VM glib
In another of those mad-scientist streaks, I added enough libc headers
so that glib-1.2 compiles without error. The libc headers are in CVS
for my Q3 mod; glib itself isn't. I haven't tested glib, yet. The
funny thing, I forgot why I wanted glib in the first place.
2002.11.13 ~11 QVMlibc
In the CVS repository for my q3 mod, I added a subset of libc and SUS
(POSIX). Covers ctype, strings, stdio, stdlib, errno, assert, unistd,
fcntl, dirent, time.
With some of the off-the-wall stuff I try, I'm thinking of renaming my
mod to something like: "Nonlinear Experimental R&D-Type Stuff Modding".
2002.11.09 ~13 Compiled vs Interpreted
I actually started on a long-winded entry on my thoughts about criteria
for "compiled" or "interpreted" for a language, when a google trip
turned up this link that is pretty much a superset of my ideas:
http://www.oche.de/~akupries/ics_lang.htmlI had pondered over compiled vs interpreted as I mulled over the Q3VM
specs and the way it makes a distinction between code space and memory
space (JUMP to address 0 is vmMain(); a LOAD from address 0 does not
return the bit-level representation of vmMain()). I decided the
dividing line comes down to observing how the Program Counter (or
Instruction Pointer, et al.) acts, whether it branches into newly
created code (compiled) or stays within already pre-existing code
(interpreted). Since a VM has its own (emulated/simulated) PC, this
would mean bytecode would technically be compilation (from the point of
view of the VM), but still interpreted by the host machine (as the host
machine does not branch directly to the byte sequence).
I had considered bytecode to be a middle ground between compiled and
interpreted, but then I wondered if there may be other categories as
well -- echoes of the zero-one-infinity principle. As the mentioned url
illustrates, the whole gig is a matter of how many layers you need to
tear through; "compiled" and "interpreted" are relative terms. Java is
"more compiled" than Bash, Perl is "more interpreted" than C, and so on.
2002.11.08 ~10 Pb rant addendum
Right about now, I feel I'd rather play on a server full of aimbotters
than fucking with Pb. At least when I take out a cheater, I can
righteously gloat haughtily for the rest of the game. With Pb on, you
can't really be sure if a cheater slipped through or not...
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