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 ...and the Mac version: http://icculus.org/news/news.php?id=1622 Other stuff: Jeffrey Lim pointed out that in my previous reciprocal square root example, you can avoid the guaranteed pipeline stall that division introduces by changing the "y = 1.0/__frsqrte(x)" to "y = x * __frsqrte(x)". Goes to show how strong my math skills are. :) So I took a 20 minute look at IBM's G5 compiler. Here are my initial thoughts, with more to come: - I've only built "Hello, World", some basic BSD sockets code and a few other things. I didn't try to build something as big as Unreal. Everything worked and ran on my G4 laptop. Contrary to what you may read, you don't need a G5 to use this, but it may be that I didn't compile anything that really worked the code generator. There are xlc (that's the compiler's name) equivalents of gcc's -mcpu and -mtune, so you might need to enable G5 code generation. I didn't build with optimizations at all. - xlc doesn't understand #pragma pack(push,x), but it does know what #pragma pack(pop) is. More to my amazement, it understood and correctly used GCC's __attribute__((aligned,packed(x))) syntax. - It understands Apple's Altivec keywords ("vector float x", "vec_splat_u32" and such), if you enable them with -qaltivec on the command line. GCC uses -faltivec. - There are a LOT of well documented knobs and dials you can tweak on the compiler...an overwhelming amount, to be honest. I like that in precisely the same way that I hate it. It does appear that all the specific optimizations you can hand-pick in gcc are here and many more. - Ogg Vorbis, zlib, and Speex all compiled without a single warning. I haven't tried to use the compiled binaries, though. I built them directly with my own Makefiles and without using the autoconf scripts. - alloca is a function call by default (which doesn't link on OSX, but maybe I didn't look closely enough). You can make alloca inline (which, honestly, I always assumed it was by default universally), with the -ma option. - fsigned-chars is -qchars=signed - If you're counting on __GNUC__ being defined to signify a Unix build, time to fix your code. I have no idea what xlc actually does define at this moment, but I'm sure it defines something. - Inline asm: I hope there's something better than this suggests: http://www-1.ibm.com/servers/esdd/articles/power4_mem.html (Look for "#pragma mc_func" and "#pragma reg_killed_by"). I know that developers using GCC have no right to bitch about other compilers when it comes to inline asm syntax, but...yikes. - There's line number debug information, so you can trace through an xlc- compiled program in GDB, but there's no data debug info, so you can't examine any variables. Even intrinsics like "int c;" will not be viewable in gdb. This is documented, and I assume will change. Still, it's a pain in the short term, especially since moving to a new compiler exposes bugs where you really need to utilize a debugger to find. Well, printf() works. :) I'll have to look into it more closely. --ryan.