Or you could do what Turbo does and make everything a plugin/module, but only require a game to specify which modules it uses in its manifest/sgm file.

Or you could do what Turbo does and make everything a plugin/module, but only require a game to specify which modules it uses in its manifest/sgm file.

Yeah, I figured I would do something like that once I implement plugins (probably a 5.0 feature).  Overall I really like the namespacing semantics of require (the caller, not the module, defines the namespace, which prevents naming conflicts entirely), but I don't want to have to add a bunch of boilerplate requires at the top of every file that needs to access functionality that's already compiled into the engine.

Progress update: I just added support for console.log() today.  Since standard output is used for engine logging, console.log() output is redirected to SSJ.  I figured it was about time I implemented this, every other JS environment known to man already includes it.

One thing I do want to do still for minisphere 3.2 is to improve the require() implementation so that I can experiment with Pegasus stuff without breaking Sphere 1.x compatibility right away.  This requires two things which are currently not supported:

• Ability to load arbitrary scripts from the game directory as modules


• Loading the startup script as a module (but ONLY if the manifest is .s2gm!)

At some point I may need to replace Duktape, though.  In my experiments with doing things in script, e.g. Galileo-based text rendering, minisphere's CPU usage nearly tripled compared to doing the same thing in C.  Before I do that though, it'd be nice if I could create a shim which would allow me to swap out the JS engine without having to rewrite the entire API layer.  How feasible that is, I'm not quite sure.  It may be impossible.

Duktape is a good fit for the Sphere 1.x design because the engine does all the heavy lifting--the game logic is almost never CPU bound as a result.  In a more minimal engine where even most of the infrastructure is in script, JIT is pretty much a necessity.

At some point I may need to replace Duktape, though.  In my experiments with doing things in script, e.g. Galileo-based text rendering, minisphere's CPU usage nearly tripled compared to doing the same thing in C.  Before I do that though, it'd be nice if I could create a shim which would allow me to swap out the JS engine without having to rewrite the entire API layer.  How feasible that is, I'm not quite sure.  It may be impossible.

The big issue I found is that different JS engines allow different specific hooks for accessing variables, modifying globals, etc.

It's certainly possible, but the amount of work it represented was literally more than changing all of TurboSphere over from V8 to SpiderMonkey. That makes the benefit of such a system, beyond very basic usage is quite questionable to me, given the amount of work to maintain it.

At some point I may need to replace Duktape, though.  In my experiments with doing things in script, e.g. Galileo-based text rendering, minisphere's CPU usage nearly tripled compared to doing the same thing in C.  Before I do that though, it'd be nice if I could create a shim which would allow me to swap out the JS engine without having to rewrite the entire API layer.  How feasible that is, I'm not quite sure.  It may be impossible.

That is pretty much impossible. Also, V8 and SM require C++ and works very differently regarding memory management. Don't start.

Why not just keep more stuff in C then? Why move everything to JS, if C is faster.

At some point I may need to replace Duktape, though.  In my experiments with doing things in script, e.g. Galileo-based text rendering, minisphere's CPU usage nearly tripled compared to doing the same thing in C.  Before I do that though, it'd be nice if I could create a shim which would allow me to swap out the JS engine without having to rewrite the entire API layer.  How feasible that is, I'm not quite sure.  It may be impossible.

That is pretty much impossible. Also, V8 and SM require C++ and works very differently regarding memory management. Don't start.

Why not just keep more stuff in C then? Why move everything to JS, if C is faster.

Because Duktape's stack-based API is tedious to work with when dealing with object properties.  High-level things such as the map engine would be much easier to maintain if they're written in JS.  To get an idea of what I mean, see my Node.js-like module loader:
https://github.com/fatcerberus/minisphere/blob/master/src/engine/commonjs.c#L9-L116

That would be about 20 lines of code in JS.  In C, it's nearly 100 because of all the stack juggling.  By the way, wrapping the module code in a function is exactly what Node.js does:
https://github.com/nodejs/node/blob/master/lib/internal/bootstrap_node.js#L426-L429

There's another good reason to write stuff in JS, too: If we end up with multiple engine implementations, as long as they implement the same low-level API, the same high-level JavaScript code can be reused in all of them.  This way the lion's share of the code only needs to be written once, as a "reference implementation" of sorts.

JS is also good enough for most things. Given how many things in the map engine are not really performance dependent (command queues, movement, scrolling) it makes sense to put them in JS.

I can also say that it just feels more natural to write the map engine in JS than in C/C++. It also makes it easy to extend the map engine.

regarding the function() wrapper in node: that is NativeModule only. Actual modules are loaded like I do it: using a new context. This NativeModule is modules with coded already in the node executable. Totally different case.

Hm, maybe, but the end result is the same:

pig.js:

Code: (javascript) [Select]

pig = "maggie";  // "accidentally" create a global variable
console.log("the pig ate everyone - pig.js");
require("./cow");
return 812;

cow.js

Code: (javascript) [Select]

console.log("the cow ate the pig " + pig + " - cow.js");

Output

Code: [Select]

$ node pig
the pig ate everyone - pig.js
the cow ate the pig maggie - cow.js

Note two things:

• return 812; is silently ignored (return is a SyntaxError in global code)


• The "accidentally" created global variable is accessible in a different module

Yes, I like to reverse-engineer stuff, why do you ask?

minisphere 3.2.0 is out, and brings with it a new Node.js-inspired module resolver and support for console.log().  There are also a few under-the-hood improvements, including a tweak to the frame skipping logic which helps keep the frame rate steady during frameskip conditions.

The new module resolver will allow you to load any script in your game directory as a module by prefixing the module ID with @/, for example @/modules/mymodule.  Relative IDs are also supported (except in global code, e.g. the startup script) and will be resolved based on the location of the calling module.  JSON is also supported so that require('@/path/to/file.json') will decode the file to a JS object rather than trying to execute it as code.

I think I'm going to drop the on-the-fly TypeScript transpiling in the next major release.  I tried an experimental change where the engine would run every script regardless of file extension through the TS transpiler (whoever decided TS should be a proper superset deserves a medal) and Spectacles took nearly a full minute to start up.  Duktape just doesn't have the performance for it.

Too bad both SpiderMonkey and V8 have C++-only APIs...

I may not be dropping Cell in minisphere 4.0 after all.  I do still want to make that command-line .s2gm editor though, so I'll need to come up with a new name for it.

I did some experimenting with V8 and let me say, my first impression was not a positive one.  It's drop-dead simple to build even on Windows (after I coerced Windows Defender into not quarantining Google's build tools anyway...), but that's as far as the "simple" goes   The API is ridiculously complex, and is apparently such a moving target that even Google can't keep their documentation up to date--most of the code samples given won't even compile.

I understand why FJ got fed up with it now.  Too bad SpiderMonkey isn't as simple to build.

Oh, amusing tidbit: The 32-bit minisphere binary went from 2.5MB to nearly 10MB once I linked in V8.   I don't think it actually qualifies for the "mini" designation anymore at that point.

V8  is simple to build? Well, that's new, it was a huge hassle before.

SpiderMonkey isn't too bad, their instructions just worked for me on Windows the last time I tried a fw weeks ago.

Yeah, you need to download Google's dev tools ("Depot Tools"), put them in the PATH, set a few environment variables, and a working build is just a few commands and about a half hour away.  I guess it's improved since you used it?

I think the commands were:

Code: [Select]

fetch v8
gclient sync
cd v8
python gypfiles/gyp_v8

And then it gives you a nice MSVC solution you can build.

That was the supposed procedure right when I gave up on V8, but the depot tools were basically completely broken. 'gclient sync' would just puke a bunch of errors out when I ran it, and the V8/Chromium folks said I needed to set about twenty environment variables and set an identity in a config file, and that was when I had had enough of Google's development process

Before that, the gyp build scripts were broken or generated broken MSVC projects most of the time. Before that, the SCons setup they had actually worked quite well. That was actually what made me want to use SCons, since everything else V8 used seemed to be a huge disaster. That and autotools is not easy to use on Windows, while SCons just works on Unix and Windows (and a few other places Python works, too).

Building SM isn't so bad, assuming you get the actual SM source release instead of building it inside gecko. Then you download the MozBuild tools, run their terminal, go to the SM directory, and it's a matter of ./configure && make.