Finger info for

 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.

 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.

 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.


America's Army:
 Linux 1.9 is live:
 ...and the Mac version:

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 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:
    (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.


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.24
Stick it in the camel and go.