UnrealEngine3:
Work officially begins. Time to get this building under gcc again. Since
we changed up the source tree layout, the Makefiles from UE2 are basically
useless. Rather than rewrite them, I'm going to spend some time exploring
SCons, which came highly recommended by TTimo, the Doom3/linux guy. First
Unreal steals their colored lighting, then their build system! :)
Obviously, there's a lot to be done at this point, but best to start now
so I'm not scrambling to port a whole engine when UE3 games get closer to
shipping. Updates as I have them.
Spider-Man 2:
Gone gold, baby.
MojoPatch:
The installers on MacSoft's Neverwinter Nights expansion pack discs are
actually a modified version of MojoPatch. Go order your copies!
Shrek 2:
Now shipping!
OpenAL:
For those that weren't at WWDC, Apple gave out preview discs of MacOS X Tiger.
One of the things Tiger installs by default? OpenAL.framework. No kidding.
That's basically awesome. It's Apple's version, which is open-sourced and
residing in Creative.com's CVS repository.
Likely I'll move my implementation over to Linux and stop further Mac
development, so that there is a clear technology path on the Mac. I'll
devote further Mac development and debugging to the Apple implementation.
After all, it was partially a stop-gap solution (remember when ut2003 took
25% of the CPU mixing audio? It was a needed fix, no doubt!), and partially
a technology proof-of-concept to show Apple what works well in terms of game
development. No doubt it has served me well.
In the short term, I'll have to decide what we ship on the disc with
Unreal-based games. For ut2004, my implementation is the only one with
ALC_EXT_capture support for VoIP...this could be added to the other
implementation, but hasn't been as of yet. My version is apparently a
little faster, but it's stereo only (but the subversion repository doesn't
crash on M-Audio 5.1 and 7.1 cards anymore), so Apple's tech is probably
more attractive for further development by default.
All of the missing functionality in Apple's implementation could be fixed
with some elbow grease, which I'm sure will show up one way or another in
the near future. Overall, this is a very good step forward, and I applaud
Apple for giving game developers something they really need.
Duke3D:
Latest CVS builds and runs on Solaris/x86 (and presumably Solaris/sparc, too).
I get a lot of questions about MacOS X: the game _does_ run on OSX, there
just isn't a nice installer or anything at the moment, so you have to
compile it yourself. When there's time, I'll put together a shareware-based
installer, and, if I can find a copy, one that works with the Mac retail disc.
UTPG:
(Yes, this is still being worked on.)
Unreal Tournament 2003:
There's an exploit in the ut2003 network code, so here's a new build.
Linux:
http://0day.icculus.org/ut2003/ut2003lnx_patch2225-3-BETA.tar.bz2 MacOSX:
http://0day.icculus.org/ut2003/ut2003-mac-patch-2225-3.dmg.bz2 The Linux one has about a million changes over the stock 2225, since it's got
all the MacOSX work on top of it. Consider it beta. The Mac version has one
or two fixes, so it's worth updating.
Unreal Tournament 2004:
If Mac retail installer crashes on you, use this:
http://icculus.org/~icculus/tmp/UT2004-mac-updated-installer.tar.bz2 Linux (x86 and amd64) official 3236 patch (new build with load times fixed):
http://icculus.org/news/news.php?id=2064 MacOS X (un?)official 3236 patch (YES, this is newer than 3229):
http://icculus.org/news/news.php?id=2064Call of Duty:
1.4 is out, now with PunkBuster support:
http://www.callofduty.com/patch/ This is a 1.4 server with an exploit closed. Admins should all upgrade:
http://icculus.org/betas/cod/COD-lnxded-1.4-07252004.tar.bz2Postal 2 Share the Pain:
Linux demo:
http://icculus.org/news/news.php?id=1816 Linux retail: In beta testing (apply at
http://www.linuxgamepublishing.com/)
Mac retail: In beta testing (no more applications, please!)
America's Army:
2.1.0 is out for Linux and Mac:
http://icculus.org/news/news.php?id=2046Other stuff:
So I sat down and cleaned up my callstack-processing programming challenge.
Overall, the code turned out to be sane, but there were some off-by-one
errors in what I posted here.
That being said, it turned out to be a huge win, much more than I
anticipated for my purpose...since my eventual goal was to track callstacks
where memory was allocated and freed, you not only find the usual frequency
of repeated callstacks, but that the differences are even fewer since many
programs only do memory management in a few choice places.
Case in point: a run of GCC to compile some C code...of all stack frames
(not just individual callstacks),
less than one percent of them were
unique...0.8%, specifically, so the storage tradeoff obviously paid off,
especially when you're looking at a data set of about 250,000 callstacks
from compiling a small C program.
--ryan.