1

Topic: Mac OS X Port (for 1.6)

I'm a few hours into the OS X port, trying to make it work in the new Xcode... No success yet. I will probably end up rebuilding the project from the ground up (tedious, but worth it I think, lots of old cruft and randomness).

Some semi-disappointing news though, is that the (old) version of Xcode (4.1) I'm working with only supports Snow Leopard (OS X 10.6)+. If I were to upgrade to the latest Xcode (4.5), it would be strictly Lion/10.7+.

Probably going to stick with: OS X 10.6+ 32/64bits vs. OS X 10.7+ 64bits.

Any thoughts?

Obviously if I have to compile to 32 bit due to library limitations or whatever, it will still run on a 64 bit system.

Cheers.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

2

Re: Mac OS X Port (for 1.6)

+1 for backward compat. I still use 10.6 on hackintoshes.

Currently Playing:
Celeste and Electronic Super Joy

3

Re: Mac OS X Port (for 1.6)

10.6 support seems worthwhile.

Cheese
==========
cheesetalks.net

4

Re: Mac OS X Port (for 1.6)

See here: http://forum.nevercorner.net/viewtopic. … 961#p27961
Making some good progress.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

5

Re: Mac OS X Port (for 1.6)

I've got another question to pose to you all.

Currently Neverball/putt require the SDL and SDL_ttf frameworks to be included and linked within the .app.
In total these two frameworks are around 3.5 megabytes. The thing is, they're included within each app, so they take up double the space. Going along with this, mapc and the locale directory are also included within each app, taking up double the space. Granted this isn't much nowadays, and it's probably less of a difference on the compressed disk image.

To save some size, I propose that I move these things outside the application bundles.
For the frameworks, I *could* install them on the system (/Library/Frameworks/SDL.framework, etc...), but I would hesitate to do that since we might need to be careful about removing them with the uninstaller. The reason being that I'm not sure if any other applications install SDL frameworks to that location, and if we'd be breaking them by uninstalling it. In that case I say I would have to leave the two frameworks we installed, but it leaves me feeling like we potentially left someones system 'dirty'.

I think I'm leaning towards the other option that I thought of. Currently we have the 'data' folder installed under "/Library/Application Support/Neverball Data/data", and I think this is the prime location for everything to sit.
The folder structure I'm envisioning is:

-- /Library/Application Support/Neverball Data/
   |-- data
   |   |-- "..."
   |   |-- "..."
   |
   |-- locale
   |   |-- "..."
   |   |-- "..."
   |
   |-- Frameworks
   |   |-- SDL.framework
   |   |-- SDL_ttf.framework
   |
   |-- mapc

Thoughts?

@parasti, is it possible to have more than one CONFIG_DATA and CONFIG_LOCALE specified?
The reason I ask this, is that I'd like users to be able to choose whether we install system-wide, or user-only. The two paths would be "~/Library/..." and "/Library/...", if this is currently unsupported, *could* we support it? Would it even make sense? If not, I'm fine with sticking to system-wide I guess.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

6

Re: Mac OS X Port (for 1.6)

Anyone?

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

7

Re: Mac OS X Port (for 1.6)

I like that idea, but are frameworks compatible from 10.6.x to 10.8.x?

Is sandboxing going to be an issue here (10.7.5->) ??

Currently Playing:
Celeste and Electronic Super Joy

8 (edited by jammnrose 2012-10-17 12:57:40)

Re: Mac OS X Port (for 1.6)

I think the frameworks will work on 10.8, but I'm not sure. I can probably ask someone at work with a 10.8 machine to test, as I haven't yet upgraded.

I don't think sandboxing will be an issue...You're talking about Gatekeeper on 10.8, right? Obviously we will require that it's off, or allows 3rd party apps, which I think bypasses the 'sandbox'.

Perhaps we can eventually get it on the Mac App store (I'm willing to pony up the $99 and try it.). In the case of the Mac App store, I think we would have to change the location of things to within the app itself. This would be a big duplication of data, but we wouldn't be hosting the download.

Has anyone thought about trying to release through Steam?

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

9

Re: Mac OS X Port (for 1.6)

Sorry jamm, forgot you posted this.

jammnrose wrote:

@parasti, is it possible to have more than one CONFIG_DATA and CONFIG_LOCALE specified?
The reason I ask this, is that I'd like users to be able to choose whether we install system-wide, or user-only. The two paths would be "~/Library/..." and "/Library/...", if this is currently unsupported, *could* we support it? Would it even make sense?

This sets off some alarms, to be honest. I have literally never touched a Mac in my life, but I can't imagine it being so braindead that you have to actually compile absolute system paths in the executables. Is it really not possible to dump a self-contained folder that has all the data and all the executables (with the default relative paths compiled in) somewhere on the system and install some shortcut equivalents?

Basically things I don't understand:

1) how the game data ends up being not where the game executables are.
2) why the two game executables are totally separate with separate dependencies, separate mapc and separate locale data.
3) why are we hard-coding absolute system paths (this is probably answered by answering #1).

(BTW,  it's actually not even possible to specify "~/Library/" at compile time and have it work. We don't do shell expansion on  filenames. So it will either be compiled in as "/Users/Ben/Library/" or what-have-you, or it will become literally "~/Library/", i.e., a directory called literally "~".)

10

Re: Mac OS X Port (for 1.6)

$HOME works on Lion 10.7.5

Currently Playing:
Celeste and Electronic Super Joy

11 (edited by parasti 2012-10-18 10:43:49)

Re: Mac OS X Port (for 1.6)

And I quote, "We don't do shell expansion on filenames."

Edit: misquoted!

12

Re: Mac OS X Port (for 1.6)

I thought you were worrying about hardcoding system paths? I just typed echo $HOME in a terminal, and it was right, as is ~. I believe ~ is universally handled as /Users/username in Mac OS X 10.6 -> 10.8

Otherwise, I missed the point entirely, and I apologise.

Currently Playing:
Celeste and Electronic Super Joy

13

Re: Mac OS X Port (for 1.6)

themacmeister wrote:

I thought you were worrying about hardcoding system paths? I just typed echo $HOME in a terminal, and it was right, as is ~. I believe ~ is universally handled as /Users/username in Mac OS X 10.6 -> 10.8

"Universally" is a pretty strong word. This isn't OSX exclusive, it's basic Unix stuff. High-level code may perform string expansion, but the level we work at will not. Try this.

$ echo '$HOME'
$ echo '~'

That's the level we work at.

Anyhow, this is getting into the "alternative solutions to the wrong problem" territory. I'd rather we find and fix the real problem.

14 (edited by jammnrose 2012-10-18 14:32:27)

Re: Mac OS X Port (for 1.6)

After some thought on your post, I think I have a better solution. First some information though.

This is the structure of a typical Mac OS X '.app' file/folder (Mac treats special folder extensions with the proper structure as applications or files, e.g. '.app', or e.g. '.xcodeproj').

MyApp.app/
   Contents/
      Info.plist
      MacOS/
         MyApp <-- executable
      Resources/
         SomeResourceFolder/
            SomeResource.txt
      Frameworks/
         ExFramework.framework/

Normally, without setting CONFIG_DATA and CONFIG_LOCALE, the 'data' and 'locale' folders are expected to be alongside 'MyApp.app'.

My thought is this: set the CONFIG_DATA and CONFIG_LOCALE paths to 'Neverball.app/Resources' ('Neverputt.app/Resources'). When you run the installer, the files/folders I listed in my other post would still get copied to '/Library/Application Support/Neverball Data/' or '~/Library/Application Support/Neverball Data/', based on a user or system install (these are appropriate places for application data, much more appropriate than next to the '.app's). As part of the installer, a script could be run to symlink 'Neverball.app/Resources/data' to '/Library/Application Support/Neverball Data/data' (or ~/Library/...), etc...

Thoughts on this method? I think this is cleaner, and results in the minimal install size that we want.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

15

Re: Mac OS X Port (for 1.6)

If no one objects, I think I'm going to go with this method.

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

16 (edited by jammnrose 2012-10-20 12:06:42)

Re: Mac OS X Port (for 1.6)

I feel bad that I didn't answer your questions earlier and more succinctly, parasti:

1) Generally on Mac, applications are installed to /Applications or ~/Applications, with all of their data contained 'within' the application 'bundle' (the ".app" folder). *Some* applications are contained within folders, but this is mostly not the case. With Neverball and Neverputt, we don't want a copy of the data residing within each app, so we need to put it in a shared place. (For windows and *nix, it happens to make sense that it's the same place as the executables.)

2) The game executables, obviously, are two different build targets. I'm in total agreement that they should share their common data, which is what I'm trying to work towards. I think the symlinking method solves this pretty well... but I am open to suggestions too. I definitely want to see a sane and rock-solid Mac package.

3) Yup, agreed, we shouldn't. This should be a process of the installer to setup the correct links, while the compiled path is a relative one.

I certainly won't profess to being an expert at any of this, so if anyone else has ideas, let me know. smile

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

17

Re: Mac OS X Port (for 1.6)

Well, I can see that you are trying to get a response from me. smile Sorry I haven't done that.

Here's the deal. I want this done right, but I'm not in a position where I can determine if we're doing the right thing or not. I can theoretically put myself in that position by reading up on Apple developer documentation, but that would take up a lot of my time, which I don't have. That's why you probably shouldn't expect active participation from me on this. Mostly I'm just worried that we'd get reviews like on macupdate. Clearly something went very wrong with the 1.5 OSX packaging.

Back to the topic at hand, what guarantees do we have that the working directory will always be alongside Neverball.app? My reading suggests that the working directory may vary depending on how the app is launched. Perhaps there is a way to discover the Application Support directory programmatically and chdir to there rather than rely on the working directory and symlinks?

18 (edited by jammnrose 2012-10-20 14:04:00)

Re: Mac OS X Port (for 1.6)

No worries, I don't expect you to read Apple developer documentation. smile I know you're stepping back a bit, and that's fine. It's just helpful to have another set of eyes saying 'yeah that seems sane' or 'WTF!?'. I'm actually surprised that others haven't chimed in more.

The issues with the 1.5 packaging are ones that stem from wanting the presentation of the disk image to look a certain way, more than doing it the right way. In retrospect this was a very bad thing... A few things I can say are this though... The big issue was that the wrapper files that launched the installer were legacy "PowerPC PEF executables", a very old, flat (e.g. not an application 'bundle'), extensionless executable format. Rosetta (the ppc emulation for Mac on x86) could handle these I believe, though there may have been some issues with an older, quickly deprecating framework called Carbon as well. With Lion, (10.7), the Rosetta compatibility layer is gone, you can't even install it... I would have never expected Apple to dump Rosetta so soon. Clearly the packaging is, for lack of a better term, completely fucked to hell.

In any case, I have plans to make that better. It won't be too hard.


So yeah, back to the topic. This link seems to show that I will have a reliable working path. This would be in the folder containing the bundle. I whipped up a quick test with Xcode and this seems like the case (data folder in Neverball.app/Contents/Resources). I launched it various different ways, and it was successful every time. I used the Dock, double-clicking it, and running launch commands from the command line:

$ open /...../trunk/macosx/xcode/build/Devel/Neverball.app/Contents/MacOS/Neverball
$ open /...../trunk/macosx/xcode/build/Devel/Neverball.app

The one issue I can see with this, which could be a blocker, is that the path becomes:

-DCONFIG_DATA=\"./Neverball.app/Contents/Resources/data\"

and similar for Neverputt. If you happened to rename the application bundle to "Neverball2.app" or something, it would no longer be able to find the data folder. This config would only be set for release versions so I don't know that it matters. I'm not aware of people renaming applications very often outside of testing. If this is a blocker, than I think I could easily do something similar to the instructions at the link I listed above.

The non-breaking solution to the case above would be to get the directory INSIDE the application bundle: "Neverball.app/.", OR next to the executable: "Neverball.app/Contents/MacOS/.", so that renaming doesn't break anything. At this level we can be reasonably assured that folder renaming won't happen, and even more, folder renaming inside the bundle usually breaks stuff anyways.
I would suggest that we do use symlinks though, as the location of the data folder may indeed differ. Either: "/Library/Application Support/Neverball/data" or "~/Library/Application Support/Neverball/data". The installer can handle setting up the correct symlink based on a user (~/Applications/) or system (/Applications) install. (Does that seem reasonable? If not, I can try to brainstorm a better way... Also going to look at some docs now.)

Whew, that's a long post.


EDIT: The more I think about it, the more I think I should go with the latter "non-breaking" solution... What's your advice on editing SDLMain.m to our needs? Obviously it's pretty trivial for me do to (very different from what's at that link though). But my point is: should we keep SDLMain.m and SDLMain.h in the repo then? How do we deal with customizations of things we rely on?

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

19

Re: Mac OS X Port (for 1.6)

Mac OS X, auto-update and app size in general are incredible space hogs. I have had two ~1GB Software Updates in the last month. That is about a full install of Windows XP and then some!!!

Anyways, with the advent of roomy hard drives, I don't think we should worry on doubling up on frameworks that much. If people don't keep many versions of NB/NP, and the data is inside the app, everything should be sweet. It seems to be the way of Mac OS X anyways (filesize-wise)

Currently Playing:
Celeste and Electronic Super Joy

20

Re: Mac OS X Port (for 1.6)

I don't think we should keep SDL files in the repo. Especially given that it's like a two line change in a 400 lines long file. It should definitely be documented, though, and that file can be kept in the repo.

21 (edited by jammnrose 2012-10-21 13:34:28)

Re: Mac OS X Port (for 1.6)

Sounds good parasti.

And what of the file size? Can anyone else weigh in here? Do we duplicate some files and keep things extremely clean? Doing this does remove the need for an installer and uninstaller, and prevents having to do all the symlink stuff. We'd probably get decent DMG compression too...

EDIT: Leaning towards this myself...

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

22 (edited by jammnrose 2012-10-24 05:09:23)

Re: Mac OS X Port (for 1.6)

Over the past weekend I upgraded to 10.8 Mountain Lion.
I'm happy to report that using Xcode 4.5.1 and a Base SDK of 10.7 with 10.6 as the OS X Deployment Target, everything seems to be running fine on my 10.6 Snow Leopard machine. (Fresh install of all the required ports had no issues, save for the custom libpng 1.2.50 as before.)

I was worried that using a later SDK would break the build, so I guess I'm not sure what using a particular SDK does... I would have to read up on it a bit more. I would guess that older code is deprecated and so no longer usable. In our case, we weren't using anything too old (that's Mac specific?) I guess... But it's good it still allows you to deploy to earlier targets.
We could try testing with 10.4 and 10.5 I guess, but I'm not sure it's worth it. I'm fairly certain I can't get libs that work on PPC anymore (I'd have to look into it). I know they were a pain.

The other thing I managed to do was modify the SDLMain.m file, specifically this bit:
Original:

/* Set the working directory to the .app's parent directory */
- (void) setupWorkingDirectory:(BOOL)shouldChdir
{
    if (shouldChdir)
    {
        char parentdir[MAXPATHLEN];
        CFURLRef url = CFBundleCopyBundleURL(CFBundleGetMainBundle());
        CFURLRef url2 = CFURLCreateCopyDeletingLastPathComponent(0, url);
        if (CFURLGetFileSystemRepresentation(url2, 1, (UInt8 *)parentdir, MAXPATHLEN)) {
            chdir(parentdir);   /* chdir to the binary app's parent */
        }
        CFRelease(url);
        CFRelease(url2);
    }
}

Edited

/* Set the working directory to the .app's Resources directory */
- (void) setupWorkingDirectory:(BOOL)shouldChdir
{
    if (shouldChdir)
    {
        char bundledir[MAXPATHLEN];
        CFURLRef url = CFBundleCopyResourcesDirectoryURL(CFBundleGetMainBundle());
        if (CFURLGetFileSystemRepresentation(url, 1, (UInt8 *)bundledir, MAXPATHLEN)) {
            chdir(bundledir);   /* chdir to the binary app's Resources directory */
        }
        CFRelease(url);
    }
}

The key piece here was "CFBundleCopyResourcesDirectoryURL(CFBundleGetMainBundle());"
That's basically a bit of magic that gets the "Neverball.app/Contents/Resources/." directory.
I haven't managed to run Neverball in a way that would cause a misconfiguration resulting in it not being able to find the "data" folder (I've intentionally tried), so I'm reasonably sure this always results in the working directory being the Resources directory.

The awesome takeaway from this, is that I no longer have to set the "-DCONFIG_LOCALE" and "-DCONFIG_DATA" C Flags! Heck yeah! It simplified a lot of stuff in the Xcode project.

With us now duplicating frameworks, locale, and data, the two applications are around 220MB in size.
Zip compression gets us to ~65-70mb (I expect similar from DMG compression).
I'm going to test a few things out to remove some duplicate data, such as only copying ball resources to the Neverball data folder, and only copying putt resources to the Neverputt data folder.

Does it sound reasonable to go about copying only the game specific data to the respective data folders by reading the course and set TXT files with some BASH script that I hack together?

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

23

Re: Mac OS X Port (for 1.6)

<!-- stupid joke in 3,2,1... -->

@jammnrose, did you try..

CURFUFFLEref url = CFCrumbleMumbleCopyBubbleHubbleRubberBabyBuggyBumper(MumbelBumbleGetMyBundle());

<!-- END STUPID JOKE -->

24 (edited by jammnrose 2012-10-26 00:53:05)

Re: Mac OS X Port (for 1.6)

ROFL big_smile

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.

25

Re: Mac OS X Port (for 1.6)

In my quest to make the best Mac package I have a few questions:

* How does gettext work? I've tried setting my system language to French, but Neverball didn't change... I do know that Mac OS X does localizations their own way, but I'm not sure how we can use that to our advantage to automatically switch to the right .mo file. It's something I may look into more.

* It looks like the compiled .sol file is all the games need to run, do we still want to bundle the .map files? I can see the reasoning behind it, but thought I'd ask. (I think it could reduce our filesize.)


If there aren't any objections, as I mentioned in my previous posting, I'm going to make build/bash scripts to strip putt stuff from the Neverball.app data folder and vice-versa. This includes levels, shots, and maybe some other things like the custom balls... Not quite sure how to suss out the dependencies of Neverball and Neverputt independently. Maps and shots are easy enough though.

I also must have made a small error in my calculations before, because now the two apps (zipped, everything duplicated) are 122MB. Some rudimentary manual removal of putt stuff from Neverball and vice-versa resulted in a zip file around 82MB, so definitely some good gains, and I will most certainly want to do this, as I said, unless there are objections (I will take no response as no objection).

Mac OS X Xcode project & package maintainer.

If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.