Alpha 8 not launching in Mac OS Lion

[collimarco]

Hi!

I've followed the instructions at http://trac.wildfire...atestReleaseMac

Everything works ok until I launch test.app in binaries/system by double-clicking on it in Finder.

The following error is raised:

Process:     	test [27822]
Path:            /Users/USER/Desktop/*/test.app/Contents/MacOS/test
Identifier:      test
Version:     	??? (???)
Code Type:   	X86-64 (Native)
Parent Process:  launchd [115]

Date/Time:   	2011-12-24 15:27:50.293 +0100
OS Version:      Mac OS X 10.7.2 (11C74)
Report Version:  9

Interval Since Last Report:          576845 sec
Crashes Since Last Report:       	11
Per-App Crashes Since Last Report:   5
Anonymous UUID:                      F75B22E4-9D31-45C7-8778-5E5D5339F0F3

Crashed Thread:  0

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: @executable_path/libmozjs185-ps-release.1.0.dylib
  Referenced from: /Users/USER/Desktop/*/test.app/Contents/MacOS/test
  Reason: image not found

Binary Images:
   	0x107fe9000 -        0x10856eff7 +test (??? - ???) <16392DD5-A634-3FA6-95D8-7E3C60DB64C1> /Users/USER/Desktop/*/test.app/Contents/MacOS/test
   	0x1088da000 -        0x108905fff  com.apple.audio.OpenAL (1.5.1 - 1.5.1) <5B954EC6-08B6-3255-932C-DDAB908E72F4> /System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL
   	0x108917000 -        0x10894bfe7 +libjpeg.8.dylib (12.0.0 - compatibility 12.0.0) <91678CF3-F9A9-3A56-A2E8-32B503616BA9> /opt/local/lib/libjpeg.8.dylib
   	0x108953000 -        0x108972fff +libpng15.15.dylib (20.0.0 - compatibility 20.0.0) <48C87023-FB13-393C-8FD4-DE4F1803ECA3> /usr/X11/lib/libpng15.15.dylib
   	0x10897d000 -        0x108990fff +libz.1.dylib (1.2.5 - compatibility 1.0.0) <FE5409A4-0190-3939-9A83-9CF4BEFAEA0C> /opt/local/lib/libz.1.dylib
    0x7fff67be9000 - 	0x7fff67c1dac7  dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld
    0x7fff91b64000 - 	0x7fff91b73ff7  com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL

Model: MacBookPro8,2, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2 GHz, 4 GB, SMC 1.69f1
Graphics: AMD Radeon HD 6490M, AMD Radeon HD 6490M, PCIe, 256 MB
Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 384 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353737334448302D4348392020
Memory Module: BANK 1/DIMM0, 2 GB, DDR3, 1333 MHz, 0x80CE, 0x4D34373142353737334448302D4348392020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18)
Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: APPLE SSD TS128C, 121,33 GB
Serial ATA Device: MATSHITADVD-R   UJ-8A8
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfa100000 / 2
USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000 / 5
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 6
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0246, 0xfa120000 / 4
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfd100000 / 2
USB Device: Elements 1042, 0x1058  (Western Digital Technologies, Inc.), 0x1042, 0xfd120000 / 4
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3

Any ideas?

Thanks

[atopuzov]

I've followed the instructions at http://trac.wildfire...atestReleaseMac

Everything works ok until I launch test.app in binaries/system by double-clicking on it in Finder.

Hi,

I just successfully compiled and run the game.

Instead of double-clicking on the test.app use Terminal to go to the binaries/system directory and copy pyrogenesis.app/Contents/MacOS/pyrogenesis to binaries/system

eg. if you are in binaries/system:

cp pyrogenesis.app/Contents/MacOS/pyrogenesis .

and now run the game from terminal with:

./pyrogenesis

If you don't get full screen and the colors are weird it's because of the incompatibility of libSDL 1.2 and Mac OS X Lion.

I have compiled it with SDL 1.3 (with some minor modifications due to errors eg. [1], but since they are more of hacks just to see if it will compile some of the mouse/keyboard controls are misfiring ) and with it everything with the graphics is OK.

I haven't compiled in the atlas (scenario editor) support because I didn't what to fiddle with wxwidgets

If you want I can provide the binaries (which are unofficial of course), the only constraint is that they will run only on 10.7 64bit systems (due to my environment setup at the compile time)

[1] Link1

Edited December 28, 2011 by atopuzov

[JuliusColtranePille]

could you please upload an employable version of the game? ... i am not really able to compile it myself...

would be cool, thankyou!

[atopuzov]

could you please upload an employable version of the game? ... i am not really able to compile it myself...

would be cool, thankyou!

Hi,

Download the data archive (0ad-r10803-alpha-unix-data) unpack it. You should now have a folder named something like 0ad-r10803-alpha now open it and download the NEW BINARIES and unpack them in the binaries folder (0ad-r10803-alpha/binaries). Now open the binaries dir and double click the pyrogenesis.app. The game should start hopefully. If you get an error please c&p it here. Binaries are tested on 10.7 compiled in 64bit (IMHO they should also run on 10.6). Scenario editor is not provided (just me being lazy). There are some problems with mouse zooming in/out (due to SDL 1.2 and 1.3 quick fix by me).

Update new set of binaries are uploaded with patched SDL 1.2 and Scenario editor!

Best regards

Aleksandar

Edited December 28, 2011 by atopuzov

[collimarco]

Thank you very much atopuzov!

When I copy the file it works! As you said it doesn't start in fullscreen mode.

So I tried your binaries and they work. The game starts in fullscreen mode! The only problem: "Audio has been disabled due to a problem with OpenAL in Mac OS X". Do you have the same problem?

Furthermore during the game a lot of errors appear on the screen (they say many things can't be loaded). Is that normal?

Edited December 25, 2011 by collimarco

[atopuzov]

Thank you very much atopuzov!

When I copy the file it works! As you said it doesn't start in fullscreen mode.

So I tried your binaries and they work. The game starts in fullscreen mode! The only problem: "Audio has been disabled due to a problem with OpenAL in Mac OS X". Do you have the same problem?

Furthermore during the game a lot of errors appear on the screen (they say many things can't be loaded). Is that normal?

Hi,

I also get the error that the audio is disabled due to OpenAL but haven't tried to enable it to see what seems to be happening.

For the errors during the game can you go into the ~/.config/0ad/logs and look at the files and c&p the error (and write what scenario have you chosen, and which binaries are you using mine or yours). I haven't tried playing for a long time so I haven't encountered any. The only errors I got was when I forgot to put the libCollada.dylib file in the right place, which should be in the same directory as the pyrogenesis.app.

Best regards

Aleksandar

[wraitii]

I've actually fixed that in my release. It has to do with the fact that you're trying to use dynamic libraries (dylib) on MacOSX, and the game can't find them because they are not where they "should" be. You have to run a script. Try searching "Mac os X deployment dylib" for more information.

[feneur]

Sound is indeed disabled on Mac for now. We have a rewrite of the sound system underway that should solve that problem. Unfortunately the programmer working on it wasn't able to finish his work in time for Alpha 8. If things go well it should be included in Alpha 9 though and Mac users should finally be able to hear the sounds

[atopuzov]

I've actually fixed that in my release. It has to do with the fact that you're trying to use dynamic libraries (dylib) on MacOSX, and the game can't find them because they are not where they "should" be. You have to run a script. Try searching "Mac os X deployment dylib" for more information.

Hi,

All libraries and executables are 'modified' so the search path is @executable_path/ (install_name_tool)

eg.:

otool -L pyrogenesis.app/Contents/MacOS/pyrogenesis 
pyrogenesis.app/Contents/MacOS/pyrogenesis:
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libjpeg.8.dylib (compatibility version 12.0.0, current version 12.0.0)
	/usr/X11/lib/libpng15.15.dylib (compatibility version 20.0.0, current version 20.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
	@executable_path/libmozjs185-ps-release.1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libvorbisfile.3.dylib (compatibility version 7.0.0, current version 7.4.0)
	@executable_path/libboost_signals-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libenet.1.dylib (compatibility version 2.0.0, current version 2.3.0)
	/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 7.0.0)
	@executable_path/libnvcore.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libnvmath.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libnvimage.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/libnvtt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	@executable_path/libSDL-1.3.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)

But libCollada.dylib is loaded from the app itself by dlopen and I have looked at the source code where does the app try to find it. But for me it works if it's in the folder where the pyrogenesis.app resides and not in the @executable_path which is in fact pyrogenesis.app/Contents/MacOS.

Best regards

Aleksandar

[historic_bruno]

But libCollada.dylib is loaded from the app itself by dlopen and I have looked at the source code where does the app try to find it. But for me it works if it's in the folder where the pyrogenesis.app resides and not in the @executable_path which is in fact pyrogenesis.app/Contents/MacOS.

I believe when you run an app bundle, the working directory is set to the directory where the bundle is located, not where the binary itself is located, it's a special OS X thing, so that's why it will search and find libraries there. At least that's what it does by default, I don't know if the behavior can be changed.

[atopuzov]

Sound is indeed disabled on Mac for now. We have a rewrite of the sound system underway that should solve that problem. Unfortunately the programmer working on it wasn't able to finish his work in time for Alpha 8. If things go well it should be included in Alpha 9 though and Mac users should finally be able to hear the sounds

Hi,

Great news indeed. While you are at it could you possibly check out the compatibility with libSDL 1.3 since 1.2 doesn't run well on Mac OS X 10.7 Lion (no fullscreen, and some glitches with the colors). The error I have encountered was to do with SDLK_LAST not being available (I just added a define for it) and something to due with sync settings which I disabled (can't really remember now). Just try to compile it with libSDL 1.3 and you get the errors.

Best regards

Aleksandar

[atopuzov]

I believe when you run an app bundle, the working directory is set to the directory where the bundle is located, not where the binary itself is located, it's a special OS X thing, so that's why it will search and find libraries there.

Hi,

Yes that's correct for opening the libraries with dlopen and likes. But for linked libraries you change the locations with install_name_tool to be sure that the right libraries are found when deploying Mac OS X applications. (eg. check the Mac OS X QT deployment guide). So for 1. you have to add it in the source code of the application to look for it at the right place.

eg. for QT

#if defined(Q_OS_MAC)
        QDir exec_dir = QDir(QCoreApplication::applicationDirPath());
#endif

And now you have exec_dir (which is set at the location of the executable) and you can now use it to find whatever you need. So when you distribute the app you have everything bundled up in one app.bundle.

Best regards

Aleksandar

[historic_bruno]

Great news indeed. While you are at it could you possibly check out the compatibility with libSDL 1.3 since 1.2 doesn't run well on Mac OS X 10.7 Lion (no fullscreen, and some glitches with the colors)

There may be a patch for SDL 1.2 that fixes the Lion fullscreen issue, which would be worth testing. Otherwise if we use a 1.3 development version on OS X, we have a whole different set of possible bugs to work around and it diverges from the Linux and Windows paths. Of course there are other problems with SDL 1.2, namely the GL context gets lost when switching between windowed and fullscreen in Windows and OS X, which requires some changes on our end.

[atopuzov]

There may be a patch for SDL 1.2 that fixes the Lion fullscreen issue, which would be worth testing. Otherwise if we use a 1.3 development version on OS X, we have a whole different set of possible bugs to work around and it diverges from the Linux and Windows paths. Of course there are other problems with SDL 1.2, namely the GL context gets lost when switching between windowed and fullscreen in Windows and OS X, which requires some changes on our end.

Hi,

Can you provide a link for the patch since I've seen a few and haven't had the time to read trough which is the latest and fixes the problems. It's not only the fullscreen issue, I can live with windowed mode but all the colors are wrong and there are some image tearing. Since nobody knows when SDL 1.3 will be released I get your point (we saw a release of duke nukem so we can only hope) of having a one version of library on Mac and an other on Win/Lin. It would hard to maintain.

Best regards

Aleksandar

[historic_bruno]

Here's the SDL 1.2 patch I mentioned. It would be nice if we could make a script to get all OS X dependencies (for developers of course, not the average user), then it could apply that patch to SDL before building it.

It's not only the fullscreen issue, I can live with windowed mode but all the colors are wrong and there are some image tearing

Hmm I haven't noticed this at all, though I only have a VM for testing. Can you post a screenshot of what you are seeing?

[jdm]

Interestingly enough, on Snow Leopard the full screen mode works but windowed mode is completely broken.

[Chakakhan]

Here's the SDL 1.2 patch I mentioned.

Yes, that patch works. The fix isn't in an official release, so it is problematic for our OS/X users.

Ben - as you, Phillip and I discussed, the best solution is to include all the 3rd party libs in an app bundle so that OS/X users could just download and run the game without worrying about supporting libraries. I think we should try to do this for Alpha 9. It would really make help us in supporting Mac versions going forward and also allow less technical Mac users to play the game.

Cheers

Interestingly enough, on Snow Leopard the full screen mode works but windowed mode is completely broken.

Yes, the Cocoa calls to set the video mode changed and this caused some issues. The full solution is to add code to detect the desktop resolution and to include the proper patched version of SDL in our release somehow. This will solve the full screen / windowed mode problems.

Cheers

[wraitii]

Note that the Collada loading problem can be fixed in a more "convergent" way by simply adding a bit of platform-dependant code. I did so in my release: I Changed the DLL loader function LoadAnyVariant to this

static void* LoadAnyVariant(const CStr& name, std::stringstream& errors)
{
	for(size_t idxSuffix = 0; idxSuffix < ARRAY_SIZE(suffixes); idxSuffix++)
	{
		for(size_t idxExtension = 0; idxExtension < ARRAY_SIZE(extensions); idxExtension++)
		{			
			CStr filename = GenerateFilename(name, suffixes[idxSuffix], extensions[idxExtension]);

			// Here's what I added
			// this should ensure Collada is properly loaded.
			#if OS_MACOSX
			if (name == "Collada" || name == "AtlasUI")
				filename = "@executable_path/../Frameworks/" + filename;
			#endif

			// we don't really care when relocations take place, but one of
			// {RTLD_NOW, RTLD_LAZY} must be specified. go with the former because
			// it is safer and matches the Windows load behavior.
			const int flags = RTLD_LOCAL|RTLD_NOW;
			void* handle = dlopen(filename.c_str(), flags);
			if(handle)
				return handle;
			else
				errors << "dlopen(" << filename << ") failed: " << dlerror() << "; ";
		}
	}

	return 0;	// none worked
}

(note that I link to "Frameworks" because I copied there every library needed for the game.

Linking even the Data in it can be done too, but requires slightly greater changes.

I also report the fact that going from FS to windowed mode crashes. Though the fullscreen mode works correctly.

As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries).

Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.

Edited December 26, 2011 by wraitii

[Chakakhan]

As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries).

Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.

Cool, hopefully you can help us figure out the best way to implement this.

Cheers

[wraitii]

I'm going to be away for a week, so won't be able to help much during this time, but the Idea is that you need to add a "copy file" phase and a "run script" phase to your Xcode projects. In the copy file phase, you'd copy every single dylib needed (I record 25). In the run script, you'll have to change the links so that it works.

You may want to take a look at this. I don't think it can compile as such, and it's not a perfectly up-to-date project, but it'll give you the idea.

[atopuzov]

Note that the Collada loading problem can be fixed in a more "convergent" way by simply adding a bit of platform-dependant code. I did so in my release: I Changed the DLL loader function LoadAnyVariant to this

(note that I link to "Frameworks" because I copied there every library needed for the game.

Linking even the Data in it can be done too, but requires slightly greater changes.

I also report the fact that going from FS to windowed mode crashes. Though the fullscreen mode works correctly.

As for the release, indeed linking every library with the app bundle is needed and not too hard (a simple copy and scripting issue, which is fairly straightforward.) Note that some of the libraries used are relying on other libraries, so you have to make sure you modify everything (not only the executable and the libraries, but the calls between libraries).

Putting the Data inside the game bundle might not be a priority for now, as long as the game works when you start it.

Hi,

Yup that's what I was talking about.

IMHO the only change to data loading should be that it's loaded from the folder where the app bundle is '.data' instead of '../data' (notice the ..) eg. if the main folder is 0ad, now data is in 0ad/data and binaries in 0ad/system (this is where the app bundle resides) and the app looks for data in ../data and much more convenient way would be to have for example 0ad and in that folder the app bundle and data in 0ad/data.

One more request is that it would be nice that someone creates a 512x512 image from which we could create the Icons for Mac OS X,

Best regards

Aleksandar

P.S. This is what I used to modify the libraries and the binary.

install_name_tool -id @executable_path/libboost_filesystem-mt.dylib libboost_filesystem-mt.dylib
install_name_tool -change /usr/local/lib/libboost_system-mt.dylib @executable_path/libboost_system-mt.dylib libboost_filesystem-mt.dylib

install_name_tool -id @executable_path/libboost_signals-mt.dylib libboost_signals-mt.dylib
install_name_tool -id @executable_path/libboost_system-mt.dylib libboost_system-mt.dylib
install_name_tool -id @executable_path/libjpeg.8.dylib libjpeg.8.dylib

install_name_tool -change /usr/local/lib/libjpeg.8.dylib @executable_path/libjpeg.8.dylib pyrogenesis
install_name_tool -change /usr/local/lib/libvorbisfile.3.dylib @executable_path/libvorbisfile.3.dylib pyrogenesis
install_name_tool -change /usr/local/lib/libboost_signals-mt.dylib @executable_path/libboost_signals-mt.dylib pyrogenesis
install_name_tool -change /usr/local/lib/libboost_filesystem-mt.dylib @executable_path/libboost_filesystem-mt.dylib pyrogenesis
install_name_tool -change /usr/local/lib/libboost_system-mt.dylib @executable_path/libboost_system-mt.dylib pyrogenesis
install_name_tool -change /usr/local/lib/libSDL-1.3.0.dylib @executable_path/libSDL-1.3.0.dylib pyrogenesis
install_name_tool -change libnvcore.dylib @executable_path/libnvcore.dylib pyrogenesis
install_name_tool -change libnvmath.dylib @executable_path/libnvmath.dylib pyrogenesis
install_name_tool -change libnvimage.dylib @executable_path/libnvimage.dylib pyrogenesis
install_name_tool -change libnvtt.dylib @executable_path/libnvtt.dylib pyrogenesis

install_name_tool -id @executable_path/libSDL-1.3.0.dylib libSDL-1.3.0.dylib

install_name_tool -id @executable_path/libvorbisfile.3.dylib libvorbisfile.3.dylib
install_name_tool -change /usr/local/Cellar/libvorbis/1.3.2/lib/libvorbis.0.dylib @executable_path/libvorbis.0.dylib libvorbisfile.3.dylib
install_name_tool -change /usr/local/lib/libogg.0.dylib @executable_path/libogg.0.dylib libvorbisfile.3.dylib

install_name_tool -id @executable_path/libogg.0.dylib libogg.0.dylib

install_name_tool -id @executable_path/libvorbis.0.dylib libvorbis.0.dylib
install_name_tool -change /usr/local/lib/libogg.0.dylib @executable_path/libogg.0.dylib libvorbis.0.dylib

install_name_tool -id @executable_path/libnvcore.dylib libnvcore.dylib
install_name_tool -id @executable_path/libnvmath.dylib libnvmath.dylib
install_name_tool -change libnvcore.dylib @executable_path/libnvcore.dylib libnvmath.dylib

install_name_tool -id @executable_path/libnvimage.dylib libnvimage.dylib
install_name_tool -change libnvcore.dylib @executable_path/libnvcore.dylib libnvimage.dylib
install_name_tool -change libnvmath.dylib @executable_path/libnvmath.dylib libnvimage.dylib
install_name_tool -change /usr/local/lib/libjpeg.8.dylib @executable_path/libjpeg.8.dylib libnvimage.dylib

install_name_tool -id @executable_path/libnvtt.dylib libnvtt.dylib
install_name_tool -change libnvcore.dylib @executable_path/libnvcore.dylib libnvtt.dylib
install_name_tool -change libnvmath.dylib @executable_path/libnvmath.dylib libnvtt.dylib
install_name_tool -change libnvimage.dylib @executable_path/libnvimage.dylib libnvtt.dylib
install_name_tool -change /usr/local/lib/libjpeg.8.dylib @executable_path/libjpeg.8.dylib libnvtt.dylib

install_name_tool -id @executable_path/libCollada.dylib libCollada.dylib

[historic_bruno]

Interestingly enough, on Snow Leopard the full screen mode works but windowed mode is completely broken.

The problem that affects all versions of OS X with SDL 1.2 is switching between fullscreen and windowed modes or changing resolution, if you want windowed mode, you can just change the game's config file to always start in windowed mode and choose a default resolution. This works fine for me, just don't stretch the window or it will break

This will solve the full screen / windowed mode problems.

What about changing resolution or toggling fullscreen/windowed mode? As far as I know, we need to reload our GL state (though I did also see a few 1.2 patches attempting to preserve the GL context in some situations - I don't know if that has been perfected, I still think it's a worthy goal to be able to reload the state).

[wraitii]

There 's a weirder issue though... On Lion, when I play 0AD, there's a weird issue with the desktop that becomes "translated"... it's hard to explain really but it's like everything in the desktop was 200px higher than it really is (clicks are wrong and so on). Restarting the Finder fixes it, changing a few stuffs fixes it too, but it's fairly weird.

[Kimball]

If anyone's got a minute on IRC, I've got an error when I try to build the game (and I'm not sure what else might come after that's taken care of). Here's what I'm getting:

==== Building ActorEditor (release) ====
test_LOSTexture.cpp
test_TextureConverter.cpp
test_TextureManager.cpp
In file included from /opt/local/include/js/jspubtd.h:97,
                 from /opt/local/include/js/jsapi.h:47,
                 from ../../../source/scriptinterface/ScriptTypes.h:81,
                 from ../../../source/simulation2/system/Message.h:21,
                 from ../../../source/simulation2/system/IComponent.h:22,
                 from ../../../source/simulation2/system/Interface.h:21,
                 from ../../../source/simulation2/components/ICmpRangeManager.h:21,
                 from ../../../source/graphics/LOSTexture.h:21,
                 from ../../../source/graphics/tests/../../../source/graphics/tests/test_LOSTexture.h:20,
                 from ../../../source/graphics/tests/test_LOSTexture.cpp:14:
/opt/local/include/js/jsproto.tbl:67:5: warning: "JS_HAS_FILE_OBJECT" is not defined
In file included from ../../../source/simulation2/system/Message.h:21,
                 from ../../../source/simulation2/system/IComponent.h:22,
                 from ../../../source/simulation2/system/Interface.h:21,
                 from ../../../source/simulation2/components/ICmpRangeManager.h:21,
                 from ../../../source/graphics/LOSTexture.h:21,
                 from ../../../source/graphics/tests/../../../source/graphics/tests/test_LOSTexture.h:20,
                 from ../../../source/graphics/tests/test_LOSTexture.cpp:14:
../../../source/scriptinterface/ScriptTypes.h:92:2: error: #error Your compiler is trying to use an incorrect version of the SpiderMonkey library.
../../../source/scriptinterface/ScriptTypes.h:93:2: error: #error The only version that works is the one in the libraries/spidermonkey-tip/ directory,
../../../source/scriptinterface/ScriptTypes.h:94:2: error: #error and it will not work with a typical system-installed version.
../../../source/scriptinterface/ScriptTypes.h:95:2: error: #error Make sure you have got all the right files and include paths.
In file included from /opt/local/include/boost/unordered/unordered_map.hpp:17,
                 from /opt/local/include/boost/unordered_map.hpp:16,
                 from ../../../source/simulation2/Simulation2.h:28,
                 from ../../../source/graphics/tests/../../../source/graphics/tests/test_LOSTexture.h:22,
                 from ../../../source/graphics/tests/test_LOSTexture.cpp:14:
/opt/local/include/boost/unordered/detail/allocator_helpers.hpp:29:5: warning: "BOOST_UNORDERED_USE_ALLOCATOR_TRAITS" is not defined
/opt/local/include/boost/unordered/detail/allocator_helpers.hpp:193:5: warning: "BOOST_UNORDERED_USE_ALLOCATOR_TRAITS" is not defined
In file included from /opt/local/include/boost/unordered/detail/equivalent.hpp:16,
                 from /opt/local/include/boost/unordered/unordered_map.hpp:18,
                 from /opt/local/include/boost/unordered_map.hpp:16,
                 from ../../../source/simulation2/Simulation2.h:28,
                 from ../../../source/graphics/tests/../../../source/graphics/tests/test_LOSTexture.h:22,
                 from ../../../source/graphics/tests/test_LOSTexture.cpp:14:
/opt/local/include/boost/unordered/detail/extract_key.hpp:54:5: warning: "BOOST_UNORDERED_USE_RV_REF" is not defined
make[1]: *** [obj/test_Release/test_LOSTexture.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [test] Error 2

Also, I was able to build the game a couple days ago, but I ran into a weird issue. I can start the game and everything, but I can't see anything; it's all black. I can tell it's all loaded because the map is there and when I hold Q or E, the map rotates as if the camera is rotating as well. This happens in Atlas too, but for some reason the ActorViewer works. I can't find anything in the Terminal log that would indicate any type of error. Also, the Alpha 7 precompiled package from this thread works great on my computer, with the minor issue that it's not Alpha 8 (and Atlas doesn't work). Here's a screenshot and some system info:

OS: Mac OSX 10.7.2 (Lion)
HW: MacBook Pro (15-inch, Mid 2009)
    2.8 GHz
    4 GB RAM
    NVIDIA GeForce 9400M & 9600M GT
    64-bit kernel enabled
GV: Alpha 8 Custom Build (r10814)

[Juicyfruit]

Hi I to have been compiling it on lion.

I have sound working with OpenAL-soft. Also I think to make a good useable binar one would need to compile nvtt without cuda support.

Maybe we should even make a subversion repo with binary libs + headers instead of compiling agains a bunch of mac ports libraries that also depend on each-other.

I know that Vdrift, Luxrender and Blender use this approach.

Also for SDL 1.2 there is a patch that fixes the Lion fullscreen GL issue:

http://lists.libsdl.org/pipermail/commits-libsdl.org/2011-September/004560.html

But this does NOT apply cleanly on libSDL 1.2.14.

As far as an OS X bundle is concerned I think the assets should also go inside the bundle.

I would love to talk on IRC about improving the mac packaging situation