Duke3D: We've got Bargle's joystick code in CVS. Haven't tried it myself (no sticks here), but it should be good to go. 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) Make sure BUILD editor runs (it does, just needs sanity checks). 6) Race condition in audiolib causes occasional crash. UTPG: 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. Devastation: 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: Going to get a patch out sooner than later. Nothing specific to report at this time. Postal 2: Please stop emailing me to ask if this is done yet. Apparently I should have Karma sources soon, so I can get this game done and out the door. MOHAA: http://icculus.org/news/news.php?id=1607 America's Army: Linux 1.9 is live: http://icculus.org/news/news.php?id=1616 Mac 1.9 is done, will be going out to the mirrors soon (but not today). Other stuff: One of the finest things about the G5 is that it (finally) has a hardware-based square root instruction. On an earlier PowerPC, you either have to use a software-based algorithm (which is EXPENSIVE...UTPG was spending about 8% of it's CPU time in libSystem's sqrt() during the intro movie flyby) or use the "frsqrte" instruction (that's "floating-point reciprocal square root estimate", or 'give me a fraction that is roughly 1.0 over square root of X'). frsqrte is fast, very fast, but it gives you a whopping five bits of precision...which means, in many cases, you can guess the result in your head more accurately. But boy, it's fast. Then again, being a reciprocal, you have to divide it by 1.0 to get the rough answer you were looking for in the first place...floating point division isn't pipelined on the PowerPC, and you get a big fat processor stall for doing it. It's still way faster than doing this with libSystem's libc, though. The G5 apparently has an "fsqrt" instruction that does what you'd expect at full precision. Using it will cause your program to crash (Illegal instruction exception, SIGILL) on a G4 or earlier, and you have to force the compiler to use them. In gcc 3.3 (the XCode/Panther version) you need to specify -O3 (maybe a lower optimization will work, too, -O0 won't), -mpowerpc-gpopt (to enable the use of the opcode), and -force_cpusubtype_ALL (to tell -mpowerpcc-gpopt you really mean it...yes, those are underscores, not dashes). I don't think Apple's gcc 3.1 will generate the fsqrt opcode, and doesn't have these extra command lines anyhow. I assume that libSystem's sqrt() uses (or will use) fsqrt on a G5 behind the scenes, but there's function call overhead and other steps the ANSI spec makes it go through (setting errno, etc). -ffast-math and -fno-math-errno might help in those cases...I've seen Apple's gcc optimize unnecessary sqrt() calls out altogether when -ffast-math is used, YMMV. --ryan.