GetGameList() actually uses engine_path(), which has the path-hack already implemented, it's just "if (false)"'d out because I didn't know how to detect whether the engine is bundled or not without having to resort to writing ObjC code.  Going three steps uplevel breaks everything in anything other than a bundled OSX app

GetGameList() actually uses engine_path(), which has the path-hack already implemented, it's just "if (false)"'d out because I didn't know how to detect whether the engine is bundled or not without having to resort to writing ObjC code.  Going three steps uplevel breaks everything in anything other than a bundled OSX app

Check line 1872 of vanilla.c (ExecuteGame function) that uses assets path for the games directory, so may need to change that.

The startup game is also looked for inside assets_path so would need to hide that away as well as the system folder.

On the bundle detection point:
- We don't need to detect a bundle at run time - you make the pick when you make your xcode Target (effectively a makefile) people aren't normally going to take the executable out of a bundle at a later point and shouldn't expect it to work if they do - if you do that to any other mac application it normally fails to open.
- seems to me that the correct condition is something like this:
#if defined __apple__ && !defined MINISPHERE_SPHERUN

On a different note sphererun is working nicely, just had to make a new xcode target and a tweak a few settings. I guess I should build ssj next?

I assume __apple__ is not defined for a unix-style app?  If that's the case, that would work perfectly.

I assume __apple__ is not defined for a unix-style app?  If that's the case, that would work perfectly.

No __apple__ is defined for a unix style app it is defined for anything you build to run on a mac BUT you wouldn't make the release version as a unix style app; nothing intended for a "normal" end user is built as a unix style app it's just not done hence my suggesiton of the two conditions 1. __apple__ and 2. not MINISPHERE_SPHERUN

Unrelated point can't get SSJ to run, assume I've messed something up building it:
Sphererun output:
waiting for connection from debug client...
connected to debug client at 127.0.0.1
Abort trap: 6

SSJ output:
./ssj -a
SSJ 4.6.0 Sphere JavaScript debugger (x64)
a symbolic JavaScript debugger for miniSphere
(c) 2015-2017 Fat Cerberus

connecting to 127.0.0.1:1208... OK.
verifying... error!

Hmm, what happens if you do "ssj game_dir" on the command line (ssj and spherun must be built in same directory)?

Google indicates abort trap 6 is a segfault, so I'm assuming some initialization is failing for whatever reason and the engine does a null pointer access.  Could you maybe run spherun under the Xcode debugger and then attach SSJ from the command line to see where it crashes?

Just implemented basic support for setting projection matrices:
https://github.com/fatcerberus/minisphere/commit/590d68a2176acbf60921e800d302ec08aba07e98

Currently projection is only supported for things drawn to the screen, but I'd like to implement it for surfaces as well.  First I need to work out the API for project3D(), though.  Right now it works like glFrustum() which makes it more flexible, but maybe a bit too advanced for beginners.

Google indicates abort trap 6 is a segfault, so I'm assuming some initialization is failing for whatever reason and the engine does a null pointer access.  Could you maybe run spherun under the Xcode debugger and then attach SSJ from the command line to see where it crashes?

Trying that and doesn't get me anything useful, running through the xcode debugger instead of aborting sphererun just hangs, no error, but nothing happening either, I'll have to put in some extra printfs or something to try and track it through, may be able to do that later today, not sure.

By the way if you decide you want to try building Cell at some point in the future, you can compile Spectacles with it as a test:
https://github.com/fatcerberus/spectacles-i

kh2Bar works too:
https://github.com/fatcerberus/kh2bar

My plan was to build all of the components of miniSphere for 4.6 then do a Mac release of sorts but seems that only the main app is working correctly at the moment.

Will look at it more later today or tomorrow.

I really got to begin making time for my game... sigh. Anyways, thanks F.C. for continuing support.

I was missing how the xcode debugger works, it was giving me an output, not sure how useful it is, the function where it's falling over is duk_debugger_detach with the following dump:

sphereRun`duk_debugger_detach:
    0x1000062fa <+0>:  pushq  %rbp
    0x1000062fb <+1>:  movq   %rsp, %rbp
    0x1000062fe <+4>:  leaq   0x2504dd(%rip), %rsi      ; "duk_api_debug.c"
    0x100006305 <+11>: leaq   0x2504e6(%rip), %rcx      ; "no debugger support"
    0x10000630c <+18>: movl   $0x60000f2, %edx          ; imm = 0x60000F2
    0x100006311 <+23>: callq  0x100002a8c               ; duk_err_handle_error at duk_error_macros.c:21

That IS useful.  Duktape looks to be throwing a "no debugger support" error when miniSphere attempts to attach the debugger.  This indicates you might have compiled spherun without defining MINISPHERE_SPHERUN which causes the other options not to be set properly for a debugger-enabled build.

That IS useful.  Duktape looks to be throwing a "no debugger support" error when miniSphere attempts to attach the debugger.  This indicates you might have compiled spherun without defining MINISPHERE_SPHERUN which causes the other options not to be set properly for a debugger-enabled build.

I definitely compiled with MINISPHERE_SPHERUN set, and have just triple checked this.

OH!  You also have to set DUK_OPT_HAVE_CUSTOM_H I think.  I've made that mistake before, too (you'll want to define that for the normal build too or glitches may happen)