Duke3D:
We've got Bargle's joystick code in CVS. Haven't tried it myself (no sticks
here), but it should be good to go.
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) Make sure BUILD editor runs (it does, just needs sanity checks).
6) Race condition in audiolib causes occasional crash.
UTPG:
Please stop emailing me to ask if this is done yet.
Metrowerks has decided to aid this effort and made arrangements for me to
use CodeWarrior 7 (much thanks!)...I've got the discs sitting here, and an
OS9 version of UT compiling just to see where it stands. Next step is merging
in the appropriate UTPG changes.
Rumor has it that AL_GAIN_LINEAR_LOKI is really what AL_GAIN is defined to
be in the OpenAL spec, so the UTPG AL renderer might be right already. I
love it when things Just Work.
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.
Unreal Tournament 2003:
Going to get a patch out sooner than later. Nothing specific to report at
this time.
Postal 2:
Please stop emailing me to ask if this is done yet.
Apparently I should have Karma sources soon, so I can get this game done
and out the door.
MOHAA:
http://icculus.org/news/news.php?id=1607
America's Army:
Linux 1.9 is live: http://icculus.org/news/news.php?id=1616
Mac 1.9 is done, will be going out to the mirrors soon (but not today).
Other stuff:
One of the finest things about the G5 is that it (finally) has a
hardware-based square root instruction. On an earlier PowerPC, you either
have to use a software-based algorithm (which is EXPENSIVE...UTPG was
spending about 8% of it's CPU time in libSystem's sqrt() during the
intro movie flyby) or use the "frsqrte" instruction (that's "floating-point
reciprocal square root estimate", or 'give me a fraction that is
roughly 1.0 over square root of X'). frsqrte is fast, very fast, but it gives
you a whopping five bits of precision...which means, in many cases, you can
guess the result in your head more accurately. But boy, it's fast. Then
again, being a reciprocal, you have to divide it by 1.0 to get the rough
answer you were looking for in the first place...floating point division
isn't pipelined on the PowerPC, and you get a big fat processor stall for
doing it. It's still way faster than doing this with libSystem's libc,
though.
The G5 apparently has an "fsqrt" instruction that does what you'd expect at
full precision. Using it will cause your program to crash (Illegal
instruction exception, SIGILL) on a G4 or earlier, and you have to force the
compiler to use them. In gcc 3.3 (the XCode/Panther version) you need to
specify -O3 (maybe a lower optimization will work, too, -O0 won't),
-mpowerpc-gpopt (to enable the use of the opcode), and -force_cpusubtype_ALL
(to tell -mpowerpcc-gpopt you really mean it...yes, those are underscores,
not dashes). I don't think Apple's gcc 3.1 will generate the fsqrt opcode,
and doesn't have these extra command lines anyhow.
I assume that libSystem's sqrt() uses (or will use) fsqrt on a G5 behind the
scenes, but there's function call overhead and other steps the ANSI spec
makes it go through (setting errno, etc). -ffast-math and -fno-math-errno
might help in those cases...I've seen Apple's gcc optimize unnecessary sqrt()
calls out altogether when -ffast-math is used, YMMV.
--ryan.