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.