Skip to main content ↑ ↓

News

Topic: neoSphere 5.9.2 (Read 529499 times) previous topic - next topic

0 Members and 3 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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 :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub
  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
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?
  • Rhuan
  • [*][*][*][*]
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 #1834 –
Oh boy, that sounds like fun.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub
Re: miniSphere 4.7.1
Reply #1836 –
Is it an issue of writing a lot of boilerplate code, or would it be more complicated than that?
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub
  • Rhuan
  • [*][*][*][*]
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.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub
Re: miniSphere 4.7.2
Reply #1840 –
I'm not familiar with SpiderMonkey or with wrapping C around C++, but I'll look into that now.
Re: miniSphere 4.7.2
Reply #1841 –
It looks like sphere2-core-api.txt isn't entirely up to date. It still says
FileStream#size [read-only]
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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. :))
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
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
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub