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.08.11 ~04 Intermedial charged weaponry
Finally came up with a hack to get charged weaponry to work. It isn't as clean
as I would like, but it works for now. Large pieces of the source tree
suffered manglings as I worked towards charged weaponry. Some data structures
had to be rearranged, and I don't see as much potential flexibility as I would
like to see. In any case, charged railgun works. I should get around to
packaging this up now into another release.
2002.07.17 ~05 Charged railgun
Q2WF sniper rifle was a charge weapon, in that the weapon "charges up"
while the fire button is held, then releases its load upon release. The
damage delivered is proportional to the time spent "charging up".
I'm trying to find a clean way to integrate a means to allow such a charge
time to influence the effects of a weapon and its projectiles. Thus far,
there doesn't seem to be any particularly clean way. Large parts of the
infrastructure may need to be replaced to accomodate charging in a clean
manner.
The current problem is that, for both ballistic and hitscan projectiles,
the projectile has, within a single function, two distinct stages, an
initialization of properties, then an actual instantiation of the
projectile based on those properites. I initially attempted to squeeze a
"modify properties here" bit of code between the two stages, but I can't
see a way of accessing the appropriate re-modding code cleanly.
Ideas are currently to use a global (tres ugly), modifying all relevant
firing code to take a callback parameter (some overhaul), split the
initialization and instantiation into two distinct functions that have a
guaranteed sequence such that remodding code can just "pop up" normally in
between (lots of work, especially ensuring sequence). Ponderances.
2002.07.09 ~06 NaN Blender blue sky
http://www.blender3d.com/On July 5th, Ton Roosendaal (head dude of some kind of Blender... or of
NaN... or something) announced having reached an agreement with NaN
shareholders to open up the sources to Blender. The majority stakeholder
apparently is a VC firm called NetVenture. From what little tidbits and
snippets I gathered since NaN tanked back in March, this VC firms seems the
type to be bass-ackwards enough to "not get" the GPL. I *seriously* doubt
Blender will be licensed under GPL.
Well, that's the first of the blue sky: Blender under GPL.
- File format
Apparently the native file format used by Blender is a real mess. Hearsay
has it that the file is "a glorified memory dump". Regardless, I'd like to
steer away from binary format.
Other folks pitching plans for Blender's future are rooting for XML.
Personally, I'd rather use S-Expressions. S-expression is simpler than
XML, it's less verbose, it already has a "natural form" for lists and
aggregates, and it looks prettier than XML. Oh, and it's a small step to
throwing in a full Lisp system :)
I should probably draw up a proof-of-concept s-expr export in the current
incarnations of Blender.
- Python & Armatures
Armature bones are currently inaccessible via Python (Blender's extensible
language). This means automated/procedural animation of armatures is
impossible, and must be all hand-animated. I feel this needs to be
resolved first.
- Blender210 module, model import
There's a minor bug in Blender210.Mesh.addFace() which bit me during my
development of a Blender MD3 import script.
The method has six arguments: four vertices (index number into list of
vertices defined earlier with addVertex()), boolean for smooth shading, and
index number into the list of materials.
Whether a quad or a tri is created is determined by the fourth argument.
If it's 0, the method forms a triangle, otherwise a quad. The problem is
that I often needed to make quads where the fourth argument is vertex 0.
This leads to an erroneous creation of a triangle when I really wanted a
quad. Although I could reverse the order of vertices, that would change
the face normal to an incorrect value. The workaround in my import script
creates a meaningless "throwaway" vertex 0 before the actual vertices, sets
up the polys, then deletes vertex 0 afterwards.
This bug needs to be worked out. I came up with three potential solutions:
* Use "-1" to mean no vertex. This is ugly.
* Use separate methods for quads and tris. This gets messy.
* Based quad-vs-tri on number of arguments. 5 for tri, 6 for quad. This
is potentially confusing.
- Completing the menus
The popup (SPC) menu could really use having all possible Blender actions
thrown into it, possibly also allowing reconfiguring of hotkeys GIMP-style.
- Intersect sucks
The closest thing that Blender has to a boolean operation is its
"Intersect". The results are often ugly and splintered, especially when
both objects are complex. I have no idea if I'm up to snuff to improve
this, but it's a wishlist item nonetheless.
- Ogg Vorbis
I throw Ogg Vorbis at everything.
- Blender Game Engine
Neat-o feature, but sort of distracts from Blender's modelling/animation
roots. On top of that, activating UV-texturing starts doing weird things
to shaded mode. This isn't reversible until Blender is restarted. Even
without this annoyance, I'd prefer the game stuff to be clearly separated
from Blender, either plugin-ish or moved into a separate project. The
current Blender python modules already split the gaming stuff from the
modelling stuff, anyway.
2002.07.04 ~09 Q3VM bit vectors
A few days ago I implemented a form of generic (compressed) bit vector.
It uses an array of int, and packs 31 bits per int (for reasons of
overflow and sign). Bits are accessed by bitshift, in sizes from 1
to 31 bits (values passed around via int).
The initial purpose for the bit vector was for my mod implementation of
multiple-pierce hitscan (viz. railgun). The original (unmodded) railgun
uses a three-element array of ints, to hold the entity number for each
object pierced (up to three). My rationale was that such limit is
arbitrary, and decided to expand it as much as possible. The most obvious
extension is to expand this array to 1024 elements of int (maximum number
of entities possible). That leads to 4*1024 = 4KB memory use, and most of
it unused since there aren't many weapons that will be infinitely piercing.
Just to keep track of a yes/no state.
This led to wishing for an array of bits. Thus the implementation. At 31
bits to the word, and 1024 bits, this resulted in 34 bytes to record
entities pierced. Major win.
A general bit vector of arbitrary length can also lay the foundation for
bignums, integers of arbitrary size.
2002.06.27 ~10 bg_lib.c vsnprintf()
http://www.linux.ucla.edu/~phaethon/q3a/vsnprintf/vsnprintf.htmlProbably one of the more subtle omissions in the Q3A game/mod source is
snprintf() (and vsnprintf()). This had been on my mind for many months,
since I always wondered about buffer-overrun situtations, but I never paid
it much heed, relying on "big enough" buffers and va() (with 32KB buffer)
to avoid buffer overruns. The lack of snprintf() in Q3VM surfaced again
while chatting away on IRC. This time around, I actually felt competent
enough to pull off an implementation of vsnprintf(), and did it for the
heck of it. Well, actually, I had nothing else to do at the time, but
having sprintf() is very handy, especially in Q3VM's limited memory.
Basically vsprintf() and three of its support routines were modified to
take an extra parameter (the `size' parameter) and add a couple more state
variables. A macro was thrown in for simplification, but it makes the code
look a little uglier. That was about it.
2002.06.23 ~08 FI CVS branch merging
Yay. My first shot at CVS branch merging. Branch "qs-tinyscheme" merged
into trunk. Now the version QuakeScheme built on top of TinySCHEME is in
the trunk. This should have actually happened a couple months ago, but I
forgot about it when the web CVS access stopped working for FI and I didn't
get to browse the CVS repository (and its ensuing branches) GUIly.
2002.06.23 ~07 FI decoys and count limits
A lot of credit goes to Inferna| on
irc://irc.enterthegame.com/#br for
giving me a push in the right direction.
Limiting the number of simultaneous instances of a projectile per player is
now implemented using an array of reference counts. The actual limit value
is stored with the projectiles definition in the weapons config file. This
limits some of the insane configurations I've been dreaming up, but for the
most part such restrictions are sensible for what amounts to a WF clone.
The decoy has been solidified. Now I can stand on my own decoy and shoot
it with just about whatever. Gauntlet is acting buggy, though. Currently
the number of deployed decoys isn't limited. In most MOCK cases, having
more than one decoy doesn't make a whole lot of sense. Still, I'd like to
mull over whether the coding design for decoys is "good" 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. 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