Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505578 times) previous topic - next topic
0 Members and 20 Guests are viewing this topic.

Re: miniSphere 4.7.1

Reply #1830 –
Quote from: Rhuan – on

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)


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 :)

Re: miniSphere 4.7.1

Reply #1831 –
Quote from: Eggbert – on

I use Linux a lot, and according to WineHQ, it doesn't run, or runs terribly.

It's probably a little different, but gitg has served me fine for selecting what changes to commit and going through the commit history. Only thing left to do after that is git push on the terminal.

Re: miniSphere 4.7.1

Reply #1832 –
Actually, I kinda forgot that Visual Studio Code (my favorite text editor/lightweight IDE) has built-in git support.

Quote from: Fat Cerberus – on
Quote from: Rhuan – on
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)

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?

Re: miniSphere 4.7.1

Reply #1833 –
Quote from: Eggbert – on
Does SpiderMonkey have built-in CommonJS support? If not, what about v8?
A quick read around implies that neither of them have commonjs built in. Also they're both c++ rather than c and so some wrapper code will be required to make the minisphere code base use either of them.

Re: miniSphere 4.7.1

Reply #1835 –
The lack of CommonJS support isn't a problem, CJS isn't hard to implement, you could even do it directly in JS if you wanted to.  You just wrap the text of the module in
Code: (javascript) [Select]
(function(exports, require, module, __filename, __dirname) {
    // your module here
})
and then call the function with the relevant parameters; the trickiest part is implementing require() in C because it's context-sensitive (path is relative to module calling it).  Other than that it's fairly painless.

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.

Re: miniSphere 4.7.1

Reply #1837 –
Not really complicated, just tedious.  I'd basically have to wrap almost all of the SpiderMonkey API in C functions that could be called from miniSphere's C code.  That's part of why I'm trying to isolate the script layer as much as possible from the actual engine code (which has mostly been accomplished, save for the map engine), so that only the files directly related to running JS code need to be updated, stuff like image handling, etc. don't have to be touched.

Re: miniSphere 4.7.1

Reply #1838 –
Quote from: Fat Cerberus – on
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.
Happy to go halves with you on the effort for this one - assuming it can wait until around september I won't have much time until then.

Re: miniSphere 4.7.2

Reply #1839 –
miniSphere 4.7.2 is up, fixing a fair number of bugs and polishing up a few dark corners of the API.  Upgrading is highly recommended.

Re: miniSphere 4.7.2

Reply #1842 –
Quote from: Eggbert – on
It looks like sphere2-core-api.txt isn't entirely up to date. It still says
FileStream#size [read-only]

Thanks, I noticed that this morning and was going to fix it, and then forgot about it.  Good thing you reminded me. :))

Re: miniSphere 4.7.2

Reply #1843 –
I'm currently working on cleaning up the map engine code and generalizing it so I can move the API stubs into vanilla.c.  Ultimately what I'm trying to accomplish is to isolate all the Duktape-specific code to one place so it will be easier to swap in SpiderMonkey down the road.  That  still won't be a simple task, but detangling the spaghetti code certainly doesn't hurt. :P

Re: miniSphere 4.7.2

Reply #1844 –
Map engine cleanup is done, and here's the entire Sphere v1 API (minus a function here and there) in all its epic glory:
https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/vanilla.c#L27-L455

274 global functions.  If you count object methods, there are over 400 functions in total.  I'm in utter shock that it's this huge, that's insane.

Pegasus (Sphere v2) is significantly more streamlined:
https://github.com/fatcerberus/minisphere/blob/master/src/minisphere/pegasus.c#L186-L381

No global functions at all (unless you count require()) :D