Finger info for

 Stuff on the MacOS TODO list:
  1) x86 compatibility for savegames
  2) keeping Mac/PC networking in sync
  3) Coming up with a server browser/matching service.
  4) Add Cmd-Q as a quit key.
  5) Joystick support (Bargle's playing with SDLifying this on Windows,
  should work on the Mac, too)
  6) Make sure BUILD editor runs (it does, just needs sanity checks).
  7) Race condition in audiolib causes occasional crash.

 Please stop emailing me to ask if this is done yet.

 Metrowerks has decided to aid this effort and made arrangements for me to
 use CodeWarrior 7 (much thanks!)...I've got the discs sitting here, and an
 OS9 version of UT compiling just to see where it stands. Next step is merging
 in the appropriate UTPG changes.

 Rumor has it that AL_GAIN_LINEAR_LOKI is really what AL_GAIN is defined to
 be in the OpenAL spec, so the UTPG AL renderer might be right already. I
 love it when things Just Work.

 Please stop emailing me to ask if this is done yet.

 Server is out. Details here.
 Beta 1 of the Linux client is avaiable. Get it.

Unreal Tournament 2003:
 Just about all of Unreal's file i/o goes through a single point...a
 platform-specific implementation of an abstract base class called
 "FFileManager". If you aren't on Windows or a console, you're likely using
 the (now inappropriately named) FFileManagerLinux class.

 When the engine asks FFileManagerLinux to open a file, it maps filenames to
 the correct places (homedir if there, gamedir otherwise when reading, homedir
 always when writing) and creates directories as needed. Then it fopen()'s the
 file and feeds a queue buffer that gets the bits from the disc to the engine.

 So I sat down and did a little rewriting. First, the ANSI stream i/o had to
 go. fopen()s and fread()s became open()s and read()s, etc...generally, streams
 are implemented on top of the Unix handles anyhow, so that probably saves a
 few cycles (we still have an FFileManagerAnsi class if we need to bootstrap
 a POSIX-hostile platform). Then, I wrote an mmap()-based version of this...
 doing so removes all the buffering logic. Overall, this changed but didn't
 really bloat the init and cleanup code, but the actual i/o code became
 basically a memcpy() call, which is nice.

 On MacOSX, the bottom line seems to be that it shaves a few seconds off
 map load times. Nothing massive, but enough to make it worth it. I should
 do a real benchmark on this at some point. Linux will likely see similar

Postal 2:
 Please stop emailing me to ask if this is done yet.

 Skeletal meshes are rendering, most textures are STILL missing, and I get
 a crash in Karma as soon as someone if you don't kill anyone,
 the game won't crash. This is taking the "it's only as violent as you are"
 mantra to a whole new level.

 Busy begging and pleading for Karma sources so I can fix this. :(


America's Army:
 We're wrapping up the Linux and Mac betas and going through the motions
 to get this out to the world. Expect it early next week.

Other stuff:
 This space intentionally left blank. (no, really.)


When this .plan was written: 2003-08-16 23:58:15
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.