Skip to main content

News

Topic: miniSphere 5.0.1 (Read 213096 times) previous topic - next topic

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: miniSphere 4.7.1
Reply #1830

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 :)
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.7.1
Reply #1831

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.

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
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
  • miniSphere 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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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
  • miniSphere 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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.7.1
Reply #1838
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
  • miniSphere 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.
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

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
  • miniSphere Developer
Re: miniSphere 4.7.2
Reply #1842
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. :))
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere 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
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere 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
miniSphere 5.0.1 - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan