So, what is to be done about lobby support? Is there going to be an SL branch, or does somebody plan to bring back QT? Most Mac users I know are going to lose interest pretty quickly if they can't at least try to play MP.

One of the people I thought might like to try it said this came up...



His processor is a Core 2 Duo.

I plan to have a go first at getting SpringLobby working, then I'll turn my attention to QT Lobby and see what state that is in and see if it is worth taking on. I personally have never liked SpringLobby very much - so I would love to have an alternative to use myself.

Can I have more information about the specific machine? i.e. model, installed version of Snow Leopard, graphics card, etc.

NVIDIA GeForce 9400
Model Identifier: iMac 9,1
OS X: 10.6.1
Memory: 2 GB

@Belmakor, I tested your release and it works good on:
MacBook Pro 5,4
Intel Core 2 Duo
2,53 Ghz
4 GB Memory
Nvidia GeForce 9400M 256 MB 1440 x 900

Only issue I had was that Kernel Panic's own in game menu won't load the actual game. I guess some functionality is lacking there. Spring1944 looks real nice! Ohh,.. and actually selecting an AI from the menu (in combination with Spring1944) would crash Spring once it loaded the map. I guess the AI's are not provided?

Thanks for the feedback!

The AIs are there, but yes, don't seem to be working for any mod I tried. Thinking about it now I have a suspicion why, but I'll have to look at it tonight in detail or something.

I think this is because AI's library files have a bad extension. For example, ".spring/AI/Interfaes/C/0.1/libAIInterface.so" should be "libAIInterface.dylib". After renaming the libraries, I could start game with AI with your binary.

This problem seems to be fixed in the latest code on git by this commit : http://github.com/spring/spring/commit/0995062ec6a9cade46ddcd59fe57722816a1dee1

By the way, the simpler method is not working because Mac OS X is considered as an Unix in cmake. So, you have to use "if(APPLE) ... endif(APPLE)" to specify Mac OS. I also made a similar change on my branch I said before.

Hey,

I'm joining the Mac porting efforts, but I to am cursed, be warned!

What I've done so far:
Compile the stock spring.
Write a portfile for macPots: http://trac.macports.org/ticket/23556
Compile QTLobby.
Tried to compile SpringLobby... Failed.

I also helped testing some fixes on IRC, like the .so AI bug.

Today I tried to compile this branch: http://github.com/yokosou/spring/tree/0.81.1.3-mac

That also failed, and I ended up with this compile log: http://pastebin.com/m2259ac49

Thanks for trying my branch. It seems that SDLMain.m uses an internal class of AppKit which only exists on 32bit.

Can you compile it for 32bit or replace SDLMain.m with the latest one? To compile it for 32bit run cmake with these options.

The latest SDLMain.m is included in the latest runtime library on the official site of SDL. Please copy MacMessageBox function from the original file or disable it and use X implementation in errorhandler.cpp if you use this method.

I could compile SpringLobby without torrent and sound support. wxWidgets doesn't support 64bit on Mac now, so I had to compile it for 32bit. I also disabled sound because it seemed that OpenAL headers are not included properly. I haven't tried libtorrent yet.

But, there are mainly two problems. First, some GUI parts does not respond to clicking. This happens on "Locate the path to unitsync" window of springsetting, which makes it useless. And I couldn't open springsetting panel from springlobby too. Second, If I select a Map in singleplayer tab, quit springlobby, launch it again and select the Map, start positions of the Map are not in right positions. Only one start position is on the left-top of the map. Deleting cache files seemed to fix it, so I think something is wrong with them.

So basically the Mac port is waiting for wxWidgets and SDL to switch to Cocoa and add 64 bit support?

I compiled an SVN release of wx to get Cocoa, but I did not try SDL yet.
How comes the standard Spring does compile one Mac and your branch does not? Is standard Spring not relying on SDL?

Which projects do I need to compile to 32 bit to get them working? Spring? wx? SpringLobby? SDL? All the same arguments?

I'm sorry, my last reply was confusing. SDL supports 64 bit in the latest stable release. I updated my branch and you should be able to compile it for 64bit now.

SDLMain.m is a source file that is included in Spring. And the source file was based on old SDL release, so it didn't compile to 64bit. I don't know why standard Spring didn't failed because it should include the same file. Maybe it's because you used libSDLmain instead of SDLMain.m. SDLMain.m and libSDLmain are explained in official FAQ of SDL : http://www.libsdl.org/faq.php?action=listentries&category=7#55


I didn't know there is a SVN release of wx that supports Cocoa and I haven't tested it yet. Only thing I can tell is that I was able to compile SpringLobby with wxWidgets for Carbon. I installed wxWidgets from Macports and built SpringLobby with the arguments I wrote.

Old TA player; new to Spring.

I downloaded your build, created ~/.spring/maps and mods, and put BA712.sd7 in mods and MountainGassLands_v1.4.sd7 in maps.

Fired up your app, chose up those and RAI601. It then went through the lengthy startup and then... disappeared from the screen. It was still running, but I couldn't switch to it and nothing was obviously happening.

Further testing suggests this depends on which AI I choose. If I pick "Commander", it starts up but I don't get an AI. Two others I tried got to displaying the overhead view, and then it all disappears.

I tried renaming all the .so files to .dylib and it didn't help.

But hey, thanks for doing this, and I'm happy to test.

you need dylibs for sure, so AIs will not work under OS X, that's a fact.

it is hard to imagine that the AI could corrupt something graphic related. consider attaching infolog.txt as file, from a game with problems, please.

I have a problem when compiling from source with the error:



How to solve this problem?

Try to compile 0.81-branch instead of the source package. That is same as release except that 2 extra mac patches are included.

I read somewhere that you could rename the AI files. Oh well.

Since I hear the AIs are good, it would be fun to have them available. Particularly until we get lobby software.

My infolog.txt is attached.

Thanks for rocking this!

yeah, renaming them should solve the problem. what i was trying to say is, that if you have .so's, and no dylib's, it definitely will not work. i can not see anything interesting in your infolog, sorry.

Anyone built a 32 bit version? I'd love to try this with a friend, but he only has Core Duo.

Good stuff so far. I played around with trying to create an installer .pkg (would be easier than instructing the user on how to create a Unix-style hidden directory on a Mac), but its giving me issues when it comes to actually creating the directory.

If you post the patches you've made to the source, I could look at fixing the folder paths where it picks up the user data (i.e.: using ~/Library/Application Support/Spring instead of ~/.spring).

rts/System/FileSystem/DataDirLocater.cpp is where you want to look at, look at DataDirLocater::LocateDataDirs().
the MACOSX_BUNDLE has to be manually defined when compiling ("-DMACOSX_BUNDLE"), but is meant to only be used when creating a bundle (obviously ). If not specifically compiling a bundle, then the same dirs as under linux/unix are used. of course you could add an other #ifdef APPLE, but i doubt that this will be a god idea, mainly because it works as it is now, and using a different data-dir mechanism for OS X then for Linux would make debugging and support for us much harder, as non of the devs or other people would remember the dirs there.
anyway.. if you can not create a hidden directory, then it is not time to change spring to edit spring.