It's running smoothly on Mac, will try and have a neat version including only one copy of chakra as dylib (rather than 3) ready shortly. (miniSphere + SpheRun + cell all statically linked to Chakra = ~50mb which seems a little excessive)

miniSphere 5 beta for macOS Sierra
miniSphere 5 beta for macOS Sierra, including miniSphere, sphereRun, Cell and SSj:
edit: snip, now on downloads drive, see link in Fat Cerberus' post below

Be warned this is not fully tested in particular SSj with chakra has not been tested on macOS.
Also note the component apps will not work if moved into different folders to each other (this is because the ChakraCore dylib used by cell and sphereRun is hidden inside miniSphere.app )
Any comments or questions or other feedback please let me know.

I put it on the Downloads drive: https://drive.google.com/drive/folders/0Bw-4UFVty4u1fjJ2RHNUTFNzMVp1WEFVOHlJaFk4STJPd1RMVmFLeGtDQWQ5SVlSSXhEWFk

Since ES6 modules will be natively supported in miniSphere 5.0, I'm going to deprecate require().  It will remain available for legacy compatibility with modules written for Node, but is otherwise no longer recommended for use in Sphere code.  import and export are much more elegant and will be the preferred mechanism for linking together scripts going forward.

Speaking of legacy compatibility, I recently added a new API, FS.evaluateScript(), which allows loading old-fashioned JS scripts.  I realized I was using RequireScript() a lot to load stuff like Aurora.js, which is awkward in an otherwise fully Sphere v2 codebase especially since all the v1 functions are technically deprecated...

miniSphere 5.0b2 and 4.8.8 are up.  Unlike the first beta, 5.0b2 has breaking API changes, so be sure to read the documentation to get up to speed.

I'm not sure if this is a bug with ChakraCore or miniSphere, but I noticed an issue with miniSphere pointing to the wrong line number when an error is thrown

Code: (js) [Select]

// md = blah blah blah (unimportant)
md.bodyB = body; // line 47
md.target.Set(mouseX, mouseY); // line 48

But I'm getting this error:

Code: [Select]

ReferenceError: 'mouseX' is not defined
   at Anonymous function (src/main.mjs:47:4)

The backtrace is generated by Chakra (it's taken from error.stack) so I guess it's either a bug, or else the line numbers are zero-based.

It's looking like I'm going to have to rewrite the module loader in order to support import(): the module loading API in Chakra is async, in other words they expect you to do module loading in the event loop rather than inline.  For static imports I could hack around that by just parsing all the dependent modules in a loop; for dynamic imports that's not possible because import() returns a promise and doesn't call your import callback until some time later.

This might be a dumb question, but is there any way to force windowed mode to not start at 2x scale? It will help a lot with GIF recording.

It will help a lot with GIF recording.

Really weird use case for a game engine

The only way right now is to set the game's resolution high enough so it doesn't need to scale up.  I hardcoded the scaling for low resolutions because otherwise e.g. 320x240 is way too small at modern screen resolutions to play comfortably.

My game is at 640x360, which I just found out is exactly on the edge for 2x.
640x361 works well for recording a gif to showoff new menu.

My game is at 640x360, which I just found out is exactly on the edge for 2x.
640x361 works well for recording a gif to showoff new menu.

Try 960x540, it's a pretty standard base for resolution

Beta 3 is on the way, just one glitch with import() I want to work out first.  I've made even more optimizations since Beta 2 and native API call performance now surpasses that of mS 4.8.  Lots of other internal optimizations too, the engine should be faster and less CPU-hungry overall.

miniSphere 5.0b3 has just gone up, with the following enhancements over Beta 2:

• Dynamic module import (import() operator)
• Console is now a class instead of a singleton
• Sphere Runtime refactoring
• API refinements
• Lots more under-the-hood performance improvements!
• Tons of minor bug fixes

I also changed the Random module back to the way it was prior to 5.0b2.  I had made it into a subclass of RNG but that made it excessively complex considering it was meant as a convenience module for when you don't actually need all the power of RNG.

I'm starting to put the finishing touches on miniSphere 5.0.  I'm not sure yet if there will be a 5.0b4 or if I'll go right to release-candidate stage for the next update.  I guess it depends how many bugs are reported in the meantime!

There is that crash on shutdown that @Rhuan keeps hitting, haven't been able to reproduce it yet...