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
 ...and the Mac version: http://icculus.org/news/news.php?id=1622


Other stuff:
 Jeffrey Lim pointed out that in my previous reciprocal square root example,
 you can avoid the guaranteed pipeline stall that division introduces by
 changing the "y = 1.0/__frsqrte(x)" to "y = x * __frsqrte(x)". Goes to show
 how strong my math skills are. :)

 So I took a 20 minute look at IBM's G5 compiler. Here are my initial
 thoughts, with more to come:

  - I've only built "Hello, World", some basic BSD sockets code and a few
  other things. I didn't try to build something as big as Unreal. Everything
  worked and ran on my G4 laptop. Contrary to what you may read, you
  don't need a G5 to use this, but it may be that I didn't compile
  anything that really worked the code generator. There are xlc (that's the
  compiler's name) equivalents of gcc's -mcpu and -mtune, so you might need
  to enable G5 code generation. I didn't build with optimizations at all.
  - xlc doesn't understand #pragma pack(push,x), but it does know
  what #pragma pack(pop) is. More to my amazement, it understood and
  correctly used GCC's __attribute__((aligned,packed(x))) syntax.
  - It understands Apple's Altivec keywords ("vector float x", "vec_splat_u32"
  and such), if you enable them with -qaltivec on the command line. GCC
  uses -faltivec.
  - There are a LOT of well documented knobs and dials you can tweak on the
  compiler...an overwhelming amount, to be honest. I like that in precisely
  the same way that I hate it. It does appear that all the specific
  optimizations you can hand-pick in gcc are here and many more.
  - Ogg Vorbis, zlib, and Speex all compiled without a single warning. I
  haven't tried to use the compiled binaries, though. I built them directly
  with my own Makefiles and without using the autoconf scripts.
  - alloca is a function call by default (which doesn't link on OSX, but maybe
  I didn't look closely enough). You can make alloca inline (which, honestly,
  I always assumed it was by default universally), with the -ma option.
  - fsigned-chars is -qchars=signed
  - If you're counting on __GNUC__ being defined to signify a Unix build, time
  to fix your code. I have no idea what xlc actually does define at this
  moment, but I'm sure it defines something.
  - Inline asm: I hope there's something better than this suggests:
  http://www-1.ibm.com/servers/esdd/articles/power4_mem.html
  (Look for "#pragma mc_func" and "#pragma reg_killed_by"). I know that
  developers using GCC have no right to bitch about other compilers when
  it comes to inline asm syntax, but...yikes.
  - There's line number debug information, so you can trace through an xlc-
  compiled program in GDB, but there's no data debug info, so you can't
  examine any variables. Even intrinsics like "int c;" will not be viewable
  in gdb. This is documented, and I assume will change. Still, it's a pain
  in the short term, especially since moving to a new compiler exposes
  bugs where you really need to utilize a debugger to find. Well, printf()
  works. :)

  I'll have to look into it more closely.

--ryan.


When this .plan was written: 2003-08-29 23:44:05
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.