Sphere.exit() turned out to be problematic as it was implemented using a longjmp and apparently Allegro didn't like that, causing a crash on exit.  So I replaced it with Sphere.shutDown() which simply instructs the event loop to exit, similarly to how ExitMapEngine() works in Sphere 1.x.

I also brought back the Pact class!  With async/await and the event loop taking center stage in miniSphere 5.0, I figured there should be an easy way in the API to fulfill or reject promises out-of-band.  With Pact, as long as you hold a reference to both the promise and the pact it was made from, you can settle the promise at any time.  It's very intuitive and doesn't require understanding closures.

Sphere.exit() turned out to be problematic as it was implemented using a longjmp and apparently Allegro didn't like that, causing a crash on exit.  So I replaced it with Sphere.shutDown() which simply instructs the event loop to exit, similarly to how ExitMapEngine() works in Sphere 1.x.

I understand changing the code to make it function, but why did you also change the method name? Sphere.exit() is nice and obvious.

I also gotta say, by the way - nice work on all of this!

"exit" implies that the method is immediate (which it was), "shutdown" tells the reader that there's a process to it all.  Just as you can either press the power button to forcibly turn off the computer or click "shut down" which will cleanly shut down the OS but has rules to it (open processes must close first, busy apps can block it, etc.)  Subtle difference, but very important from an API design standpoint.  It's the same reason I renamed FileStream#size to fileSize: I want the API to be as intuitive and self-describing as possible to a person reading the code as it will be to the person writing it.

Well, I asked exactly because exit() is very self-explanatory as well, and just something I've seen around more in software I guess. But your explanation makes a lot of sense; I'm just going to have to remember the change if I ever use the function.

API design is a very subtle art and it's been my experience that method naming isn't always just about the immediate effect of a method.  Consider the difference between:

Code: (javascript) [Select]

Sphere.exit();
Dispatch.onUpdate(doStuff);

Versus:

Code: (javascript) [Select]

Sphere.shutDown()
Dispatch.onUpdate(doStuff);

One might reasonably expect the former to close the engine regardless of what comes after.  It wouldn't, because the new job added to Dispatch keeps the event loop alive.  "But I explicitly said to exit, what's going on?!"  Whereas, if one looks at the latter code, it's requested a shutdown, but then added a new process afterwards which effectively cancels the request (you can't shut down if there are active processes).  It makes more sense intuitively that a request to "shut down" would be canceled (since an OS shutdown can do this too), canceling an "exit" (which sounds atomic) seems nonsensical.

Consider the documentation for ExitMapEngine(), where the note laying out the caveat is significantly longer than the description of the API:
https://github.com/sphere-group/sphere/blob/master/sphere/docs/development/api.txt#L495-L499

And that note is *STILL* vague--what exactly causes MapEngine to return if not the exit call itself?  I know the answer to that because I'm familiar with the Sphere 1.x source code and know that it's single-threaded.  But to the uninitiated it's not nearly as obvious.  For example if you start a FlipScreen loop in an update script that will block the exit despite performing other event loop-y operations.  Which is why the miniSphere documentation is much more explicit about it:
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-core-api.txt#L236-L240

Control MUST return to the engine (i.e. ongoing JavaScript operations must run to completion) for the request to be honored.

miniSphere 5 beta 4 is on its way, it's just that I keep hitting really bad bugs that I have to fix.  Also I'm a refactoring fiend so a good deal of the regressions are my own fault, but let's not talk about that...

5.0b4 is out now!

The entire Sphere Runtime has been completely overhauled and brought some breaking changes with it (although I tried to be as conservative as possible), see the API documentation to find out what you'll have to do to upgrade.  Notably, Thread.join() and Scene#run() are no longer blocking and instead return a promise that you can await.

Major changes in Beta 4 off the top of my head:

• "fullScreen" manifest field: Specifies default fullscreen state for game, defaults to false
• "sandbox" manifest field: Specifies enforcement level of SphereFS sandbox.  "full" is the default and matches previous behavior, "relaxed" allows write access to @/, and "none" disables the sandbox
• --performance command line option for SpheRun (disables the stepping debugger)
• Thread#on_update() in subclass can be async and use await
• No more Sphere.run() or screen.flip(), v2 games must yield to the event loop (async/await makes this painless)

Forgot to mention - because files were renamed, I strongly recommend uninstalling any previous version of miniSphere before installing 5.0b4 to ensure cruft from previous versions doesn't cause problems.

Do you have an ETA on a stable 5.0 release? I'm not complaining, I just haven't been updating the AUR package. I'm pretty sure I'm the only person who actually uses it, but I don't want to update to a potentially unstable release, and I don't feel like creating a second AUR package for unstable builds.

I'm hoping to have the release ready by Halloween, but I'm not sure how feasible that is just yet.  There are a few showstoppers that may or may not be easy to fix:
https://github.com/fatcerberus/minisphere/issues?q=is%3Aissue+is%3Aopen+label%3Ashowstopper

So we'll see what happens.

Alright, that's fine. Arch is known for being "bleeding edge", but I don't want to push something that isn't stable yet.

miniSphere 5.0rc is up.  This is a release candidate and should therefore be very stable.  As such, the links for miniSphere 4.8 have been taken down.  Give miniSphere 5.0 a spin, it's awesome!

Do you think it's safe enough for the AUR?

Release candidate is just that: Either it or a build very close to it will become the final release (unless someone finds some huge showstopping bug between now and the 31st).  So yeah, I definitely consider it stable at this point.

I made some last-minute tweaks to 5.0.0 to improve the experience compared to the RC, mostly to do with error reporting.  In particular was an issue where syntax errors in a module didn't have file:line info that made quick debugging much harder than it needed to be.  So that'll be fixed in the final build.

I also made a change to the API, shader uniforms are now set directly on the Shader instead of being associated with Models.  That matches how OpenGL shaders actually work and allowed me to optimize things better.

Release is still on track for the 31st so get ready, the best miniSphere release yet is almost here!