Skip to main content

News

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

0 Members and 26 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1335
Hm, Spidermonkey seems to be going down V8's path.  The API can change arbitrarily between releases, quickly enough that the documentation is not always kept up to date (there's a tutorial on MDN that doesn't even compile because it doesn't reflect the current API), and I found this note in the release notes for SM 45:

Quote
Mozilla has no plans to keep the JSAPI stable for embedders. We have instead chosen to concentrate on overall performance and accuracy as our primary concerns.


Lovely.  So that should be a fun learning curve if I can't even trust Mozilla's own API documentation to be kept up to date.  Thank goodness for intellisense. :P
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 4.2.4
Reply #1336

Hm, Spidermonkey seems to be going down V8's path.


I thought V8 was supposed to be relatively friendly with embedded projects (for example, node.js)
Is that no longer the case, or is the node.js development team willing to deal with the changes in the API?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1337
Back when FJ was working on TurboSphere the V8 API was a moving target and in a constant state of flux, I don't know if it's stabilized since then.  That's one of the things that ultimately led him to go with SpiderMonkey instead. (The other reason being that V8's garbage collector is too lax leading to native resources not being freed in a timely manner)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 4.2.4
Reply #1338
Ah, well that stinks. So with those two out, does that make Duktape our best option, for better or worse?

Also it's not a huge issue but I noticed I get a parse error if the last line of a script is a comment.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1339

Ah, well that stinks. So with those two out, does that make Duktape our best option, for better or worse?

Also it's not a huge issue but I noticed I get a parse error if the last line of a script is a comment.


For now, probably yes.  I'm still going to keep experimenting with SpiderMonkey though, but it'd be a pretty big refactoring project to actually make the switch.  Most likely minisphere 5.0 will still use Duktape.

I'll look into that comment issue and submit a bug report if needed.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 4.2.4
Reply #1340
More than just being less stable, V8's API isn't very friendly. It's developed solely to be a part of Chrome, while SpiderMonkey is intended to be a good JS VM. As a part of that, it is also far better documented.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1341

More than just being less stable, V8's API isn't very friendly. It's developed solely to be a part of Chrome, while SpiderMonkey is intended to be a good JS VM. As a part of that, it is also far better documented.


Better documented, but I haven't found the documentation to always be kept up to date.  This "hello world" tutorial which is likely the first thing anyone's going to find when learning how to embed SM, won't even compile with the current version:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/How_to_embed_the_JavaScript_engine

I had to do some digging before I found out that JS_NewRuntime and JS_NewContext were merged into one function at some point.  Speed bumps like this are surmountable (and of course MDN is a wiki so I could fix the tutorial myself), but it doesn't exactly inspire confidence.  I found Duktape's documentation to be a lot better when I was first learning to use it.
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.2.4
Reply #1342
Is there really even a point to switching to anything else? Isn't Duktape serving its purpose just fine on this? Or is this done purely for experimental reasons?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1343
We'll call it "experimental with intent to implement". ;)

As far as Sphere 1.x backward compatibility and migration of existing projects is concerned, Duktape is certainly more than adequate.  However there are a lot of neat new JS constructs from the latest specifications that it doesn't support and probably won't for the foreseeable future, for example:


  • Destructuring assignment: [a, b, c] = [1, 2, 3]

  • Lambda syntax: (a, b) => a + b

  • Computed property names: obj = { [propNameVar]: "something" }

  • Symbols (like hidden properties)

  • Map/Set/WeakMap/WeakSet

  • Promises (these can be polyfilled though)

  • Probably more that I can't think of right now



I have an ongoing dialogue with the developer.  Some work is being done to get some of the easier stuff implemented, but overall, comprehensive ES6+ support is not a near-term goal; Duktape is effectively an ES5 engine + some extras from later specs (like ArrayBuffer).  If I switch to SpiderMonkey or V8 I can get all of this stuff now, plus much better performance thanks to the JIT.
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.2.4
Reply #1344
I see, that makes sense. I guess I need to brush up on my JS too, considering so much stuff is being added.

Re: minisphere 4.2.4
Reply #1345
Would it be at all possible to use a non-Allegro library to add MP3 support? Some of the old 1.x games had mp3 audio files, and it would be nice to have it for convenience, rather than having to go through, convert each one and then look for where each one is loaded.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1346

Would it be at all possible to use a non-Allegro library to add MP3 support? Some of the old 1.x games had mp3 audio files, and it would be nice to have it for convenience, rather than having to go through, convert each one and then look for where each one is loaded.


Not without relicensing minisphere under the GPL.  There are no MIT/BSD licensed mp3 decoders, sadly. :-\
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.2.4
Reply #1347
Well, at least there's this to decode MP3 in JS. The code looks pretty browser-independent. GPL2-licensed tho.

Re: minisphere 4.2.4
Reply #1348
There are also LGPL-licenses MP3 decoders, which would not interfere with the permissive license.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 4.2.4
Reply #1349
I finally caved and the latest minisphere build supports type coercion for boolean arguments of Sphere v1 functions.  It turns out that a lot of legacy Sphere code assumed this and did things like passing 1 and 0 for true and false, which broke several games in minisphere due to a stricter type check which throws a TypeError for non-boolean values.  Sphere v2 APIs still use the stricter check, of course.

I also added native support for Promises (using a polyfill).

edit: And with that change, Trial and Error now runs in minisphere unmolested. ;D  Screenshot attached - also note minisphere's CPU usage--and that's with the debugger attached!
  • Last Edit: October 28, 2016, 01:35:11 am by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub