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.