Finger info for icculus@icculus.org...


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.
    

When this .plan was written: 2003-07-29 04:10:06
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.24
Stick it in the camel and go.