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.