Okay, so just to be sure I understand this correctly (so I can implement it cleanly):

• There's a folder called, say minisphere.app, which contains all the files needed to run the engine.


• Finder (and the OS in general) treats this as a self-contained executable, but it's really a folder.


• The actual engine executable is minisphere.app/Contents/MacOS/minisphere


• Bundled non-executable files go into minisphere.app/Contents/Resources/.


• Therefore, to get to the directory containing minisphere.app, one has to go three levels up (../../../) from either location.


• None of the above applies to a Unix-style executable, which works the same as it does in Linux.

Do I have that right?  If so it shouldn't be too hard to come up with a less hacky solution.  I really need to invest in a Macbook...

Okay, I renamed enginepath() to asset_path(), and added a new engine_path() function to enable better future support for OS X:
https://github.com/fatcerberus/minisphere/blob/master/src/engine/utility.c#L35-L44

Note the if (false) - the path hack is disabled for now because I can't figure out how to find out, at runtime, if the app is bundled or not.  That's why I didn't want to incorporate the change as-is: It'd be hardcoded.  I'd rather detect it at runtime if possible, so that one can choose to either bundle the engine or not (for a developer setup, the Unix style is probably better).

I'm glad to have a Mac developer on board by the way; it's the only one of the three major platforms I don't support--simply because I don't have the hardware to do so!

You're mostly right on the above - one point to note is if you use a unix style executable in MacOS opening it makes the command line open (which a casual MacOS user would not be used to - it's generally a lot less common than seeing a DOS box in windows)

I can't see much benefit to using a unix executable on a Mac; the only features it has that an app bundle doesn't have are:
a) you see the outputs of printfs - so it's useful for debugging the engine itself (if you open an app bundle printfs output to nowhere)
b) you can run it from the command line and potentially pass parameters to it (though you can do this with the bundle too you'd just have to step up 3 levels to do it - to the command line the .app is nothing but a folder)

When you compile an application with xcode (the apple equivalent of MVS) it automatically builds the bundle for you - so if compiling with xcode you're making a bundle (unless you do som extra steps to reverse it) - I think the most pragmatic solution to allow both methods would be to add a custom compiler flag e.g. macos_bundle or something.

The only way I can think of to detect the bundle at run time would be to find the path to the engine then compare it against what it would be if you were in a bundle with string operations this seems a bit tedious to me.

I'm not sure I really count as a mac developer - I taught myself how to use mac developer tools about 10 years ago so I could port the original sphere to mac then I got back into it two weeks ago to port minisphere...

Right, that's why I said the Unix style is better for development - spherun, for example, can be told from the command line to enable some pretty heavy logging using the --verbose <1-4> command-line option (console.log() also prints to the terminal when using spherun).  And of course you have Cell, SSJ and eventually Majin, all of which are command-line tools.  Sphere pretty much has its own toolchain these days thanks to me.  Gone are the days when the engine was just a toy - I'll make it a serious development platform if it's the last thing I do

Your limited Mac development experience should be enough I think - the point is that you know a bit of how the platform is organized which you can use to help solve some of the portability issues I'm not aware of (like this one).

One other minor point... The icon that comes in the source tree is too low a resolution for macosx it ends up looking blurry - I also tried the one from the top corner ofthe forums but again it's too low a resolution - the suggested image size for an icon on macosx is 1024*1024 - somewhat ridiculously as it's very rare to see it that large, but it could do with being at least 512*512. Do we have a version of the icon that size anywhere?

The .ico that's in msvs/ is a Win10 icon, i.e. 768x768.  I believe the .svg is also there so you could export any size you wanted.  In fact I'll do that in a bit, it'll be quick.

The .ico that's in msvs/ is a Win10 icon, i.e. 768x768.  I believe the .svg is also there so you could export any size you wanted.  In fact I'll do that in a bit, it'll be quick.

I was using the png from the system folder I can't see a .ico and the .svg I can see appears to be 100*100 I'm probably looking in the wrong place.

SVG is scalable.  The nominal resolution is 100x100 but with the proper tools you can scale it up to any resolution.  I used CloudConvert to do it, here's a 1024x1024 PNG, download below.

The .ico is located at msvs/spherical.ico in the Git repository by the way.

Great thanks - no longer have a blurry icon

I now do macOS builds for most releases of miniSphere which are posted in the main miniSphere topic so closing this.