If it helps, here's a comparison of the implementations of FlipScreen() and screen.flip():
v1: https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/vanilla.c#L1851-L1856
v2: https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/pegasus.c#L1224-L1230

The only difference is the framerate variable used, which for v1 defaults to 0 (unlimited) while screen.frameRate (v2) defaults to 60, and that screen.flip() resets the clipping rectangle afterwards.  So maybe the lack of frame limiting in v1 by default was what was causing your issue?

Idea for new feature: 3D rendering, complete with projection support, camera, etc.  Sphere has always been a 2D engine, but it would be a nice bonus if we could also do basic 3D stuff with it.  Things like loading model files, etc. could be added in time.

I wonder if a maximum frame rate shouldn't be enforced even in v1, like eg. a default frame rate of 240 or so. I've managed to lock my entire system up once just by accidentally getting it stuck in an infinite loop. (Note: I don't remember how it happened, just THAT it happened.)

...Actually, scratch that. That might have been a loop without any rendering/flipping going on at all. I dunno. Just something was weird.

Idea for new feature: 3D rendering, complete with projection support, camera, etc.  Sphere has always been a 2D engine, but it would be a nice bonus if we could also do basic 3D stuff with it.  Things like loading model files, etc. could be added in time.

I was going to ask for 3D the other day, doesn't feel like the API needs much expansion (other than allowing us to fiddle with transformations more as already mentioned) the main thing that would need work I guess is the rendering code under the hood.

As in you can already set Z coordinates BUT if you keep them between +1 and -1 they seem to do nothing and if you go outside of that range then the shape isn't drawn.

Is it currently possible for a game to set the window icon?

As in you can already set Z coordinates BUT if you keep them between +1 and -1 they seem to do nothing and if you go outside of that range then the shape isn't drawn.

I never figured this out myself.  I guess something to do with the Z buffer?  It caused a few bugs in the past where I forgot to zero a vertex buffer in the engine and ended up with nothing getting drawn.  It took me a while to figure that one out.

It looks like most of the useful 3D utility functions are not in Allegro 5.0.  So I'll need to require 5.2 or later.  A non-issue for windows releases (allegro is static linked), but may be a problem for Linux.  We'll see.

Is it currently possible for a game to set the window icon?

Not at runtime (yet); any custom icon should be 32x32 and packaged in the dist as icon.png.

As in you can already set Z coordinates BUT if you keep them between +1 and -1 they seem to do nothing and if you go outside of that range then the shape isn't drawn.

I never figured this out myself.  I guess something to do with the Z buffer?  It caused a few bugs in the past where I forgot to zero a vertex buffer in the engine and ended up with nothing getting drawn.  It took me a while to figure that one out.

It looks like most of the useful 3D utility functions are not in Allegro 5.0.  So I'll need to require 5.2 or later.  A non-issue for windows releases (allegro is static linked), but may be a problem for Linux.  We'll see.

My current build of minisphere 4.5 for mac is a) statically linked and b) already using allegro 5.2 so non-issue for macos support.

Is it currently possible for a game to set the window icon?

Not at runtime (yet); any custom icon should be 32x32 and packaged in the dist as icon.png.

That's fine, that's what I meant.

I wonder if a maximum frame rate shouldn't be enforced even in v1, like eg. a default frame rate of 240 or so. I've managed to lock my entire system up once just by accidentally getting it stuck in an infinite loop. (Note: I don't remember how it happened, just THAT it happened.)

As long as a script is calling FlipScreen() or DoEvents() regularly, or using the Sphere v2 event loop like in the example project, then you will always be able to close the window even if the CPU is pegged.  Of course if you have an infinite loop that doesn't do any event processing, that will cause problems, but there's not really anything miniSphere can do about that.  JS is single-threaded so it comes with the territory, unfortunately.

So I was going to fix all the spriteset bugs... but then I found out, Sphere 1.x does this for all functions that accept a spriteset parameter:
https://github.com/sphere-group/sphere/blob/master/sphere/source/engine/script.cpp#L1199-L1660

Over 450 lines of code just to read in a spriteset argument.  You see, Sphere 1.x does something very strange with spriteset parameters that it doesn't do for any other object: It reconstructs a native spriteset from the properties of the spriteset object passed in--as opposed to just having the object carry a native pointer and reading that back (like miniSphere does).  This should be a lot of fun to try to emulate.  I was originally going to fix it for miniSphere 4.6, but now I'm thinking it might be better to hold off on tackling that one.  It's not going to be fun, I can see that already.

Here's a peak at all the enhancements and fixes that'll be in miniSphere 4.6:
https://github.com/fatcerberus/minisphere/blob/master/CHANGELOG.md

And here're the release notes (listing breaking changes):
https://github.com/fatcerberus/minisphere/blob/master/RELEASES.md

Well, a lot of the lines in that function are because one: Sphere 1.x does all GC rooting there manually (and does a lot of unnecessary GC rooting), and two: Spritesets don't have actual constructors/classes, so it is literally doing this in the most complicated way possible.

Yeah, I noticed all the GC rooting.  It should honestly have been enough just to root the spriteset object itself and then all its properties would be guaranteed to be reachable for the duration of the call.  Even then I'm not sure any GC rooting was necessary at all.  Oh well, it's very old code, I'll give it a pass.

Anyway, the main point I was getting at is that Sphere 1.x reconstructs an internal spriteset object on-the-fly every time it accepts a Spriteset as an API parameter.  That's not going to be fun to replicate because the structure goes 3-4 levels deep in spots and Duktape's API is stack-based like Lua.  It can be done and it's not even really challenging, just extremely tedious.  Unfortunately, there do exist games that rely on the behavior, so I'll bite the bullet sooner or later.  Just not now.

Here's a peak at all the enhancements and fixes that'll be in miniSphere 4.6:
https://github.com/fatcerberus/minisphere/blob/master/CHANGELOG.md

And here're the release notes (listing breaking changes):
https://github.com/fatcerberus/minisphere/blob/master/RELEASES.md

Is there any chance of getting direct access to transformation matrices and setting vector uniforms added to 4.6?

I'd really appreciate it if possible.