OpenAL: So I'm maintaining my own MacOSX OpenAL implementation now. http://icculus.org/al_osx/ I pounded on my high-level mixing code to make it stop thrashing the CPU cache, and now it takes 0.1% of the CPU instead of 0.3% in ut2003...while that doesn't sound like much of an improvement in those terms, it is three times faster, and when our total AL processing time is hovering around 1.5% of the CPU, this is actually a huge optimization win...one of the biggest ones I could find at this point. I also played around with vec_dst in the mixers, but it didn't seem to give a notable speed boost like I hoped...maybe I'm misunderstanding how to use it. It's also my understanding that the G5 notices sequential memory accesses and automatically starts pulling in cachelines in anticipation that you'll be touching them shortly...effectively, this does the same thing as vec_dst, but without your explicit intervention, and without having to worry about the architectural differences in prefetching between the G4 and G5. I think the bottom line is that this is a problem that will fix itself over time. I haven't benchmarked my AL implementation on a G5 yet; with the dual CPUs, the prefetching mechanism and IBM's G5 compiler...maybe I'm already below the mythical 1.0% CPU time. I'd have to check. I've been doing my work and profiling with ut2003 on a Powerbook G4 12" (the model MacSoft says the game absolutely isn't playable on...in light of that, it seemed like a good target to shoot for). I also put new upsampling code (yes, this is iteration number four for those keeping track) into CVS...my idea about Bresenham's line algorithm seems to have panned out very well...it's about identical in results to the previous iteration, but easily five times faster. I'm going to go reread Abrash's articles on optimizing Bresenham to see if I can push that farther...there's an obvious win by moving the branch out of the resampling loop and splitting it into two seperate loops, since a given sample's "run length" alternates between two definite values, you don't need to check if it's time to switch in the loop...just iterate for one length, then iterate for the other, then start over until the whole buffer is resampled. There are better sounding resampling algorithms, but I think you'd be hard-pressed to find one that is faster with equally acceptable quality (and if you can, send me a patch). I also like the idea of adding an alHint() entry point so an app can specify "fast" vs "good" resampling. But that's not really important in the scope of most games. Duke3D: 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) Race condition in audiolib causes occasional crash. 6) Ship it. UTPG: Please stop emailing me to ask if this is done yet. We're doing some polishing to get ALAudio working on Windows and other details at the moment. Some long-standing bugs that have been delaying a release have been squashed recently, so progress is being made. Unreal Tournament 2003: Okay, so we didn't beat Panther out the door. There were some pressing OpenAL fixes I really wanted to get in the first patch, and I wrote a patch program to make the whole thing easier on the end user, which took about a day longer that I wanted to reach a 0.0.1 version. You poor bastards are really just my test subjects, though...the ut2003 patch will be pretty tiny, since it's just a few files changing...but the patch program will be hugely helpful for ArmyOps, since the upcoming 2.0 patch is, um, slightly larger. At any rate, the patch isn't ready for primetime yet, but should be sometime next week (then again, we all know how well I keep deadlines). If there are any ATI users that installed Panther and need a fix, and don't mind running prerelease builds, please contact me and I'll hook you up in the interrim. Call of Duty: Linux server will be ready in a few days. Infinity Ward is testing it in house right now...the goal is to have this in the admin's hands before the game hits shelves. Please don't email me about a Linux or Mac client port...I'm really way too busy to even consider it right now. Postal 2: Please stop emailing me to ask if this is done yet. The karma source is in my hands now, but the legal paperwork is still being done. :( MOHAA: Yes, I know the binary expired. A new binary will be along shortly. Sorry about that. Talked with EA today about Breakthrough, hoping source will be coming my way shortly, once all the NDA stuff is cleaned up. 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 If you're running on Linux and having trouble with Punkbuster because it wants to write to a directory you don't have permission to, please read this: http://americasarmy.com/forum/viewtopic.php?topic=88357&forum=43 You do NOT have to run the program as root. We'll automate this for the next release, but this'll get you running in the short term. Other stuff: Thank god: Apple's iBook line is now G4-based. Are there any current Apple products now that don't have a vector unit? The eMacs and iMacs are G4 tech, now, too...maybe we can stop worrying about whether a given user has Altivec or not within the 2006 timeframe. Who am I kidding? People will still be bitching at me about the performance of UT2031 on their Blueberry iMac which they "paid good money for". --ryan.