XCode 2.0 Steps to compile

#1 I went through the same process to get mine working (10.3.9). I'm surprised that the audio didn't work on Tiger, though, since Apple is preinstalling a tweaked version of the OpenAL framework (http://developer.apple.com/audio/openal.html). I was about to install Tiger myself, and was hoping audio would work without the hack of installing the older OpenAL :-(

Did you try to run Torque using the Apple supplied OpenAL, or did you install the latest OpenAL framework from the Creative site?

#2 As far as I know you need an older version of OpenAL which was compatible when Torque was first created. I had to go to the link below (look for Josh Williams post) to get the older drivers.

http://www.garagegames.com/mg/forums/result.thread.php?qt=20401

#3 I haven't tried the version of OpenAL that Apple ships with Tiger yet, it might work. If anyone tries it before me, please post and let it be known whether it works or not. :) Thanks.

As for the GCC4 errors... we'll be looking into that. It's a bummer, the early versions of XCode 2.0 we had worked great, and as Paul says it can still work. But it'll be cooler when we get it compiling in GCC4. As above, if anyone beats me to it, please post the changes you had to make. :) I won't get a chance to look at GCC4 compiling for about 2 weeks myself. Crazy busy here.

#4 Thanks for the tip, Paul and everyone else in this thread.

#5 However my Tiger was configured by default, sound did not work with Torque. I don't know much about OSX, but I just did the Tiger upgrade that came with my iBook and then installed Torque 1.3... when sound didn't work I followed the steps I already detailed above.

#6 For the record, the WarZone demo [which ROCKS, and also plays nicely in Widescreen format 1280x800], does *not* have working sound. i have not yet re-compiled or installed Torque after upgrading to Tiger, choosing to wait until a verifiably Tiger-proof ;) Torque build has been released. [or at the least, until someone can finalize instructions that get it all working reasonably easily].

so, the Tiger-included OpenAL, seemingly, does not work with Torque as it does not work with WarZone.

i will watch this thread closely, and any others noting Tiger compile steps.


- heath

#7 We've dealt with this in ThinkTanks already. If you go into the library/frameworks folder and replace the version of OpenAL that is in there with the one linked to in this thread everything works fine. Not a solution, just a datapoint and a temporary workaround. (Unfortunately, Tiger -- and earlier versions of OSX -- seem to ignore the version of open al that sits in the application package).

#8 How difficult is it, taking the other approach, to get Torque to instead use the Tiger-shipped OpenAL before build-time? [i am a coding newbie..] and, is OpenAL the main outstanding issue with Tiger?

- h

#9 An interesting point... Marble Blast Gold bundled with my OSX Tiger had working sound by default and still after I installed the older OpenAL.

#10 @Paul - I think that was Josh's doing and I think it's because he statically linked the library. Perhaps he can comment...I seem to remember him mentioning some special dance he had to do to get the mac build just right.

#11 What do you do to change it from 4.0 to 3.3 ... I'm a bit lost as to how you did this. I brought up the Edit Project Settings but wasn't sure what to do from there.

#12 Hmmm ... I think I figured that out ... switched it to target 10.3 instead of 10.4. However I get the same 12 errors which all occur in event.h ... what's the deal with this?

#13 Try using the gcc_select command.

sudo gcc_select 3.3

#14 Ah thanks! Had to use the terminal. I'm still working my way through Macs and Xcode so forgive me.

#15 The gcc_select command might work for some, but I led people to think the wrong path for GCC selection in XCode 2. You actually go to Edit Active Target. I made 2 screenshots to help people find it here:

http://img150.echo.cx/my.php?image=untitled1mt1.png
http://img222.echo.cx/my.php?image=untitled22jg.png

#16 Here's what needs to be done for GCC4, at least with the problem in event.h that plagues audioblock.cc and others: the macro Offset(member, type) uses some pretty standard casting/pointer/arithmetic magic to get the offset of the members of a struct/class at compile time. The problem seems to be that GCC4 enforces the C standard maybe a little too strictly, and doesn't allow the use of casts, references or dereferences in constant expressions (like the enum in event.h for the HeaderSizes). What I did to fix it was to conditionally change the enum to a series of #defines (which basically turns it into the original macro) like so: (I'll provide a patch file if necessary, but I think you can figure where this one goes).

#if defined(TORQUE_COMPILER_GCC) && (__GNUC__ >= 4)

// GCC4 doesn't allow casts within constant-expressions (like enums).  Ugly.
#define PacketReceiveEventHeaderSize Offset(data,PacketReceiveEvent)
#define ConnectedReceiveEventHeaderSize Offset(data,ConnectedReceiveEvent)
#define ConsoleEventHeaderSize Offset(data,ConsoleEvent)

#else

/// Header sizes for events defined later on.
enum HeaderSizes
{
   /// Byte offset to payload of a PacketReceiveEvent
   PacketReceiveEventHeaderSize = Offset(data,PacketReceiveEvent),

   /// Byte offset to payload of a ConnectedReceiveEvent
   ConnectedReceiveEventHeaderSize = Offset(data,ConnectedReceiveEvent),

   /// Byte offset to payload of a ConsoleEvent
   ConsoleEventHeaderSize = Offset(data,ConsoleEvent)

};

#endif

This just goes around the original enum.

I kind of hope that there's a way to either just fix the Offset macro to work with GCC4 and integer constants or to set some compiler option, because this seems to be mostly a case of the compiler pedantically following the C specification in places it hasn't before; the macro basically just gets a pointer to the member of a structure addressed at NULL (actually 1 in this case, for whatever reason), so there's no reason it can't be a compile-time decision like it needs to be for enums.

I also had to reorder some class definitions in resManager.h because it was balking at the forward declaration of ResManager for some reason. There's probably a more elegant way of doing it, but reordering the file so that the forward declaration is no longer required fixed things.

#17 A more elegent solution is to simply tell the compiler about the Offset macro for gcc 4.0 in engine/platform/types.h :

// compiler is GCC 3 with minor version greater than 4
#elif defined(TORQUE_COMPILER_GCC) && (__GNUC__ == 3) && (__GNUC_MINOR__ >= 4)
#include
#define Offset(x, cls) _Offset_Variant_2(x, cls)
#define OffsetNonConst(x, cls) _Offset_Variant_1(x, cls)

// compiler is GCC 4
#elif defined(TORQUE_COMPILER_GCC) && (__GNUC__ == 4)
#include
#define Offset(x, cls) _Offset_Variant_2(x, cls)
#define OffsetNonConst(x, cls) _Offset_Variant_1(x, cls)

#endif
#endif

#18 Well, such a macro is something I was looking for, though it looks like your code does the same thing for both versions. I hadn't looked in stddef.h before.

What I'm seeing in stddef.h is the define for a macro (a builtin for GCC >= 3.5, apparently) named offsetof(type, field). It exists as the standard pointer/cast magic for older versions of GCC (my 3.4.3 on my Linux box has it defined as such), so I don't see why we shouldn't use that for GCC regardless.

#19 My thought process for including the additional #define in types.h rather than stddef.h was two fold: All of the final definitions of the Offset macro are included there and I figured there might be more proper way of defining the Offset macro for machines supporting gcc 4.0 (like OS X Tiger).

#20 I guess what I was saying was that older versions of GCC still have the "offsetof()" macro, it's just defined as the pointer business instead of as a builtin. If you look at stddef.h in GCC 4 vs. stddef.h in GCC <= 3.4, you'll see that the 4.0 version has the old version defined as a backwards compatibility.

It's not particularly important, since it takes up so little space, but I think my other original point is that both of those defines have the same code inside (i.e. GCC >= 3.4 and GCC 4 will do the same thing).