Spherical forums

Sphere Development => Engine Development => Topic started by: Rhuan on December 27, 2016, 08:40:39 am

Title: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 08:40:39 am
So as some of you will be aware after a long absence I have returned.

I've built miniSphere 4.3.8 for MacOS Sierra. I've uploaded it to my google drive if anyone would like to test it: https://drive.google.com/open?id=0BxPwycggYMWlV2ZTR2ZyVF9hSnM

Notes:
1. I've included the license.txt that came with the miniSphere source I haven't checked this is right in light of all the dependencies etc if I've got this wrong and broken any rules please forgive me; this link is a temporary version for testing purposes I'll double check license texts etc later.
2. This is a test version it's the first programme I've compiled in at least a year, it works for me.... (It's meant to be statically linked and 100% self contained but I've had no way of testing that yet)
3. Known issues:
a) drawZoomedText doesn't work properly - it doesn't crash but it creates graphical anomalies on screen
b) it can't play mp3s (but this is apparently a wider miniSphere point)
4. Development notes; I made two changes to the source to make it work:
i). in utility.c starting from line 17 I inserted:
//macosx specific code - step back 3 levels from the unix executable to the OSX wrapper
#ifdef __APPLE__
al_drop_path_tail(al_path);
al_drop_path_tail(al_path);
al_drop_path_tail(al_path);
#endif

ii) in dyad.c I changed the function panic to d_panic and renamed each time it was called - this was to avoid a clash with a function used by a Mac dependency of one of the dependencies
5. If anyone is interested I've got an xcode project I can share which was used to build this.

Sphere editor I'm not going to try and port an editor at the moment - I like the old sphere editor which runs comfortably on wine if you dump a copy of mfc42.dll into its folder (thanks to DaVince for telling me that's what I needed).

Original Sphere/Sphere 1.5/1.6: The download link for Sphere 1.6 for mac on the google drive - which is a compile I made some years ago will not run on modern Macs I had a quick look over it and it is leaning on a stack of deprecated system functions - I think fixing it would be a large project even if I could find the original xcode project (and I'm not sure I would be able to - the computer I used for that stuff is somewhat broken) - seeing as miniSphere works pretty well I think any development effort should focus on that.

I note also that the windows version of Sphere 1.5 runs ok under wine so this is also an option - it can run Aquatis for instance.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 11:01:08 am
Fat Cerberus: have you got any thoughts on the points above, particularly notes 3 and 4?
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 11:02:40 am
Note that Aquatis is almost fully functional in minisphere if one transcodes the .mp3 files to, say, Ogg Vorbis.  That game was one of my first compatibility targets during early development. :)

I should also note that minisphere runs Kefka's Revenge - which if you've ever seen the code for it, is quite an accomplishment.  There's really very little reason to use Sphere 1.x these days since minisphere is 99% compatible.  The only real stumbling block for compatibility is the missing MP3 support.
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 11:21:18 am
Regarding the license, it's a BSD 3-clause, so you can pretty much do whatever you want with it.  The only real requirement is that you include the license text.

That OS X path hack would be easy to incorporate, but note that it's not correct for a Unix build, and it's my understanding that OS X also supports Unix-style apps, without any wrapper.  So I don't think #ifdef __APPLE__ is the right check here?  And I'm not sure what's going on with drawZoomedText().  That worked properly when I implemented it in minisphere 1.0, but I don't think I've tested it since then, so it's very possible there's a regression.  I'll look into it.

The dyad.c fix I can make in the official build.  Dyad isn't my library, but it's MIT licensed so making in-house edits is fine.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 11:31:21 am
On the path hack; you can use a unix executable with no wrapper on OSX but it's seriously discouraged and normally makes your command line prompt open when you open them - this isn't behaviour that an "average " (i.e. non-developer) OSX user would expect or understand. The pathhack is obviously not wanted for any non-Mac build; we could use a different #ifdef, I put in that one as it's one of the standard ones you always have when building on a Mac so I didn't have to add any extra compiler flags.

(I just tested kefka's revenge on my miniSphere build the start of it runs, the walk speed is super slow and then I got stuck inside a wall and couldn't move but I assume that's a problem in the game not the engine)
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 12:09:54 pm
KR is incredibly buggy (not to mention horribly coded), so I wouldn't doubt you hit a glitch in the game itself. :)
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 01:10:04 pm
Interestingly enough, that path hack shouldn't actually be necessary.  I use ALLEGRO_RESOURCES_PATH to locate the system directory, which is documented as follows in the Allegro API:
https://www.allegro.cc/manual/5/al_get_standard_path

Quote
If ran from an OS X app bundle, then this will point to the internal resource directory (<bundle.app>/Contents/Resources). To maintain consistency, if you put your resources into a directory called "data" beneath the executable on some other platform (like Windows), then you should also create a directory called "data" under the OS X app bundle's resource folder.


So I assume there's a bug in Allegro, where their logic to detect OS X app bundles doesn't work on Sierra.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 01:22:03 pm

Interestingly enough, that path hack shouldn't actually be necessary.  I use ALLEGRO_RESOURCES_PATH to locate the system directory, which is documented as follows in the Allegro API:
https://www.allegro.cc/manual/5/al_get_standard_path

Quote
If ran from an OS X app bundle, then this will point to the internal resource directory (<bundle.app>/Contents/Resources). To maintain consistency, if you put your resources into a directory called "data" beneath the executable on some other platform (like Windows), then you should also create a directory called "data" under the OS X app bundle's resource folder.


So I assume there's a bug in Allegro, where their logic to detect OS X app bundles doesn't work on Sierra.
Even if it did point to bundle.app/contents/resources this wouldn't work for sphere as again that is a hidden folder inside the application bundle - it's an ok place for resources that come with the application as long as a user is never intended to edit them - it won't work for a sphere game folder for instance.
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 01:29:10 pm

Even if it did point to bundle.app/contents/resources this wouldn't work or sphere as again that is a hidden folder inside the application bundle - it's an ok place for resources that come with the application as long as a user is never intended to edit them - it won't work for a sphere game folder for instance.


It would work for a Sphere v2 game.  With SphereFS if you use a path like ~/MyGame/savefile.dat, that gets stored in a subdirectory of the user's home folder rather than relative to the game folder.  For new games the game folder should be considered read-only for exactly the reason you mention.

SphereFS paths are as follows:


Note that SphereFS only applies to the new APIs - legacy stuff like LoadImage() uses the Sphere 1.5 semantics for compatibility.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 01:55:55 pm
From my read of the source the point was that except for the home directory path all paths were defined with reference to the executable and hence for MacOS require the path hack unless we wish to make these be hidden folders.

I personally don't like the idea of using the home directory/documents path as it could force a user to install Sphere in a specific place which could be problematic in some instances - though the home directory finding feature should work fine with no path hack.
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 03:12:30 pm

I personally don't like the idea of using the home directory/documents path as it could force a user to install Sphere in a specific place which could be problematic in some instances - though the home directory finding feature should work fine with no path hack.


I don't follow - home directory (Unix convention ~/) is always the same for a given user regardless of where the executable requesting it is?

The system directory is not really meant to be user-accessible - for all intents and purposes it's part of the engine.  So it doesn't matter if it's in a hidden folder.  Sphere v2 @/ is relative to game.sgm (or game.json) and so that also doesn't care where the engine is either.

Keep in mind that the "minisphere" executable will prompt the user for a game if none is found - so it's not strictly necessary to bundle your game with the engine package.  For the startup game, minisphere will also search for games stored in ~/Documents/minisphere/games, by the way.
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 03:18:04 pm
To clarify, enginepath() is called for two reasons: To find the "system" directory alongside the engine, and to find the directory for bundled games (well, one of them).  For that latter case, the path hack is indeed needed at least for Sphere v1 games, but there might be a cleaner way to implement it.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 03:19:56 pm
Ok to clarify we could remove the path hack if:
a) we don't mind hiding the system folder - this would be ok as you've noted above
b) we don't mind breaking the startup game (as it would now point to a hidden games folder) - correct me if I'm wrong


My point on the home directory was a separate note - I don't like the idea of requiring anything to be installed in a specific place - if we use paths that start from the home directory someone else running the game is forced to put files in a specific folder; what if they want to download and run it from their desktop or their downloads folder or... (I like to make things as close to double click and go for a theoretical end user as I can)
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 27, 2016, 03:37:02 pm
The home directory is only meant to be used for save files--the game itself can be stored anywhere, but the recommendation for new code is to treat the game folder as read-only and store save data in ~/.  I don't mean for that to be used for game assets (except in the case that the startup game finds them there, of course).

The startup game does require the path hack if you want to bundle games with the engine without hiding them from the user, that's true.  All I meant was that I don't think enginepath() is the right place to implement it--I'd prefer to refactor if possible.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 27, 2016, 04:55:25 pm

The home directory is only meant to be used for save files--the game itself can be stored anywhere, but the recommendation for new code is to treat the game folder as read-only and store save data in ~/.  I don't mean for that to be used for game assets (except in the case that the startup game finds them there, of course).

The startup game does require the path hack if you want to bundle games with the engine without hiding them from the user, that's true.  All I meant was that I don't think enginepath() is the right place to implement it--I'd prefer to refactor if possible.
Obviously it's your codebase not mine - enginepath() just seemed the most logical/simplest place to put it to me.
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 28, 2016, 12:30:24 am
Okay, so just to be sure I understand this correctly (so I can implement it cleanly):



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...
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 28, 2016, 02:08:42 am
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!
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 28, 2016, 06:09:04 am
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...
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 28, 2016, 06:34:52 am
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).
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 28, 2016, 07:42:14 am
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?
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 28, 2016, 10:06:59 am
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.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 28, 2016, 10:44:28 am

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.
Title: Re: miniSphere for Mac (with link)
Post by: Fat Cerberus on December 28, 2016, 11:08:06 am
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.
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on December 28, 2016, 11:13:11 am
Great thanks - no longer have a blurry icon :)
Title: Re: miniSphere for Mac (with link)
Post by: Rhuan on February 26, 2018, 04:18:33 pm
I now do macOS builds for most releases of miniSphere which are posted in the main miniSphere topic so closing this.