Good work, now... How much slower was it than Duktape?

Good work, now... How much slower was it than Duktape?

I would say it was slower by a factor of about -10x.

Good work, now... How much slower was it than Duktape?

I would say it was slower by a factor of about -10x.

I was hoping for more, that's the low end of the benchmarks I did, but ah well still pretty amazing, and TBH when optimised correctly most things I've been scripting don't need that level of speed - but it is nice to have it in reserve.

One question though, why Babel not TypeScript? I thought you switched to babel because typescript took too long to run in duktape couldn't you switch back now? Is Cell flexible enough to use either with a cellscript flag?

It was actually the reverse - TypeScript is faster than Babel when type checking is off--i.e. when it's just used as a vanilla ES6 transpiler.  However, Babel supports more ES6 features (see the kangax table) and detects more errors (like import/export in a .js file) that TypeScript completely ignores when type checking is off.  The problem was that Babel takes about 5x longer to process a script, so I went back and forth for a while but eventually settled on using TS in plain-JS mode.

Now Babel runs faster than TS did under Duktape.

Another problem with TypeScript is that for type checking to work, the compiler needs every single .ts file in the project at once--so just by changing one file you have to rebuild your whole game.  Even with a fast JS engine running it, that's not going to be very fun.

Hmm, I see, not sure on the speed point, I guess it depends how much code there is and how frequently a retranspile is needed - is cell with Babel set up to only re-transpile the documents that have changed?

Other thoughts:
1. Per the Kangax table pure CC actually has higher ES6 compatability than either Babel or Typescript, with only one area it's behind on that being reg.expresion prototypes

2. Is the transpiling step even needed with CC?

3. For people who like the idea of working typescript can a choice of Babel or Typescript be specified in a cellscript? Without needing many other changes?

4. I note that despite point 2 I'm very keen on the idea of cell as I want to write cellscript Tools to package maps and sprites into new formats I'm designing that will be loaded a lot faster than RMP, RSS or Tiled JSON files. (I also want to see if I can make a cellscript tool to strip debug code out of my scripts for release versions)

EDIT: extra note on typescript compatibility - the Kangax table's footnote says they're looking at Typescript 1.8, version 2.4 is the latest stable release on typescriptlang.org, they support several features that Kangax says they don't support.

Hmm, I see, not sure on the speed point, I guess it depends how much code there is and how frequently a retranspile is needed - is cell with Babel set up to only re-transpile the documents that have changed?

Other thoughts:
1. Per the Kangax table pure CC actually has higher ES6 compatability than either Babel or Typescript, with only one area it's behind on that being reg.expresion prototypes

2. Is the transpiling step even needed with CC?

3. For people who like the idea of working typescript can a choice of Babel or Typescript be specified in a cellscript? Without needing many other changes?

4. I note that despite point 2 I'm very keen on the idea of cell as I want to write cellscript Tools to package maps and sprites into new formats I'm designing that will be loaded a lot faster than RMP, RSS or Tiled JSON files. (I also want to see if I can make a cellscript tool to strip debug code out of my scripts for release versions)

Yeah, only the changed files get recompiled, unless you pass the -r switch for a full rebuild.  That's true even in the 4.8.4 which uses TS, with type checking off I can compile individual scripts with no problem.  It's just the strong typing that requires passing in everything at once.

1. Makes sense, every single major engine is ahead of Babel nowadays, it's just that it was nice to be able to get basics like arrow functions and such in Duktape since it's still primarily an ES5 engine.

2. Technically no, transpilation will no longer be necessary (which is very nice!), although it might be useful if you want to compile a game that runs on earlier miniSphere versions.  That's kind of academic though since I keep making breaking changes to the API.

3. It would just be a matter of coding a TypeScript tool using Cell's Tool API and using that in place of transpile().  Cell is fully programmable with JS so you can pretty much do anything you want with it.  It exposes the same FS API that miniSphere does, too.

One big benefit to this change is that runtime modules will be able to use ES6 syntax now.  You have no idea how many times I've wanted to type an arrow function while coding a runtime module and had to stop myself because otherwise the module wouldn't load.   Arrow functions are especially tempting when using from().

All that aside, I'm going to stick to old ES5 JS for now, once I have a working release of the Engine code I'm writing in ES5 I'll consider what's best for the first complete refactor I choose to do.

Started on migrating miniSphere to CC today.  Let's just say my local copy of the codebase is in shambles right now.

Most of the work is just straight Find and Replace but some stuff needs to be refactored.  Very tedious work, but the good part is thanks to JSAL if I decide to change engines in the future, I won't have to rewrite half the engine again.

Here's what's going to be fun: the debugger.  With Duktape I could just open a socket and wire up Duktape's debugger protocol to it with callbacks.  CC has an actual debugging API so I'm going to have to figure out how to make miniSphere and SSj communicate myself.

Hopefully it's not been too tedious.

I'm really looking forward to seeing this in action - I'm probably going to try and build some stupidly detailed physics sim to see if I can get a slow down.

I'm debating whether to release the CC miniSphere as 4.9 or 5.0.  It's a pretty big change that definitely warrants a new major version, it's just that I've promised an API freeze for mS 5.0 and I'm not quite ready to set everything in stone yet.

I'm debating whether to release the CC miniSphere as 4.9 or 5.0.  It's a pretty big change that definitely warrants a new major version, it's just that I've promised an API freeze for mS 5.0 and I'm not quite ready to set everything in stone yet.

Which parts of the API are still in flux?

In particular, the shader API needs work.
https://github.com/fatcerberus/minisphere/issues/192

Not sure what else, I'll have to skim through sphere2-core-api.txt when I get home to jog my memory.

Almost got miniSphere going, it runs games but there are a lot of glitches and in a fully optimized Release build, it actually crashes outright.  Not sure what's wrong yet and I don't feel like pulling an all-nighter to figure it out.  I'll revisit it later.

I'm debating whether to release the CC miniSphere as 4.9 or 5.0.  It's a pretty big change that definitely warrants a new major version, it's just that I've promised an API freeze for mS 5.0 and I'm not quite ready to set everything in stone yet.

Which parts of the API are still in flux?

Having looked over the issues list I think that the CC version should be 4.9 if you're going to release it soon, save 5.0 until various other aspects are done - i.e. most of the issues log, unless you want to push all of that to 6.0 - just means that the version number will tick up very quickly.

In particular, the shader API needs work.
https://github.com/fatcerberus/minisphere/issues/192

Not sure what else, I'll have to skim through sphere2-core-api.txt when I get home to jog my memory.

Not sure what I think of a shader api re-work. At their core shaders are not n00bie friendly and won't be unless there is a very hand-holdy tutorial written, the key reason for this is they require the use of a second programming language with different syntax and a few other importantly different idiosyncrasies.

Being able to distinguish floats vs ints is very important for shaders, so I actually think having Duck typing with uniform setting would be harder to work with.

One option I suppose would be a setUniform method that takes a type as the first parameter, then at least the type is clearly written in the JS file.

Almost got miniSphere going, it runs games but there are a lot of glitches and in a fully optimized Release build, it actually crashes outright.  Not sure what's wrong yet and I don't feel like pulling an all-nighter to figure it out.  I'll revisit it later.

Sounds like great progress though, so good work.

I found the bug, I was mismanaging JsRefs.  Calling pop_value() releases the reference, and then I was just re-inserting it into the stack without calling JsAddRef() and the garbage collector got it.  Hence the crashes.

Not sure why I couldn't get it to crash in a debug build though...