The engine's up and running finally.  I verified by converting the Prim module to an actual class with static methods, worked like a charm.

Now I just have to fix the crazy memory leaks.  My finalizers aren't getting called because I didn't figure out how to make them work yet and so everything gets leaked.  Depending on the game you can sometimes hit 1GB of RAM usage--and climbing--within seconds.

Got the finalizers to run.  I can't get them to run on shutdown but it's not a big deal since the OS will clean everything up at that point anyway.  Both Sphere v1 and v2 games run flawlessly now.

The engine definitely seems a lot snappier than it was with Duktape, that's for sure.

There are two things left in the engine that still don't work:

• Get ES6 modules working.  I have the code in place to load them, but it's giving me random syntax errors, even for a completely empty file!  No idea what's up with that.
• Exceptions don't seem to include file and line number information.  That combined with not being able to use SSj yet makes debugging a nightmare.

I had a weird dream about miniSphere, CC, and SM last night...

...now I want to hear about it.

In other news, CC is *fast*.  Remember the SoundStream demo I posted here?
http://forums.spheredev.org/index.php/topic,1400.msg9870.html#msg9870

Under Duktape that spiked my CPU usage to around 15% (almost completely saturating a core), and didn't complete buffering the mp3 file until the song was nearly over.  Under CC, total CPU utilization is around 3% and the stream is completely buffered by about 30 seconds in.  If I remove the delay, decoding the whole file takes no more than 5 seconds.

It's kind of difficult to describe, and it was very abstract. They were more than just software, but not really physical. They just kind of...existed.

Also, that's pretty awesome! Do you think it wold be possible to optimize it even more to shorten the amount of time, or would that require native decoding?

I'm at the mercy of how fast the decoder can send me data.  I'm just taking the data it sends me in callbacks and stuffing them into the stream with SoundStream#write().  There's not much more I can do to optimize that on my end.

Aurora.js does seem to be inefficient, though, and for whatever reason the callbacks aren't async except for the first one, so it blocks execution until the file finishes buffering.  I'd probably be better off using a native decoder.

@Rhuan Since you already looked through the GitHub issues list, is there anything in there that you would like to be prioritized for implementation in mS 4.9?

@Rhuan Since you already looked through the GitHub issues list, is there anything in there that you would like to be prioritized for implementation in mS 4.9?

Not really, based on your posts above the things I'd want in 4.9 would be miniSphere running smoothly with chakra including module loading and line numbers for script errors... and SSJ working. My view is that everything else can wait.

I removed the core-js shim (polyfill for ES6 built-in functions, obviously no longer necessary) and the performance improved even further.  Time to build Spectacles using Babel: 2 seconds.

edit: Good news!  I got modules working!  miniSphere 4.9 will thus have nearly full support for ES6 without any transpilation or polyfills, AND be way faster to boot.  Now THAT'S what I call an upgrade.

I'd probably be better off using a native decoder.

Yeah, that's what I had in mind. It would obviously take some work, but I'm sure it would be worth it.
Also, I have some good news. It turns out that the issues I was having in Arch Linux with tracker files not playing in miniSphere was because of an out of date Dumb package, so that's hopefully going to come out of the testing repo (which it was recently put into) and into the main repo.

Slight complication: CC doesn't seem to provide access to the module export table through its API, so I can't make require() work with ES6 modules like it did with Babel and TS.

Would it be unreasonably difficult to implement it yourself?

The problem is that there's seemingly no access to the module's exports from the native side--so there's nothing to latch onto.

I managed to replicate mS<=4.8 behavior of instantiating a class exported from the main module by evaluating a fake root module that imports the real one, but I don't think I can adapt that to make require() work, since I have to return the exports to the caller somehow.

Would it be unreasonably difficult ti implement it yourself?

Hmm... come to think of it, there may be a way to make this work after all.  I could evaluate the following fake module:

Code: (javascript) [Select]

import * as RealModule from '<filename>';
global.___exports = RealModule;

And then just return the value of ___exports from require().

edit: It worked!

Progress report!

Here's what works so far:

• All Sphere v1 and v2 APIs
• Cell
• ES6 syntax, no transpilation required
• ES6 built-ins, no polyfill required
• ES6 modules!
• ES2017 async functions (!!)
• require() can load ES modules
• STILL backward compatible with Sphere 1.x games

Here's what doesn't:

• File and line information on the error screen.  SpheRun does show a stack trace after a crash, however.
• SSj and SSj Blue
• Linux support; it crashes under VirtualBox at least

Getting require() to be able to load modules was important, as without that ability, transpiled code doesn't work, and backward compatibility is lost.  Both Babel and TypeScript transpile import statements to require() calls.