Interesting, thanks for looking into the issue.  I'll take a look at it when I'm not falling-over tired.

It's a problem with drawZoomedText.  Using drawText will render correctly with the semi-transparent pixels, but drawZoomedText with zoom set to 2 or 1 will not draw them.

I fixed it (on dev branch, patch coming soon).  drawZoomedText is implemented internally by rendering the text to a surface and then zoomblitting that to the screen.  The bug was caused by not setting the blend mode properly before drawing to the surface, causing the alpha channel to be lost.  This was a function that didn't get much in-house testing, since I think there was just one Sphere 1.x game I tested that actually used it (Blackfoot), and that was with the default font so the bug didn't show up.

Alright, 4.5.10 should fix the font rendering bugs.

Good to know.  When I'm further along the development process for TRM, I'll send you a release to help debug some more issues.

4.5.11 fixes an annoying bug in the SSJ command-line debugger where entering an invalid command would cause it to repeat the previous action (especially frustrating if that previous action was a step or continue).  That's only supposed to happen if you leave the command line completely empty.   I also improved startup time a bit for Cell by using TypeScript to compile Cellscripts instead of Babel.

I'm pretty sure I'm going to drop the TypeScript support idea and just use TS as an ES6 transpiler, like it is now.  The more I read about TS, the more I dislike it, as I get the impression the type system is overengineered and at times too clever for its own good when it comes to type inference.  For example, the following is a compile error(!):

Code: (javascript) [Select]

const what = "pig";
if (what === "cow")
    console.log("the cow is going to eat you");
else
    console.log("the pig is going to eat you");

You get an error on line 2 because TypeScript treats the const not as a string but as a literal type: Its type is quite literally "pig".  Thus the comparison is an error because "cow" and "pig" are different types.

TypeScript also apparently uses static analysis in combination with type inference to narrow down types, which at first glance sounds convenient but (to me at least) makes me want to say "stop helping me!":
https://blog.mariusschulz.com/2016/09/30/typescript-2-0-control-flow-based-type-analysis

I can typecast it myself, thank you.

I like C# because I don't usually have to fight the type system - with TS narrowing types down to the level of individual values whenever it can, prototyping stuff becomes annoying in a lot of cases.  That kind of granularity is just not necessary.

That said, as a transpiler TS is pretty incredible.  Given a little generator function:

Code: (javascript) [Select]

function* getEatenByThePig(numberOfTimes)
{
	for (let i = 0; i < numberOfTimes; ++i)
		yield `you got eaten by the pig for the ${i}th time`;
	return 812;
}

TS creates this whole gnarly state machine for it:

Code: (javascript) [Select]

var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (_) try {
            if (f = 1, y && (t = y[op[0] & 2 ? "return" : op[0] ? "throw" : "next"]) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [0, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};

function getEatenByThePig(numberOfTimes) {
    var i;
    return __generator(this, function (_a) {
        switch (_a.label) {
            case 0:
                i = 0;
                _a.label = 1;
            case 1:
                if (!(i < numberOfTimes)) return [3 /*break*/, 4];
                return [4 /*yield*/, "you got eaten by the pig for the " + i + "th time"];
            case 2:
                _a.sent();
                _a.label = 3;
            case 3:
                ++i;
                return [3 /*break*/, 1];
            case 4: return [2 /*return*/, 812];
        }
    });
}

The fact that it was actually able to convert the for loop into a state machine is what really blew me away.

What's the benefit of that state machine? It seems like a lot of code for a very simple closure generator?

I assume it's so ridiculously complex because ES6 has a lot of very specific requirements for iterators and such and the transpiler is trying to cover all the possibilities.  You should see the TS/Babel output for a for/of loop.  That's pretty bad, too.

If TypeScript actually got sum types/discriminated unions (as they claim they will), it might be very useful. But I think that's still not even agreed upon for inclusion.

Apparently that's a thing already:
https://www.typescriptlang.org/docs/handbook/advanced-types.html

Code: (javascript) [Select]

type Shape = Square | Rectangle | Circle;

function area(s: Shape) {
    switch (s.kind) {
        case "square": return s.size * s.size;
        case "rectangle": return s.height * s.width;
        case "circle": return Math.PI * s.radius ** 2;
    }
}

The compiler does some static analysis and automatically narrows the type in the switch cases, so that you can access the relevant members without an explicit type cast.  That's why I felt it was trying to be too clever for its own good, but I guess I can see the reasoning for it.

Good to see that updates are still being made.

I'd like to do an updated build of miniSphere for mac, when would be a good time for me to grab the source?

(I.e. when no major changes are about to happen)

I already started (sporadically) working on miniSphere 5.0 so there are breaking changes on the trunk already, but you can build against the v4.5.11 tag ("git checkout v4.5.11")--or even just download the tarball:
https://github.com/fatcerberus/minisphere/releases/download/v4.5.11/minisphere-4.5.11.tar.gz

I have a pretty long backlog of stuff I want to implement for 5.0, so v4.5 will be current for quite a while still.

Found a nice feature of miniSphere that Sphere 1.5 doesn't have which is a symptom of the older JS engine used by 1.5; the JSON object and methods are available in miniSphere - I've been fiddling with Tiled map editor and with miniSphere I can save a Tiled Map as JSON and load it incredibly easily - sure I could write a script to load it a different way but 5 lines rather than 50 is nice .

Ran into a not so nice feature of miniSphere for mac again - for some reasons when fiddling with images and particularly cutting up a surface you lose your alpha channel, Fat Cerberus, - I think we talked about this issue before but you could not reproduce it on a PC.

I'm wondering if it's a problem with Mac Allegro (or my compilation of Allegro such) though I can't think how to debug that at the moment.

In other news 4.5.11 runs with no noticeable differences I had to make the same two changes to the source I made before to get it to compile and run (rename the function panic and put in the path hack).