@Radnen
I figured out the Blockman crashes.  The getPixel calls were fine, none were out of range--though I added bounds checking anyway, since Sphere also checks it (an out of range getPixel() will throw in 1.5).  The crash was here:

Code: (c) [Select]

void
update_persons(void)
{
	bool is_sort_needed = false;
	
	int i;

	for (i = 0; i < s_num_persons; ++i) {
		if (s_persons[i]->leader != NULL)
			continue;  // skip followers for now
		update_person(s_persons[i]);
		is_sort_needed |= has_person_moved(s_persons[i]); // <-- CRASH HERE
	}
	if (is_sort_needed) sort_persons();
}

As part of update processing for persons, they can end up being deleted (if a command generator script destroys one, say), which is exactly what happened here.  Once I reproduced the crash, I checked the variables.  i = 3 and s_num_persons = 3, which meant one was deleted, but it was still trying to access the person structure, causing a crash.  Should be an easy fix.

1.1b5 is out.  A couple bug fixes in this one, as well as two new APIs: Async() (required for promise compliance, see changelog) and Assert(), very useful for debugging.  This will be the last beta ahead of 1.1, now I want to concentrate on finishing up the API documentation before release, and maybe write that config tool...

I decided to go in a different direction with the customizable key mappings.  I added a new API, SetPlayerKey(), to change the key mappings at runtime; any such changes are then saved out to disk on shutdown.  What I'm thinking is, I will add commands to miniconsole so that any game using the minisphere Runtime can have its keymap changed by the player through the console.  miniconfig as a separate thing will still exist, of course, but its scope will be enlarged: Allowing key mappings to be changed for any game minisphere has previously run or otherwise knows about.

This will allow me to work on miniconfig at my own pace, rather than having to rush it to make the 1.1 release.  I can release it separately when it's ready. :-)

I like the idea. I've always wanted many config related options to be game specific. Hence why I never used the config.exe tool to set up key mappings, that and having the ability to set them and save them in game is always nice.

See the screenshot below.  Any games using miniconsole will get these commands by default.

It's been a long ride, but minisphere 1.1 is finally ready for primetime!   So um... go download it!  See the changelog in the OP for all changes since 1.0.x, but the highlights are:

• 64-bit support


• miniRT


• Galileo API


• Console engine


• Performance improvements

The download is a lot bigger this time (as in over 7 MB) not only because of the new Console engine but also because it includes a new Spectacles battle engine demo to show off the power of miniRT.

@Radnen
So I finally got around to implementing gradient circles, and was therefore able to test out the cave lighting effect in Blockman.  Results: Success!  Not only does the effect look great, but it runs at full speed.  See screenshot below.

So, um... I got animation support working. Which means the KR intro now works!

Damn is libmng bloated though.  It added about 200KB to the engine executable size.

Amazing and awesome. KR is a buggy mess that likes to not work properly on some versions of Sphere, so it might be an interesting test case for minisphere.

Did you add your own mng support, or was it in Allegro?

Damn is libmng bloated though.  It added about 200KB to the engine executable size.

No, I had to do it myself using libmng and loading the frames into locked surfaces.  You'd think Allegro would have it, but nope.  Luckily I was able to use the Sphere source as a reference again, to lessen the learning curve a bit.

Edit: It's funny, I wasn't originally going to do it, I was just going to have some stub APIs in place to allow games using the functions to get by, but once the stubs were in place, I said ah, why not.  I'm used to the hassles of compiling dependencies on Windows by now, so what's another library?

Edit 2: I got the 64-bit Windows build of minisphere back down to under 1.7MB by rebuilding everything optimizing for size instead of speed.   I don't appear to have taken a visible performance hit by doing so, but time will tell...

minisphere 1.1.1 is up.  This adds the animation support and finally fixes GradientCircle, which I've been too lazy to fix up until now.  Also, the windowstyle rendering should be fixed on all platforms as I added a workaround (i.e. tile in software) for images < 16x16.

I've decided to go to an Allegro-style "tick-tock" versioning cycle for minisphere: Even-numbered versions (e.g. 1.0) are stable and only receive bugfixes, while odd versions (e.g. 1.1) are considered WIP and can get new features (or have them removed) at any time.  I like this setup because it allows more public testing to be done on new features before they get committed to a genuine Stable release.

Just added shader support today. 

Code: (javascript) [Select]

var shader = new ShaderProgram('pixel.glsl', 'vertex.glsl');  // this might be changed to take an object argument
var image = new Image('ScottSucks.png');
var shape = new Shape([
	{ x: 10, y: 10 },
	{ x: 110, y: 10 },
	{ x: 110, y: 110 },
	{ x: 10, y: 110 },
], image);
var group = new Group([ shape ], shader);

Initial tests are promising!

minisphere 1.1.2 out now, now with GLSL shaders!

You know, I'm beginning to think I'm releasing these faster than anyone can test them...   Good thing my own in-house tests are very thorough!

1.1.3 has been posted.  Just a maintenance release, nothing groundbreaking this time.

At this point it seems the only thing I'm really missing is a particle engine.  Sphere 1.6 had one from what I understand, and that's one thing that would definitely benefit from being implemented natively, I think.  It can be done in script, but I'd imagine it might be slow then.