Finger info for phaethon@icculus.org...



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.10.27 ~06 improved RNG in Q3VM, Q3 1.32

+ Towards a better (Pseudo-)Random Number Generator.

http://www.icculus.org/~phaethon/q3a/nbrng/nbrng.html

My quest for a better RNG started in Quake 3 Urban Terror (q3ut) v2.5,
fueled by countless numbers of "Bullshit Incidents", aka "being 2.5'd".
I'm not in a position to improve q3ut myself (read: damn elitist "dev
group"), but the repeated 2.5'ing fired up my drive.

The stock random number generator in Q3A is a laughably deterministic
cyclic PRNG. Just multiplying the seed by 69069, storing the result back
into the seed, and then using the new seed value as the random number.
(Note: mods compiled to native code use the host OS's (P)RNG)

A google search for free RNG source turned up "noiz". The original noiz
acts like an ad-hoc system-wide RNG, using an entropy pool file in /etc (or
elsewhere) and explicit programs to take the pool, stirs the pool with
stdin, and writes back the altered pool; basically a shellified+disked
variant of an entropy collector.

My terminology is probably rather shoddily used and incorrectly applied,
since I just started to look into RNG. I never realized the breadth of
research on just figuring out how to *induce* randomness.

Anyway, I took noiz and modified it to be function+cvar based. The
function to actually collect entropy needs to be strategically placed
throughout the mod to correctly scoop up entropy, but otherwise the
noiz-based RNG is far more nondeterministic than the stock PRNG.

+ Quake 3 Software Development Kit v1.32.

ftp://ftp.idsoftware.com/idstuff/quake3/source/linuxq3a-sdk-1.32.x86.run

So, the new SDK to reflect the new Q3A mod (baseq3) source was released a
few days ago. Apparently most of the baseq3 changes involve
PunkBuster-related options, such as UI elements to turn it on/off. At
last id released their patched lcc, which compiles C to Q3VM assembly
(which is actually a variant on the lcc bytecode machine description).

As far as I can tell, the 1.32 q3asm doesn't have any speedups over the
prior (1.27?) version, although someone took the time to clean up the code
to keep gcc quiet.

+ PunkBuster

So now Q3 1.32 has PunkBuster. I have no idea what the basic principles
are behind it, but apparently it's supposed to reduce cheating somehow.
Since it (PB) deposits .so files on my (client) side, I presume these
checks are done client-side. One lesson I recall from the Q1 source
release is that anything run on client-side is totally untrustable, as
there is really no limit to what the client-side can "say". So I seriously
doubt PB can catch "all" or even "most" cheats, if it relies on this
client-side .so file to check for client-side... um... stuff.

Aside from that, I'm starting to notice strange lags in Q3. Now everything
feels like a 100+ ms lag, instead of the usual inherent 50ms lag. It
almost feels like CPU/client-side lag, but the framerate still pegs the
meter at high double digits. Everything, from baseq3 to ufreeze to q3ut2
to wfa, from extremely low ping to extremely high ping. Either the netcode
in Q3 1.32 has hit the shitter, or PunkBuster is stuffing Q3's face into
the shitter with extra net comm.

Neither one bodes well. Still, it would be extremely stupid if PunkBuster
maintains some kind of "out-of-bounds" channel _during_ gameplay, since
even so much as a rogue SYN packet can exponentially compound the lag on a
56K connection (a large segment of Q3 players, iirc) and completely ruin
the experience (of either side of 0wn@ge). But I find it harder to believe
Id would deliberately cripple the netcode in 1.32 sufficiently to make the
difference noticeable on a broadband connection. Which is it? Which way
would Occam's Razor cut?


2002.10.19 ~05 Blender web plugin problems

The last compilation stretch is the Blender GamePlayer web plugin. The
problem is that the plugin was initially developed using the API in Mozilla
1.0 (or earlier?). Debian unstable has the bins and dev files for moz 1.1.
Problems at compile time. My options at this point are hacking on the
plugin to use the 1.1 API (XPCOM in particular), fall back to moz 1.0 (via
cvs), or abandon the compiling plugin altogether and concentrating on the
preliminary ODE patch (physics engine) for Blender trunk.

Oh, fwiw, the original collision-detection library in Blender, SOLID, had
to be removed from the Open version due to licensing constraints. Yay
proprietary license.


2002.10.18 ~01 Blender Open-Source

Blender Liberated

The Blender source code is distributed under a dual GPL/not-so-GPL license.
Reminds me a bit of Mozilla. Freed 13 October 2002.

Blender Autoconfiscating
http://www.linux.ucla.edu/~phaethon/blender/blender-autoconf.html

The initial build environment was heavily broken/undocumented. It didn't
"out-of-the-box", so on Sunday night (localtime) I started rearranging
directories and files, and autoconfiscating the tree. Started late 13
October 2002. Hacking at it since. First I got a modelling-only Blender.
Then GameBlender eventually fell into the autostream. Now it's mostly
cleanup and tweaks. Hoping for a pub CVS repository on www.blender.org.

Blender Publisher semi-freeware

The v2.25 that was previously off-limits to non-bondaged users was released
in limited "freeware" style, um... yesterday, I think. RE'ing and
decompilation are still forbidden, but at least the "common rabble" can take
a stab at 2.25 without trying to figure out the compile path.


2002.10.03 ~06 Ogg Vorbis 1.0 in Q3, cgame outline

So I took the plunge and snarfed Ogg Vorbis v1.0 (no shmamsy-pamsy rc
suffix), then untarred it to my working directory, then made the necessary
make-q3asm-happy patches. Vorbis decoding promptly b0rk3d. Oh well. I'll
keep it that way for the time being; no plans for serious cgame modding any
time soon.

In other non-news, http://www.icculus.org/~phaethon/q3mc/outline2.html

The cgame portion of an execution trace in outline form.


2002.10.03 ~03 Compiling Scheme to Q3VM bytecode

Right now, compiling Scheme directly to a Q3VM file is possible. The
opcodes for Q3VM are all laid out, the peculiarities of Q3VM are in the
q3lcc patch, the memory structure is not complex. A suitable halfway hack
is to compile for a SECD machine, then translate the SECD operations into
Q3VM opcodes. The SECD layer could be done away with entirely, but that's
an entire research project in of itself ("Optimized Scheme Compiler for
Quake 3 Virtual Machine").

Programs for compiling Scheme into SECD byteocde are already available, and
written in... Scheme. Well, C compilers are written in C, so that's not so
entirely weird :)

I'm wondering if it may be more worthwhile to try to hack one of the
existing Common Lisp compilers to target Q3VM, instead of trying to
compile Scheme via SECD.


2002.09.27 ~07 Another universe SIGSEGV

00:43 < Chunky_Ks> vogon: turn the computer off and leave the house
00:43 < Chunky_Ks> talk to a girl
00:43 < Chunky_Ks> I'm going to bed
00:43 -!- Chunky_Ks [chunky@gamehenge.icculus.org] has quit ["Leaving"]
00:43 < vogon> chu: I try, but the Universe always segfaults.

Maybe it really did raise signal 11. That timing is too eerie.


2002.09.24 ~08 Welcome to the City of Angels :)

(timestamps PDT)
00:56 <Chunky_Ks> and this is the most socially backward an uncivilsed place I've ever been
00:56 <phaethon> huh? California?
00:58 <Chunky_Ks> LA, specifically
00:58 <phaethon> yep. That's us.
00:58 <phaethon> :)


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


When this .plan was written: 2002-10-27 01:51:49
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.