Just implemented atlasing for RFN fonts.  The original implementation used individual ALLEGRO_BITMAPs for each glyph, which I suspect was the main reason for minisphere's horrible text-rendering performance up to now.  The drag became especially noticeable in Spectacles when the console was displayed.  Now it seems to be much better!

Awesome!

Were you able to figure out the windowstyle issue? I know it may break on 1x1 sized images, but what about 2x2 or larger?

See, the odd thing is, that big window test?  It displays fine if I force Allegro into OpenGL mode.  It's only with D3D (Allegro's default under Windows) that the issue shows up.  I'll have to test with larger backgrounds though.  Honestly I haven't really worried about it since nobody's going to be using 1x1 windowstyles in a real game and the more typical sizes seem to render fine.

So I just finished implementing zones, which completes the map engine. . Still missing APIs I'm sure, but the map engine itself is, as far as I can tell, a complete functional recreation of Sphere's.

Now... what exactly do I need to do to get Lithonite working?  It seems to work somewhat in minisphere, but many of the zone types are completely non-functional and others are glitchy--for example slopes cause me to get stuck in diagonal movement eternally, and jumping off ledges makes my guy fly off the map completely out of my control.  Since the APIs Lithonite needs are all implemented and should be behaving identically to Sphere, I fail to understand what is causing the glitches.

Also: Lithonite reminded me that I never actually implemented tile animation... I should get on that!

So that didn't take long--I got Lithonite working!   Little-known fact about SetDelayScript(): Despite the name of the function, it actually queues scripts, rather than setting one at a time.  Not supporting this was the reason it didn't work for me, and likely the reason it doesn't work properly in SSFML either--it only tracks one delay script at a time.

Not supporting this was the reason it didn't work for me, and likely the reason it doesn't work properly in SSFML either--it only tracks one delay script at a time.

Good to know!

Also I really need to implement more of the API esp. zone and trigger execution nuances, etc. I just need to find the time sometime to do it.

Also I really need to implement more of the API esp. zone and trigger execution nuances, etc. I just need to find the time sometime to do it.

I have to say, recreating Sphere like this, I have a new respect for the built-in map engine.  I always wrote it off because of the all the bugs in the Sphere 1.x implementation, but now I think it's pretty great.  The fact that minisphere fixes a lot of the aforementioned bugs (some of them without conscious effort on my part even) makes it that much more awesome.

What's the best way to implement tile animation?  My current implementation just does a brute-force traversal of the map, counting frames for each tile and switching them in-place, but I have a feeling this is going to end up being a performance drain on larger maps.  I looked at both SSFML and Sphere's source, but I can't make heads or tails of the lookup method either one uses.  Care to enlighten me?

Edit: Okay, I really need to shut up.   Leave me to my own devices for an hour and I figure stuff out every single time.  Instead of traversing the map, I set up a system where I walk the tileset and, at render time, remap the tile indices passed in from the map engine to their current animation state.  Funny thing about it: I ended up looking at the Sphere source again after doing this, and it turns out Sphere uses this exact same system, the code for it is just a lot sloppier.

Wow, Lord English. You're making amazing progress with this. I wish I had enough time to check it out!

Edit: Okay, I really need to shut up.   Leave me to my own devices for an hour and I figure stuff out every single time.  Instead of traversing the map, I set up a system where I walk the tileset and, at render time, remap the tile indices passed in from the map engine to their current animation state.  Funny thing about it: I ended up looking at the Sphere source again after doing this, and it turns out Sphere uses this exact same system, the code for it is just a lot sloppier.

Sane here. I walk the tileset, find the correct timings (just once), and then just use them at the appropriate time intervals. I only update the timings when the user sets the tile animation in code.

BTW I just want to add between you me and FJ, working on our own engines has really helped us see how Sphere works internally and I'd say we'd all know at this point how to hack sphere into submission JS code-side.

Speaking of tilesets, I just implemented tile atlasing!  My refcounted image system really helped here, I just have it create subimages off of the atlas, then free the atlas--when the last subimage (tile) is freed, the atlas gets freed automatically.  The best part is that the subimages are normal image_t pointers, so the atlas doesn't even interfere with things like SetTileImage, which can just free and replace the image pointer as normal.

Well, minisphere has been a far bigger success than I ever anticipated.  Not only does it beat Sphere 1.5 in performance hands-down, but it runs the vast majority of existing Sphere games better than Sphere does.  I've known Sphere was buggy for quite a while, but I never realized it was quite this bad until I started comparing the two engines side-by-side later in development.

This is the part where I'll be honest: minisphere's development was largely motivated by self-interest.  After I finished the Spectacles battle engine, I started work on the field, and then realized that Sphere's map engine doesn't react well at all to blocking logic, UpdateMapEngine be damned.  For the longest time I thought it was a bug in the Specs threader, but no, it turns out it has something to do with Sphere's frameskipping logic causing it to skip a ton of FlipScreens (exactly equal to the number of frames spent in the MapEngine loop, interestingly enough), which I didn't fully realize until I got minisphere's map engine up and running and the threader behaved just fine there.

Whatever the case, I'm confident to say that the version of minisphere as it exists on GitHub right now is quite suitable as a drop-in replacement for Sphere 1.5.  I'll be posting minisphere 1.0b2 soon.  It would be a release candidate instead of a beta, but I haven't implemented networking support yet.  I want to at least do that before going gold with 1.0.

This is the part where I'll be honest: minisphere's development was largely motivated by self-interest.

So was TurboSphere. I was frustrated by not being able to do N-body physics and 3D matrix transformations in script, and I was disappointed in the polygon drawing performance.
The best engines solve actual problems that you run into

New API function: IsSkippedFrame().  This returns true if the next FlipScreen will be ignored, allowing the game to skip rendering for a frame to maximize the effectiveness of frame skipping.  The engine already does this internally for primitives and blits (except for render-to-surface, which is exempt for obvious reasons), so figured I may as well expose it to script.

Since you've implemented the map engine, can you run my NShoot demo, Artyxx in minisphere? I want to find out if the issues it had in vanilla 1.5 still exist, since I know that I also had sloppy code at the time (e.g. wrote an unoptimized particle system script NPart b/c the beta ParticleSystem didn't have collision or the ability to access individual particles for me to script collision myself) but was running against a whole bunch of map engine ridiculousness too.

Hm, seems I can't even get past the intro.  minisphere fails with "invalid base value" (I haven't located the cause yet, but basically this is Duktape's obtuse way of calling out attempts to use undefined as an object--probably due to an API I haven't implemented yet), and Sphere 1.5 fails at the same point with an error on SetLayerRenderer (invalid integer "Base" for argument 1).