[quake3] Re: Mac work...

[Ryan C. Gordon]

> I noticed while poking about with the Xcode build (via pearpc) that
> MACOS_X is defined by the build system. This seems a bit poo. Does any
> body know what the "definitive" OS X define is? A cursory glance over
> http://developer.apple.com/technotes/tn2002/tn2071.html suggests there
> isn't one!

(PearPC?! Dear lord, that must be painful...)

There's isn't one...you can look for something like ((__DARWIN__) && 
(__APPLE__)), but that's always been awkward imho.

Forcibly defining MACOS_X is fine, as far as I'm concerned, as long as 
we don't make the usual mistake of using it when we mean "powerpc" or 
"bigendian architecture" ... I'm sure we have a few of those in there, 
which I'll weed out next week when I build this on an x86 Mac.

> I'm not sure I understand this. id386 is (indirectly) defined by qasm.h,
> so moving the #include to after the #if means that the contents of the
> #if will never been seen -- on any platform. A powerpc build should not
> #be including these files anyway since they are x86.

I was just trying to get it to compile at all here...I didn't realize 
id386 was defined in there. I'll change that back, and have the makefile 
only include that file on Intel Mac builds.

> It looks as if the Altivec build is fairly broken in general (and has
> been since day 1). It would be nice if somebody skilled in the ways of
> __VEC__  could take a look at it, but it seems Mac developers are thin
> on the ground.

Actually, LerpMeshVertexes() is definitely broken in debug builds with 
Altivec, but everything else seems fine (including this function in 
release builds)...there are some other rendering issues, but they don't 
appear to be Altivec-related.

--ryan.