Skip to main content

News

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

0 Members and 17 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.3
Reply #1515
For the next release I'm switching the default ES6 transpiler from Babel to TypeScript, since the latter is a lot faster.  TS is a strict superset of vanilla JS, so there shouldn't be any issue with the transition, but of course I'll make sure to do a lot of in-house testing before putting out a release with the change. ;)

By the way when I say "a lot faster" I mean a lot faster - build time for Spectacles went from what felt like about 30s down to 5s.  It's quite a dramatic difference.

TS with type-checking is a different story entirely - that is SLOW.

edit: Full rebuild of Radnen's Blockman takes ~13s on my Skylake i7 using TypeScript.  That took over a minute with Babel.

edit 2: Hm, that's unfortunate.  TypeScript will not convert ES6 generator functions to an ES5-compatible form; Babel does.  Generators are quite useful, e.g. as iterators.  It might worth the tradeoff for a faster build though... hm...  A future release of TypeScript will support downlevel transpilation of generators.  So this is a non-issue in the long run.
  • Last Edit: March 05, 2017, 12:45:29 am by Fat Cerberus
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.3
Reply #1516
Hm, so the lack of generator support wasn't a dealbreaker for TS-as-default-compiler.  This, however, is:
https://www.typescriptlang.org/docs/handbook/iterators-and-generators.html

TypeScript purposely only transpiles for...of properly for arrays, not generic iterables (which is stupid since it's just a matter of calling collection[Symbol.iterator]() and stepping through it using .next().  Iterators are one of the most useful features in ES6, I don't want to lose them.  So Babel it is.  Hopefully it'll get faster in the future.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.3
Reply #1517
I've been kind of neglecting it, but I finally got around to updating the AUR package.

Also, while syntax highlighting isn't complete yet, it will have TypeScript highlighting in addition to JavaScript highlighting.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.3
Reply #1518

I've been kind of neglecting it, but I finally got around to updating the AUR package.

Also, while syntax highlighting isn't complete yet, it will have TypeScript highlighting in addition to JavaScript highlighting.


Thanks, good to know.  I'm probably going to revert to Babel as the default ES6 transpiler, but TypeScript support (i.e. .ts files) will be in the next release anyway, as an opt-in feature.  The main thing I'm trying to figure out is how to do incremental builds, because the TS compiler wants to see the complete program upfront.  So if even one file changes, everything has to be recompiled.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.4
Reply #1519
New release.  4.5.4 has a small breaking change for Cell, the transpiler is now imported as:

Code: (javascript) [Select]

import { transpile } from 'compiler';


The rename was done in anticipating of future TypeScript support.  Calling TS a "transpiler" is stretching it since it's technically a different language, so I wanted a more generic name for the module than "transpile".  Note also that there's no longer a default export - transpile() is now a named export.

This release also adds support for for...of iteration of over from() queries.  Note that query results are enumerated as key/value pairs, NOT the raw values.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.3
Reply #1520

The main thing I'm trying to figure out is how to do incremental builds, because the TS compiler wants to see the complete program upfront.  So if even one file changes, everything has to be recompiled.

Really? How long would it normally take to transpile it on a fairly large project?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.3
Reply #1521

Really? How long would it normally take to transpile it on a fairly large project?


Yeah, the TS compiler wants to parse everything up front so it can resolve types, interfaces, etc. properly across files.  There's no separate compile and link steps like with C/C++ so you have to give it the full list of source files every time you build.  I haven't found a way around it.

Anyway, with type checking turned on and default definitions, Spectacles takes 60+ seconds to compile if I remember right from the last time I tested it.  WITHOUT type checking it's actually pretty quick--around 5 seconds for the whole project--but that would still be annoying to wait 5s every time you go to test something.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.4
Reply #1522
True, but miniSphere itself takes much longer to build. QtSphere IDE usually takes 5-6 seconds as well.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.4
Reply #1523
Good news: TypeScript recently merged full support for generators and for...of iteration when targeting ES5.  So I'll be able to make the switch after all and everyone can benefit from much faster ES6 transpilation times. :)

There will be some work needed to implement sourcemap support first though, before I can make a release using the TS transpiler (probably that'll be 5.0.0).  Sphere Studio can't currently debug TypeScript-compiled code properly because the line numbers don't match up.  SSJ can be used because it downloads source directly from miniSphere, but the mismatched line numbers still complicate setting up breakpoints for example.

edit: Holy crap, TypeScript has async/await!  That's awesome!
  • Last Edit: March 08, 2017, 02:28:00 pm by Fat Cerberus
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.5
Reply #1524
New version 4.5.5, bringing much faster transpile times thanks to TypeScript and fixing a few bugs in the process.  5.0 will bring more comprehensive TS integration; right now it's just being used for its transpiler.

I'm not sure how well TypeScript preserves line numbers in the transpiled code, so let me know of any issues with Sphere Studio debugging.  SSJ is fine in any case since it just downloads the transpiled code directly from the engine.  Sphere Studio tries to use the original source, so that might not match up now :(
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.5
Reply #1525
Is there relatively simple/straightforward documentation on Sphere/miniSphere's file formats (RSS, RMP, RTS, etc)?

also, looking at the GitHub repo source, what is obsmap?
  • Last Edit: March 10, 2017, 07:49:24 pm by Eggbert

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.5
Reply #1526
obsmap = obstruction map.  It handles collision detection for the map engine, which is not bounding-box but is instead based on intersecting line segments.  The obsmap keeps a list of all the obstructing line segments on a given map or tile.  You then pass in a rectangle to the obsmap representing the location of a spritebase, and it will tell you if the sprite is touching any of the segments.

For the file formats, miniSphere's implementation was pieced together by using the internal documentation for Sphere 1.x, a bit of reverse engineering, and a lot of studying the Sphere 1.x source code.  The internal docs will honestly get you most of the way there, but there are some ambiguities you need to watch out for, particularly with the RSS format.  Ultimately, if all else fails, you can probably get a good idea of what to do by looking at the miniSphere source.  I tried to make the loaders as easy to follow as possible.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.6
Reply #1527
I've switched back to Babel for now, as the lack of sourcemap support makes debugging impossible in the IDE.  TypeScript tends to add a lot of boilerplate to support, e.g. generator functions, and also deletes blank lines, so the line numbers end up not matching up at all.  While Babel's line number retention isn't perfect either, it works well enough that debugging is still possible in 90% of cases.

TypeScript support will eventually be added back, but it's being postponed until miniSphere 5.0--which is still quite a ways off.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.6
Reply #1528
Would it be unrealistic for the IDE to calculate what the new line number would be and output the both TypeScript line number and the compiled Javascript line number?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.6
Reply #1529

Would it be unrealistic for the IDE to calculate what the new line number would be and output the both TypeScript line number and the compiled Javascript line number?


That's what source maps are for, and there's plenty of existing code to work with them.  The problem is that all the sourcemap libraries I was able to find only go one way, i.e. compiled->original.  Because I have to tell the engine where the breakpoints are relative to the compiled code (the code Duktape is actually running), I need a reverse lookup for that, i.e. original->compiled.  I'm sure something exists to do that, but I wasn't able to find it.  So since it may take me a while to get everything in order, I put Babel back for now so as not to compromise the debugging experience.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub