Skip to main content

News

Topic: miniSphere for Mac (with link) (Read 10475 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Rhuan
  • [*][*][*][*]
miniSphere for Mac (with link)
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.
  • Last Edit: December 27, 2016, 11:10:24 am by Rhuan

  • Rhuan
  • [*][*][*][*]
Re: miniSphere for Mac (with link)
Reply #1
Fat Cerberus: have you got any thoughts on the points above, particularly notes 3 and 4?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #2
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #3
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere for Mac (with link)
Reply #4
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)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #5
KR is incredibly buggy (not to mention horribly coded), so I wouldn't doubt you hit a glitch in the game itself. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #6
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere for Mac (with link)
Reply #7

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.
  • Last Edit: December 27, 2016, 01:50:43 pm by Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #8

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:

  • @/path/to/file or path/to/file - Relative to game directory (for best results, treat as read-only)

  • ~/path/to/file - Usually relative to <user home>/Documents/minisphere

  • #/path/to/file - Relative to system directory (again, treat as read-only)


Note that SphereFS only applies to the new APIs - legacy stuff like LoadImage() uses the Sphere 1.5 semantics for compatibility.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere for Mac (with link)
Reply #9
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.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #10

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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #11
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere for Mac (with link)
Reply #12
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)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere for Mac (with link)
Reply #13
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere for Mac (with link)
Reply #14

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.