Spring RTS Engine

It would eb easier for me to patch up battlehub and hope it works, than to spend my time figuring out springlobbies internals, then the inevitable 200+ buglist that needs sorting before another platform is even considered.

As for OS X users not liking crossplatform apps, this is normally because the mac ports do not look like mac programs, and its highly abrasive.

I haven't had much time to look at spring recently, sorry about that.

I would rather use a cross platform application than not have anything at all. I do prefer to use native Cocoa apps over the cross platform ones as long as they have the same functionality, but mostly just because they look nicer. The biggest reason that most people prefer to use mac apps is that in many cases they can be downloaded as one small app bundle, which is much easier than having to download source bundles and build them like most linux users do.

I would be very glad to get Mac support back in Spring. I am willing to help with both Spring and springlobby, although I don't know how much help I can be. I am going to see how the patch applies to master.

AF wrote:It would eb easier for me to patch up battlehub and hope it works, than to spend my time figuring out springlobbies internals, then the inevitable 200+ buglist that needs sorting before another platform is even considered.

If you're saying SpringLobby has 200+ (known) bugs and that mac won't be considered before they're all fixed, please stop. That's just blatantly false and you prolly should know better.

revcompgeek wrote:The biggest reason that most people prefer to use mac apps is that in many cases they can be downloaded as one small app bundle

Our cmake buildsystem should be able to produce just that.

revcompgeek wrote:I am willing to help with both Spring and springlobby, although I don't know how much help I can be.

Your help would be greatly appreciated and you don't really need to dig in SL's internals. We can try to fix problems from afar when they arise. We just need to know what they are!

I'm saying its foolish to port a program that has a considerably number of bugs, many of which are considered show stoppers, not that it cannot be done.

AF wrote:I'm saying its foolish to port a program that has a considerably number of bugs, many of which are considered show stoppers, not that it cannot be done.

then spring for mac is hopeless since it meets all your criterias for "foolish to work on"

in the case i'm not clear, i'm not suggesting you at all to work on SL nor spring, i just find the statement a bit silly especially considering that the problem is/has always been not making the lobby run, but rather spring itself

revcompgeek, I made my fork on github and pushed a few changes to it. Please see it instead of the outdated patch.
here is my fork:http://github.com/yokosou/spring/tree/master

I could make a binary of springlobby with a few change to the source code. I could play spring with one of my friends using the binary and lobby server for linux. That binary was a little slow and baggy but, I think this is because I could not port it completely.

Alright, I have pulled changes from yokosou on github. Every file builds, except for rts/System/Sound/Sound.cpp with some very weird OpenAL bugs. I can't figure them out, and Google isn't helping much so I'm hoping someone here can help: I am also working on building springlobby, and I'm getting lots of warnings but it appears to be working so far.

Edit: I have built springlobby and it is working great as far as I can tell. It actually looks quite nice, although there are a few layout issues that will need to be fixed.

Very good, find us in #springlobby sometime to talk about the layout issues.

As for the spring compile problems, you sure it finds the OpenAL headers?

revcompgeek wrote:Alright, I have pulled changes from yokosou on github. Every file builds, except for rts/System/Sound/Sound.cpp with some very weird OpenAL bugs. I can't figure them out, and Google isn't helping much so I'm hoping someone here can help

Well i have been following this and another thread that are BOTH building a 0.80 binary for OSX and I was having the same kind of problems with the OpenAL frame work. First off i went and changed the code so that it would all compile nicely, i added in a few casts and changed the types of some of the variables in the "Sound.cpp" file. compiled nicely until it tried to link all of ".o" files together. it did not like the OpenAL framework. I did a bit of research and found that my project was linking to the OpenAL framework at "Library/Frameworks/" and should be linking to "System/Library/Frameworks/" all i did was TEMPORARILY moved the "Library/Frameworks/" framework to my desktop, rebuilt spring all the way from the beginning, and moved the framework back to where it was.

or you can go into the "CMakeCache.txt" file and change a few lines:

//Path to a file.
OPENAL_INCLUDE_DIR:PATH=/Library/Frameworks/OpenAL.framework/Headers

//Path to a library.
OPENAL_LIBRARY_RAW:FILEPATH=/Library/Frameworks/OpenAL.framework

to:

//Path to a file.
OPENAL_INCLUDE_DIR:PATH=/System/Library/Frameworks/OpenAL.framework/Headers

//Path to a library.
OPENAL_LIBRARY_RAW:FILEPATH=/System/Library/Frameworks/OpenAL.frame

Sorry to bump this thread - just wanted to notify anyone subscribed to it that there is a test binary release available for Snow Leopard.