Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505944 times) previous topic - next topic
0 Members and 20 Guests are viewing this topic.

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.

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.

Re: miniSphere 4.5.3

Reply #1518 –
Quote from: Eggbert – on

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.

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.

Re: miniSphere 4.5.3

Reply #1520 –
Quote from: Fat Cerberus – on

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?

Re: miniSphere 4.5.3

Reply #1521 –
Quote from: Eggbert – on

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.

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!
 

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 :(

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.

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.

Re: miniSphere 4.5.6

Reply #1529 –
Quote from: Eggbert – on

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.