I'm considering making the Game class an official part of the Sphere v2 API.  Currently Sphere v2 has no intuitive way to pass options to the game on startup, other than adding an API that the game would have to access manually (like Sphere.Game.arguments or something), because the main script is run directly--there's no game() function like in 1.x.

See:
https://github.com/fatcerberus/minisphere/issues/166

This would avoid the need to do new Game().start() in every game's main script--the engine would do that automatically.

Just implemented the change described above.  The template now looks like this:
https://github.com/fatcerberus/minisphere/blob/master/assets/template/src/main.mjs

Exporting a Game class is optional, but methinks it will make for much easier-to-understand tutorials.  The alternative is having module-level code with global variables, Dispatch API calls (or Thread.create) and a flipscreen loop, which makes the whole thing a lot more difficult to introduce to the uninitiated.  Now you just have to introduce the concept of a class and the rest will be self-explanatory.

Overall, miniSphere 4.6 is shaping up to be a much bigger release than I originally planned.  It's going to end up being pretty close to the "definitive Sphere v2 experience", I think.  Which is good: the sooner I can stabilize the API once and for all, the better.

I'm considering retiring the Ubuntu PPA for miniSphere in 4.6 and switching to snap packages instead:
https://www.ubuntu.com/desktop/snappy

The PPA is a nightmare to maintain.  Every Linux release requires me to build at least 3 times: Once normally with make, then once each for x64 and x86 with pbuilder to ensure everything will go smoothly under Ubuntu's build sandbox.  If I forget to test with pbuilder and upload, and the build fails, Launchpad won't allow me to re-upload the package without bumping the version number.  And now it's about to get even more involved (5 builds), because I'll need to maintain separate packages for Ubuntu 16.10+ thanks to Allegro 5.2 changing the package names.  It's just a complete mess, and I don't feel supporting the most popular Linux distribution should be this hard.

Windows releases are easy: Build everything in MSVC (once!), then run Inno Setup to build the installer, test it, and upload it to GitHub.  Snap, from what I'm seeing, looks to bring that same painless workflow to Linux packaging.

Thoughts on making such a change?

If building is a nightmare and just takes up precious time you could be using to be productive instead, I'm all for this. I'm going to have to get used to Snap packages though.

I don't feel supporting the most popular Linux distribution should be this hard.

I completely agree with this. You'd think it would be easier, considering there are so many people who have to deal with it on a daily basis...

It seems like making and uploading Snap packages will be easy, so that's no problem.  What's holding up the release is that I found out I'm missing most of the surface blitting functions (surface.zoomBlitSurface() et al.) so I'd prefer to implement those first.

For those curious exactly what's missing compared to Sphere 1.5, here's the list of unimplemented legacy functions in miniSphere 4.5.11:
* BezierCurve
* Filled/Outlined/GradientComplex
* CreateSpriteset
* ExecuteZoneScript
* GradientLine
* Get/SetLayerAngle
* SetLayerScaleFactorX/Y
* LoadSoundEffect + all soundeffect methods
* surface.bezierCurve
* surface.gradientLine
* surface.lineSeries
* surface.zoomBlitSurface, transformBlitMaskSurface, etc.

I've narrowed that list down a bit, notably SoundEffect is now fully supported.  The blitting functions are big though, so even though it's not a showstopper for 4.6, I want to do them anyway.

On a sidenote, I still don't understand the purpose of the Complex primitive, though I have seen a few games (notably some of Radnen's) that use it...

So apparently Sphere 1.x implements Complex in OpenGL by drawing it pixel-by-pixel using GL_POINTS.  *shudder*  Even with a modern GPU I can't imagine that being very efficient.  And in any case it won't work properly with miniSphere's fullscreen scaling method.  I'll have to see if I can come up with a different approach.

I'm trying to have a think through what the API is missing vs the "dream" API.

The key things I can think of at the moment are:

- brevity, on a per function or per interface basis sphere v2 methods are often longer/more flexible than wanted in common cases, I guess miniRT is meant to help with this, but sphere v1 functions may run faster for some things at that point, consideration point rather than any specific actions at the moment.

- fast graphics editing abilities as all images and surfaces are pushed to the graphics card if you want to edit them it's slower than you might like

The Core API is low-level by design-and usually more performant when used properly because it more closely matches how things work at the hardware level, particularly wrt Galileo.  That's why miniRT exists, to provide a more high-level abstraction for common use cases-and is generally the preferred API for user-level code.  Hence why I've decided to promote miniRT to an official part of Sphere v2

So apparently Sphere 1.x implements Complex in OpenGL by drawing it pixel-by-pixel using GL_POINTS.  *shudder*  Even with a modern GPU I can't imagine that being very efficient.  And in any case it won't work properly with miniSphere's fullscreen scaling method.  I'll have to see if I can come up with a different approach.

I can't imagine that the complex primitive is very important, though. I never even bothered implementing it, even in the faster GL driver I wrote for Sphere 1.6, and I never had any issues.

Yeah, that's why I haven't implemented it until now either.  Radnen used it a lot in his games but otherwise it didn't seem to get much use.

I also wouldn't look too much at how the old Sphere drivers worked, they tended to be assuming a very fill-limited architecture, rather than vertex-limited. A much smarter solution would just have been to do per-scanline fills using GL_LINES. There was a reason that I decided to write my own, although doing so strengthened my resolve that an API with persistent primitives was needed for performance that was significantly higher than a software solution.

That was a part of what lead my first prototypes of Galileo, and I determined that you got a HUGE boost in performance by forcing triangle-based geometry definitions (slow geometry is hard to specify, fast geometry is simpler), and by encouraging persistent geometry (all modern graphics frameworks use this in some manner). The design also lends itself to "accumulator" based asynchronicity, as it was implemented in Sapphire, which vastly improves performance.

So it turns out that there are a few bugs caused by miniSphere's fullscreen implementation:
https://github.com/fatcerberus/minisphere/issues/167
https://github.com/fatcerberus/minisphere/issues/170

This affects Galileo, which is unfortunate.  It will need to be fixed, but I'm not sure if I'll do it in 4.6 or hold off until 5.0.  Anyway, the gist is that, because miniSphere applies a scaling transformation to everything drawn to the backbuffer while in fullscreen, primitives like ShapeType.Lines don't work correctly.  The lines end up "thinner than a pixel" because they are drawn at the native resolution and only the vertices get scaled.

Not sure of a good fix yet.  My idea was to use my own backbuffer without scaling applied and draw that to the "real" backbuffer as a textured quad, but that could be a performance issue?  I'm not sure.

I had noticed a few inexplicable graphical anomalies when using minisphere, not sure why I hadn't mentioned them before

In the attached you can see a screenshot of text drawn with the system font over the system windowstyle drawn with a colour mask - there's an odd white line on the window, it goes away in windowed mode but is there in full screen - is this related to the issue you're talking about?

(The red circles behind are something I've been messing around with brownian motion spinning rings as a background they're "fun"...)

That's indeed related--and hopefully goes away with the same fix--but no, it's not the same issue.  The bug in your case is due to an interaction between fullscreen scaling and font atlasing.  How miniSphere's font renderer works is to load all font glyphs into a single, large atlas texture.  When using an integral scale factor like 1x or 2x, you can accurately address individual texels.  When using a non-integer scale, however, as often happens in fullscreen, the GPU starts interpolating texels and sometimes you end up pulling in stuff from adjacent glyphs.  Hence the weird artifacts.

Incidentally, tilesets and spritesets are loaded the same way, so the map engine suffers from this bug too.

I use zoombBlitted single pixel width shapes in the project I've been working on and then generally display quite well in miniSphere.

I also use a surface that I draw graphic primitives (including rectangles with a single pixel outline) and images to and then zoomBlit and it displays well full screen - so there is a way to draw and scale without problems.