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: This is floating through QA right now as a final candidate, so it's Darned Near Done. MojoPatch: Now open source! http://icculus.org/news/news.php?id=2040 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). 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=2064 Call 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.bz2 Postal 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=2046 Other stuff: So here's your programming test. You have a program that reads a bunch of data from disk...several hundred megabytes. Most of this data is comprised of callstacks...variable-length lists of pointers that represent a program's program flow. Ever hit a breakpoint in gdb and hit "bt"? That backtrace. That's what I'm talking about. Let's say you are writing a profiler that is examining a run of a program. Let's say you're writing Apple's Shark tool or whatnot. You might have hundreds of thousands (or millions) of backtraces that represent a small snapshot of a program at any given time. So, how do you efficiently store this information as it comes flooding in? Here are your interfaces: "callstackid" can be anything that fits in the platform's wordsize...a pointer or an integer or whatnot, but it has to be an intrinsic datatype of some sort, not a structure. You can have structures behind the scenes. callstackid callstack_add(void **ptrs, size_t count); ...this will get called repeatedly as the callstacks are read from disk. (ptrs) is an array of void-pointers, which represent the callstack. (count) are the number of elements pointed to by (ptrs), which is not null-terminated. This is called once per callstack. We'll be nice and let you have: void callstack_doneadding(void); ...which is called when we're done reading from disk, in case you want notification that there won't be more calls to callstack_add(). Now we'll be calling... size_t callstack_framecount(callstackid id); ..where you return the number of pointers in that specific callstack. We'll use this to allocate enough space before calling: void callstack_get(callstackid id, void **ptrs); ...where you copy the pointers into the array we supply in (ptrs). In Real Life, this would pass the size of the array, but you can assume we allocated it based on what you fed us in callstack_framecount(), and that id is a valid value you fed us from callstack_add(). Etc. That's it. The goal is to implement this interface so that it is: 1) as fast as possible, even with a potentially huge data set, in all parts of this API (i.e. - if adding is fast, but getting is SLOW, then it's no good). 2) uses as little memory as possible. Remember that we might feed you gigabytes of data over time in callstacks_add(). We'll be nice and say you won't get more than your address space can hold, but even then, you can't use the whole thing (ever use 4 gigs of swap?). 3) as simple as possible (har!). You can use C or C++ at your discretion. Nothing else. If it's not in the standard C runtime, you can't use any external functions, either (yes, that means no STL or Boost, etc). There isn't a 100% Good answer; With large datasets, it's always a collection of tradeoffs and content assumptions. Welcome to the industry. Those that complete this assignment have the satisfaction of knowing that you probably came up with an acceptable answer faster than I did. :/ I'll post my attempt later on. --ryan.