I'm about to disappear for a while, but advance query for when I'm back, after I get the mapengine working well I'd be keen to help with making a variant of minisphere to run with spidermonkey, I'm very curious what that would do to performance.(Note, in my draft sprite and map engine scripts the bottleneck performance wise is now in the javascript not in the rendering - when I say bottleneck I'm talking about it slowing down when dealing with moving ~1000 sprites)
I use Linux a lot, and according to WineHQ, it doesn't run, or runs terribly.
Quote from: Rhuan on July 25, 2017, 01:52:03 pmI'm about to disappear for a while, but advance query for when I'm back, after I get the mapengine working well I'd be keen to help with making a variant of minisphere to run with spidermonkey, I'm very curious what that would do to performance.(Note, in my draft sprite and map engine scripts the bottleneck performance wise is now in the javascript not in the rendering - when I say bottleneck I'm talking about it slowing down when dealing with moving ~1000 sprites)Performance should be pretty close to native code as SpiderMonkey has a JIT. Duktape just compiles to bytecode and then interprets it, so slowdown with 1,000+ entities is understandable. It's good to hear that the JS is the bottleneck though, as it means I did something right with Galileo in 4.7
Does SpiderMonkey have built-in CommonJS support? If not, what about v8?
(function(exports, require, module, __filename, __dirname) { // your module here})
The hard part, and the reason I keep putting it off, is like Rhuan says, both major JS engines have a C++ API so making them interoperate with miniSphere which is written in C isn't exactly trivial. It can be done, but it's a big investment of time.
It looks like sphere2-core-api.txt isn't entirely up to date. It still saysFileStream#size [read-only]