Duke3D: I'm putting together a MacOS X installer for Duke3D that can be used with the retail disc to get everything setup. I need artwork that I can legally distribute, though (that is, not something swiped off 3drealms.com or a screenshot, etc...something Duke-like that you created from scratch). If you can make me an OSX icon for the game, a separate one for the installer, and a "splash" graphic (393x83 pixels worked well with the ut2003 installer), please drop me a line. The only things missing from the Mac port at this point is music, which is complicated, x86 compatibility for savegames, which is not worth the effort, and keeping PC-to-Mac netgames in sync, which is a pain. Overall, it's worth calling it done at this point, since the widespread appeal of Duke at this point is the single player campaign, imho. If you really want to play against others, make sure you're all on Macs. Playing against Windows and Linux players seems to work, but goes out of sync for some reason, which is frustrating, since we appear to handle all the byte swapping (yeah, apparently not...). UTPG: Please stop emailing me to ask if this is done yet. Spent some time getting the OpenAL renderer to make some noise on the OSX port. The original UT's AL renderer was written when the spec wasn't finalized (it doesn't create a device to pass to the AL context, etc), and relies on a few Loki extensions that don't appear to exist in the current cvs at this point, too. Fun. Progress is being made. I'd rather not try to coerce the Westlake audio code into running, since we can probably score a better framerate from a CoreAudio-based AL implementation, and it's one more chunk of code I'd have to maintain, and God knows I'm maintaining way too many chunks already. If anyone has a legal copy (i.e. - you own the original discs that came out of a non-Academic version) of Codewarrior 7 they can donate to me, it would help make sure that the OS9 version of UT continues to work online when UTPG breaks network compatibility. One of you has a copy collecting dust in the closet since you've probably upgraded _TWICE_ since that version, and I could really use it, here. Please drop me a line if you can help. I'm seriously not cherishing the idea of backporting the thing to CodeWarrior 6, since that's all I've got here. Ask your IT department if there's a copy in storage they can let go of. Someone's got to have a copy they don't need at this point. 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: 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.