Finger info for icculus@icculus.org...


OpenAL:
 So I'm maintaining my own MacOSX OpenAL implementation now.
   http://icculus.org/al_osx/

 I pounded on my high-level mixing code to make it stop thrashing the CPU 
 cache, and now it takes 0.1% of the CPU instead of 0.3% in ut2003...while
 that doesn't sound like much of an improvement in those terms, it is
 three times faster, and when our total AL processing time is hovering 
 around 1.5% of the CPU, this is actually a huge optimization win...one of 
 the biggest ones I could find at this point.

 I also played around with vec_dst in the mixers, but it didn't seem to 
 give a notable speed boost like I hoped...maybe I'm misunderstanding how 
 to use it. It's also my understanding that the G5 notices sequential memory
 accesses and automatically starts pulling in cachelines in anticipation 
 that you'll be touching them shortly...effectively, this does the same 
 thing as vec_dst, but without your explicit intervention, and without 
 having to worry about the architectural differences in prefetching 
 between the G4 and G5. I think the bottom line is that this is a problem 
 that will fix itself over time. I haven't benchmarked my AL 
 implementation on a G5 yet; with the dual CPUs, the prefetching 
 mechanism and IBM's G5 compiler...maybe I'm already below the mythical 
 1.0% CPU time. I'd have to check. I've been doing my work and profiling 
 with ut2003 on a Powerbook G4 12" (the model MacSoft says the game 
 absolutely isn't playable on...in light of that, it seemed like a good 
 target to shoot for).

 I also put new upsampling code (yes, this is iteration number four for 
 those keeping track) into CVS...my idea about Bresenham's line algorithm 
 seems to have panned out very well...it's about identical in results to 
 the previous iteration, but easily five times faster. I'm going to go 
 reread Abrash's articles on optimizing Bresenham to see if I can push 
 that farther...there's an obvious win by moving the branch out of the 
 resampling loop and splitting it into two seperate loops, since a given 
 sample's "run length" alternates between two definite values, you don't 
 need to check if it's time to switch in the loop...just iterate for one 
 length, then iterate for the other, then start over until the whole 
 buffer is resampled. There are better sounding resampling algorithms, but 
 I think you'd be hard-pressed to find one that is faster with equally 
 acceptable quality (and if you can, send me a patch).

 I also like the idea of adding an alHint() entry point so an app can 
 specify "fast" vs "good" resampling. But that's not really important in 
 the scope of most games.


Duke3D:
 Stuff on the MacOS TODO list:
   1) x86 compatibility for savegames
   2) keeping Mac/PC networking in sync
   3) Coming up with a server browser/matching service.
   4) Add Cmd-Q as a quit key.
   5) Race condition in audiolib causes occasional crash.
   6) Ship it.


UTPG:
 Please stop emailing me to ask if this is done yet.

 We're doing some polishing to get ALAudio working on Windows and other
 details at the moment. Some long-standing bugs that have been delaying a
 release have been squashed recently, so progress is being made.


Unreal Tournament 2003:
 Okay, so we didn't beat Panther out the door. There were some pressing OpenAL
 fixes I really wanted to get in the first patch, and I wrote a patch program
 to make the whole thing easier on the end user, which took about a day longer
 that I wanted to reach a 0.0.1 version. You poor bastards are really just my
 test subjects, though...the ut2003 patch will be pretty tiny, since it's just
 a few files changing...but the patch program will be hugely helpful for
 ArmyOps, since the upcoming 2.0 patch is, um, slightly larger.

 At any rate, the patch isn't ready for primetime yet, but should be sometime
 next week (then again, we all know how well I keep deadlines). If there are
 any ATI users that installed Panther and need a fix, and don't mind running
 prerelease builds, please contact me and I'll hook you up in the interrim.


Call of Duty:
 Linux server will be ready in a few days. Infinity Ward is testing it in
 house right now...the goal is to have this in the admin's hands before the
 game hits shelves.

 Please don't email me about a Linux or Mac client port...I'm really way too
 busy to even consider it right now.


Postal 2:
 Please stop emailing me to ask if this is done yet.

 The karma source is in my hands now, but the legal paperwork is still 
 being done.  :(


MOHAA:
 Yes, I know the binary expired. A new binary will be along 
 shortly. Sorry about that.

 Talked with EA today about Breakthrough, hoping source will be coming my 
 way shortly, once all the NDA stuff is cleaned up.


America's Army:
 Linux 1.9 is live: http://icculus.org/news/news.php?id=1616
 ...and the Mac version: http://icculus.org/news/news.php?id=1622

 If you're running on Linux and having trouble with Punkbuster because it 
 wants to write to a directory you don't have permission to, please read 
 this:

    http://americasarmy.com/forum/viewtopic.php?topic=88357&forum=43

 You do NOT have to run the program as root. We'll automate this for the 
 next release, but this'll get you running in the short term.


Other stuff:

 Thank god: Apple's iBook line is now G4-based. Are there any current Apple
 products now that don't have a vector unit? The eMacs and iMacs are G4 tech,
 now, too...maybe we can stop worrying about whether a given user has
 Altivec or not within the 2006 timeframe. Who am I kidding? People will still
 be bitching at me about the performance of UT2031 on their Blueberry iMac
 which they "paid good money for".

--ryan.
    

When this .plan was written: 2003-10-27 00:23:12
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.24
Stick it in the camel and go.