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.