Quick update: minisphere 4.3.1 adds an engine-provided frame loop that runs as long as there are active Dispatch jobs.  While seemingly a small change, this represents a fairly large paradigm shift.  Instead of this:

Code: (javascript) [Select]

while (system.run()) {
    // render stuff here
    screen.flip();
    // update stuff here
}

The idiomatic Sphere v2 way to write a game is now:

Code: (javascript) [Select]

Dispatch.onUpdate(doUpdate);
Dispatch.onRender(doRender);

function doUpdate()
{
    // update stuff here
}

function doRender()
{
    // render stuff here
}

It's a bit more complicated, but effectively paves the way for cross-compatibility with Oozaru.  And if you're only targeting minisphere, then you can still use the classic method.

Would the Exit() and Abort() functions cancel all jobs currently dispatched? Or would I have to cancel each job through Dispatch.cancel(job)? Is there a way to cancel all jobs (like Dispatch.cancelAllJobs()), and would that exit the engine right away or would you still have a brief moment to dispatch a whole new job right after that?

The engine won't quit until you return from the main script, same as Sphere 1.x.  It's just that if there ARE active jobs at that time (including one-time jobs), it will run a gameloop until they have all finished running.

There's nothing to cancel all jobs right now, you'd have to cancel them individually.  That said, system.exit() and system.abort() (and indeed, as you point out, the Sphere v1 equivalents) still work as before and close the engine immediately.

Damn, I wish I had caught this this morning.  There's a minor glitch in the current release: Dispatch jobs will continue to be processed even after an uncaught exception, possibly rendering over the error screen (I'm not really sure what would happen if another error is thrown at this point, probably a crash).  All jobs should have been canceled in that case, but due to the oversight they aren't.  I fixed it already in the latest build, but I don't think it's pressing enough to warrant a hotfix.

edit: Hm, it seems the engine will crash if an error is thrown in an update or render call dispatched from the main event loop.  So that's something else to fix, but also not a big deal (if you don't catch an error you were going to terminate anyway, it's just that normally that wouldn't cause an outright crash).  It looks like I'll need to go through and test a few different scenarios to make sure all the edge cases are covered.  Expect a 4.3.2 release in a few days with Dispatch API fixes.  For the time being everything is completely usable, there just might be some landmines involved.

Just released minisphere 4.3.2 with a bunch of fixes.  The crashes mentioned above are fixed, and the new project template has been greatly improved.  Notably, this version also improves priority handling for Dispatch.onUpdate(): Jobs with higher priority are now executed first.  Renders are still processed low->high of course.

Something that I didn't notice until now for some reason, in Sphere 1.x, if Abort() was called (whether via script error or called from a script) and the game had been loaded from a startup game, Sphere went back to the startup game, but this isn't done in minisphere. Also, if I press Alt-Enter from the startup game to toggle window view (when not set in the command line), when the game loads it goes back to fullscreen.

Thanks for the heads-up on Abort(), the bug is here:
https://github.com/fatcerberus/minisphere/blob/master/src/engine/main.c#L768

I call exit() after displaying the error screen.  It should call `exit_game(false)` instead, which it would if I just remove the exit().  Not sure why I put that there, I'll fix it for 4.3.3.

I'll look into the full screen issue later too, that sounds like a bug since it's not the intended behavior.

Tip: Abort() doesn't actually abort unconditionally but rather throws a catchable exception (Sphere games historically didn't use try/catch that much).  If you want an unconditional error, call Sphere v2 system.abort() instead.

Oh, alright. Also, why was fs changed to FS?

Oh, alright. Also, why was fs changed to FS?

The release notes for 4.3 explain this.  Mostly it was done to match other JS namespaces like Math and Reflect.  It's not really an object representing the file system so much as "the place where file system functions live."  So it gets an uppercase name.  A concrete global "this is the file system" variable only really makes sense if the engine supports multiple independent file systems, which doesn't seem like something we need in Sphere.

screen on the other hand was left lowercase because it's an actual Surface object, just one that happens to represent the backbuffer.  It's not a namespace but a true object in the OOP sense.  The alternative is to call it Surface.Screen for consistency with Mixer.Default etc. but that's a bit verbose for an object that will be referenced all the time.

tl;dr: API consistency concerns.

Hm, it turns out I was wrong about Abort()'s behavior: In Sphere 1.5 it actually is an unconditional error; wrapping it in a try/catch has no effect.  minisphere currently implements it as a throw which is incompatible, so I'll have to fix that.

@Eggbert: The two bugs you found, along with the incorrect Abort() throwing behavior, are fixed in git and will be in the 4.3.3 release.  I'll hold off on that release for a bit longer in case you find more glitches.

Oh, alright. Also, why was fs changed to FS?

The release notes for 4.3 explain this.  Mostly it was done to match other JS namespaces like Math and Reflect.  It's not really an object representing the file system so much as "the place where file system functions live."  So it gets an uppercase name.  A concrete global "this is the file system" variable only really makes sense if the engine supports multiple independent file systems, which doesn't seem like something we need in Sphere.

screen on the other hand was left lowercase because it's an actual Surface object, just one that happens to represent the backbuffer.  It's not a namespace but a true object in the OOP sense.  The alternative is to call it Surface.Screen for consistency with Mixer.Default etc. but that's a bit verbose for an object that will be referenced all the time.

tl;dr: API consistency concerns.

What about system then?

It has properties (engine name, version, etc.), so I treat it as a real object representing the engine.  In fact it originally was called "engine" a while ago, don't remember why I changed it.  It is kind of a gray area though, unlike screen.

I decided to release minisphere 4.3.3 now since it adds a few useful features: Object.assign(), and a new "test" module based on http://wiki.commonjs.org/wiki/Unit_Testing/1.0

The test module is used for automating unit tests.  You call test.run() with object full of functions called "testWhatever" and it runs them all for you:

Code: (javascript) [Select]

const assert = require('assert');
const test   = require('test');

test.run({
    testFatburner: function() {
        var scott = existence.find("Scott Starcross");
        var maggie = existence.find("maggie");
        var fatburner = existence.find("Holy Blade Fatburner");
        scott.equipWeapon(fatburner);
        scott.attack(maggie);
        assert.ok(maggie.deceased);
    },

    testMunch: function() {
        var scott = existence.find("Scott Starcross");
        var maggie = existence.find("maggie");
        maggie.munch(scott);
        assert.ok(!existence.has(scott));
    }
});

Ah, that explains the Link query from the other post. Nice work!