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.
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.
Quote from: Lord English on May 18, 2016, 04:32:48 pmAt 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.
pig = "maggie"; // "accidentally" create a global variableconsole.log("the pig ate everyone - pig.js");require("./cow");return 812;
console.log("the cow ate the pig " + pig + " - cow.js");
$ node pigthe pig ate everyone - pig.jsthe cow ate the pig maggie - cow.js
fetch v8gclient synccd v8python gypfiles/gyp_v8