Finger info for icculus@icculus.org...


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.
    

When this .plan was written: 2003-08-22 18:13:27
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.24
Stick it in the camel and go.