Yeah, I had no problems building it but I threw my hands up when I realized how much of a moving target the API must be for all the documentation out there to be so horribly broken.  I can understand constantly wanting to improve (being guilty of the same with minisphere), but if you're going to break things, at least try to keep some consistency in your API design.  It seems like they must rewrite the entire API layer every couple of months.  Geez.

I'm suddenly very thankful for Duktape following SemVer so religiously.

Building SM isn't so bad, assuming you get the actual SM source release instead of building it inside gecko. Then you download the MozBuild tools, run their terminal, go to the SM directory, and it's a matter of ./configure && make.

Hm, you're right, it really was that simple.  But the SM 38 source release is apparently broken - I ended up having to check out the entire Gecko repo and build it from there (against the esr38 branch).  Using the source release I got errors during configure about NSPR.

You need to either configure it to use the system nspr (default) or configure it to build its own. Fortunately, there is an effort underway to remove the NSPR dependency soon.

Also, SM is up to 45 now.

Is it?  Reading the wiki pages I got the impression that 45 was still in development/not released yet.

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/releases/45

The documentation on the MDN isn't quite up to date for 45 yet. But the changes aren't too bad from 38 (mostly removing deprecated versions of functions), and in general I've really only had a couple changes to make every release. Almost always they about half the changes are related to initialization.

New feature coming in the next release (3.3): Predefined colors.  The complete X11 set will be available, and you can access them as Color.White, Color.Red, Color.DodgerBlue, etc.  Each one is a property getter which returns a fresh color object, so that writing to the returned object doesn't modify the preset color.

Another useful enhancement is Font.Default.  This is a more Sphere 2.0 way to get the default system font.  There are also analogues for shaders (ShaderProgram.Default), audio mixers (Mixer.Default) and windowstyles (WindowStyle.Default).

Since the predefined colors all have alpha of 255, I'm also adding a fade method which only scales the alpha channel so that you can do:

Code: (javascript) [Select]

var translucentBlue = Color.Blue.fade(128);

Otherwise you would have to resort to the Color constructor for translucent colors.

New feature coming in the next release (3.3): Predefined colors.  The complete X11 set will be available, and you can access them as Color.White, Color.Red, Color.DodgerBlue, etc.  Each one is a property getter which returns a fresh color object, so that writing to the returned object doesn't modify the preset color.

+1, this is awesome.

Yeah, the Color API was always one of the weaknesses in Sphere.  I got spoiled working in C# where you can just say Color.Green or whatever, which is more convenient than writing out the RGB values and also makes the code more readable.

I'm also adding Color.of() to decode HTML color codes, e.g. Color.of("#ff0000") gives you red.  It also supports X11 color names, so Color.Red, etc. are actually redundant now.

edit: Oh, and also color_obj.name will give you the name of a color (or ARGB hexcode, if no name matches) so you can easily save it to a file.  Then you call Color.of(name) to reconstruct the color from the saved string.

I switched to xoroshiro128+ instead of Mersenne Twister for the random number generator.  This is the successor to the xorshift algorithm used in modern versions of both SpiderMonkey and V8 and is faster than MT as well as apparently higher quality.  The period is smaller (2^128 vs. 2^19937) but realistically there's no way you're ever going to exhaust all 340,282,366,920,938,463,463,374,607,431,768,211,456 states.

edit: I'm also going to add the ability to save and restore the internal state of the RNG by reading and writing RNG.state.  You can use this to prevent the player soft-resetting a game to get a different random result, if you wanted to prevent that, or even use it to implement time travel mechanics.  For xoroshiro128+, the entire internal state is representable as a 32-digit hex string, making it easy to save and restore in a JSON file.  That's a far cry from Mersenne Twister, which has 2.5KB worth of state!

edit: I'm also going to add the ability to save and restore the internal state of the RNG by reading and writing RNG.state.  You can use this to prevent the player soft-resetting a game to get a different random result, if you wanted to prevent that, or even use it to implement time travel mechanics.  For xoroshiro128+, the entire internal state is representable as a 32-digit hex string, making it easy to save and restore in a JSON file.  That's a far cry from Mersenne Twister, which has 2.5KB worth of state!

Awesome! I like the ability to save the rng so that people can't save-scum a game for awesome items.

minisphere 3.3.0 is out now.  There should be no breaking changes in this version, and it includes both the predefined colors and the RNG enhancements mentioned earlier.

In minisphere 3.3, besides named colors, I combined the functions of BlendColors() and BlendColorsWeighted() into a single function: Color.mix().  The function signature is:

Code: [Select]

Color.mix(color1, color2[, w1, w2]);

    Calculates a weighted average of two colors.  `w1` and `w2` are optional
    and specify the relative weights of `color1` and `color2` respectively.  If
    the weights are omitted, the mix is 50/50.

This, combined with the new named colors and Color#fade(), makes working with colors much easier:

Code: (javascript) [Select]

TurnPreview.prototype.render = function()
{
	var alpha = 255 * (1.0 - this.fadeness);
	var y = -16 * this.fadeness;
	SetClippingRectangle(0, y, 160, 16);
	Rectangle(0, y, 48, 16, Color.Black.fade(alpha * 0.75));
	OutlinedRectangle(0, y, 48, 16, Color.Black.fade(alpha * 0.125));
	DrawTextEx(this.font, 24, y + 2, "next:", Color.Gray.fade(alpha), 1, 'center');
	Rectangle(48, y, 112, 16, Color.Black.fade(alpha * 0.75));
	OutlinedRectangle(48, y, 112, 16, Color.Black.fade(alpha * 0.125));
	for (var id in this.entries) {
		var entry = this.entries[id];
		for (var i = 0; i < entry.turnBoxes.length; ++i) {
			var turnBox = entry.turnBoxes[i];
			var pictureColor = entry.color.fade(alpha);
			Rectangle(turnBox.x, y, 16, 16, pictureColor);
			OutlinedRectangle(turnBox.x, y, 16, 16, Color.Black.fade(alpha * 0.25));
			DrawTextEx(this.font, turnBox.x + 4, y + 2, entry.name[0], Color.mix(entry.color, Color.White), 1);
		}
	}
	SetClippingRectangle(0, 0, GetScreenWidth(), GetScreenHeight());
};

The code above was littered with CreateColor() calls before and was harder to read as a result.

Heads up, guys: I'm going to break Sphere 1.x compatibility in a major way in minisphere 4.0.  I don't have an idea what the full extent of that will be yet, but it's 100% certain that existing code will not run in minisphere 4.0 without major modifications.  I will probably maintain minisphere 3.3 for a while after the v4.0 release, but I figure it's time to start looking to the future of Sphere, and there are a bunch of enhancements I've wanted to make to the way the API is structured that I haven't been able to do up to now, as it would have meant breaking legacy code.

Basically, maintaining Sphere 1.x compatibility is holding back any further modernization of the API, so I think it's high time I made a clean break.  This has actually been my plan since the project started, but I've held off because... well, we're still kind of dead here, what's the rush?

It will be possible to write a shim of course, I'm just not sure yet whether I'm going to be the person to write it.  It's probably not worth the effort on at this point, to be honest.  minisphere 3.3 will continue to run Sphere 1.x code even if Sphere 1.x itself eventually stops working completely.

I'm really excited about Sphere 2.0, guys.

Here's my plan: minisphere 4.0 will provide a very minimal and low-level set of functionality, for example, Galileo gives you Images, Surfaces, Colors, Groups and Shapes and that's it.  And Images and Surfaces are themselves pretty basic: Images are read-only and can only be used as textures for Shapes; and Surfaces are dumb render targets with no drawing methods of their own (but can be converted to Images if needed).  No more legacy primitives like Rectangle, GradientCircle, etc. and in general no more huge, monolithic all-in-one API.

Of course, providing only low-level functionality out of the box would make Sphere quite unappealing to newbies.  So my solution for that is to leverage the CommonJS module system to provide extra system modules (implemented in JS) along with the engine to replace some of the Sphere 1.x "all-in-one" functionality.  This is what "system scripts" were supposed to be for Sphere 1.x, but looking at the selection of scripts available there vs. what's provided by the engine already, it... doesn't really seem to have panned out.

For example, take my prim module:
https://github.com/fatcerberus/minisphere/blob/master/assets/system/modules/prim.js

prim provides stuff like prim.rect() or prim.blit() which replicate the Sphere 1.x graphics functions but with a more modern approach to the API:

Code: (javascript) [Select]

const prim = require('prim');
var myImage = new Image('test.png');
// note: `screen` is a Surface object!
while (true) {
	prim.blit(screen, 0, 0, myImage);
	prim.circle(screen, 30, 30, 20, Color.Chartreuse, Color.Black);  // gradient circle!
	screen.flip();
}

Other candidates for standard system modules are stuff like Scenario, my cooperative threading engine (basically: SetUpdateScript() on a ton of steroids), Link, etc.

This naturally also makes Sphere more newbie-friendly since we can point people at these modules instead of going straight to the low-level APIs, without us needing to bloat the core engine with high-level stuff as a compromise.