Duke3D: Please stop emailing me to ask if this is done yet. Just got the floors and ceilings to render correctly on MacOS X, thanks to Dan Olson and Steven Fuller, the Ninja Hack Squad. Still needs some polishing, but this is really close to done, now. UTPG: Please stop emailing me to ask if this is done yet. A UTPG that breaks network compatibility is inevitable, which means I need to find a copy of CodeWarrior 7 for the OS9 port soon, or Mac users are going to be left in the cold. I really hate the idea of paying for a compiler that is two major revisions out of date. :( 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. Serious Sam: Please stop emailing me to ask if this is done yet. The First Encounter: Beta three is out. The Second Encounter is now available, too! Details are here. Time to work on ssam is non-existant, and there will probably not be another build for Linux for the foreseeable future, if ever. Unreal Tournament 2003: Mac version is in stores now! Go order from somewhere. I assume there are physical stores that sell Mac games that will/do have it, too. MacOS X French Release Candidate 2 is awaiting MacSoft approval. IF THE ENGLISH MAC UT2003 INSTALLER CRASHES AFTER YOU ENTER YOUR CD KEY: Then please download this (2.1 megabytes): http://icculus.org/updates/ut2003/ut2003-mac-setup-fixed.cdr.dmg.bz2 You should end up with a disk image with an installer icon. Run it, and install as usual. When the installation is done, throw away the disk image and pretend nothing ever went wrong. This is an installer bug; the game itself runs as usual. 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 ragdolls...so 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. :( MOHAA: Please stop emailing me to ask if this is done yet. If there is time this week, I'm going to try and finish this. I'm sick of answering emails from people that want to know if it's done. If you preordered this from TuxGames, I'm sorry, the delays are 100% my fault, and I told Michael Simms that this would be ready WAY sooner than it was. America's Army: Please stop emailing me to ask if this is done yet. Cheers to Damian for finding me a Revolution 7.1 card. The OpenAL crashbug that M-Audio users are seeing is due to a buffer overflow in the new CoreAudio-based code we dropped into ArmyOps. We query the hardware for available formats, but only allocate room for one format (this is apparently all the built-in sound chip in your Mac supports). The Revolution 7.1 returns 14 different formats, so we scribble over a lot of RAM, and the game pukes. This was just an incorrect assumption on our part, or a misreading of the docs. A deeper problem is exposed, though. The current OpenAL implementation only deals with stereo output. The Revolution, as far as I can tell, doesn't expose a two-channel output stream...all the formats want 8 channels. Ugh. There are a LOT of 2-channel assumptions in this implementation (and the drill instructor sounds like a chipmonk once you get past the crashbug, since writing 2 channels to an 8-channel buffer speeds him up by 4x). I also don't like that this AL implementation resamples and converts buffers on the fly during mixing. I'd rather we do all that crap when we first dereference the audio data during the alBufferData() call. If we do that, then the significant bottleneck of the mixer callback would become basically one big Altivec blit to the output buffer, which is sexy enough to me to justify a redesign of code I've never seen before. The current implementation does a really rough resampling, too... intentionally. Accurate resampling is expensive, especially in the window you've got to feed the audio device. We could do something that sounds cleaner given the expectation that alBufferData() can do things a little more slowly. There are a few sounds in ArmyOps (the harmonica in Leavenworth, etc), that are recorded at 5000 samples-per-second...which is strange, and it really NEEDS a better resampler to not sound crappy when the audio hardware is expecting something that's not a power of two (44100 samples per second, in many cases). So it's four in the morning, and my brain is fried from trying to grok this: http://www-ccrma.stanford.edu/~jos/resample/resample.html Sometimes I really wish I had passed Basic Math. For the Revolution users, the short of it is "we're working on it". For the rest of you, the short of it is "we're working on making it faster". For now you should disable the card and use the built-in audio. This requires a few clicks in System Preferences, and does NOT require you to remove the sound card or open your Mac up, as insidemacgames reported. Other stuff: So I was at Apple's campus for an appointment last week. That place is the fucking MOTHERSHIP, i swear. It's everything you'd expect it to be, too... even the toilets are stylish. In light of all the CoreAudio studying I've been doing with OpenAL, I sat down to write a CoreAudio SDL target on the flight home. I think it'll be a good speed boost over the SoundManager-based audio target MacSDL currently uses. Removing the argument that "SDL is slow on the Mac" is important to me, and this is a rather low-hanging fruit when it comes down to it. That being said, it isn't complete at this point. Are you shocked? Don't email me to ask if it's done yet. :) --ryan.