I see. Even setting that back to 2.0 makes it return the same error message, though. I'm not sure why. Also, it can't hurt to have the full list of extensions in there, right? I think I'll be using pretty much all of them anyway. (Except for maybe legacy-api, but that depends on what that specific extension includes.)

I'd include legacy-api just to be safe.  It's basically a catch-all for any functions directly taken from the Sphere 1.x API that weren't reassigned to a Sphere 2.0 extension, so I don't really have a concrete list of what it covers.   One thing for future work would be to standardize exactly what constitutes Sphere 2.0 and go from there.  Ah well, something for another day.

Anyway, I'll look into the S2GM issue tonight.  Thanks for testing as always.

Okay, that's a documentation bug and is on me.   There are actually several things wrong with the example: JSON requires property names to be quoted, double quotes used throughout, and doesn't allow a trailing comma after the last array entry or property.  Here's a properly-formatted file:

Code: (javascript) [Select]

{
    "name": "Hunger-Pig Feeder 5000",
    "author": "Some Weird Guy",
    "summary": "Get eaten by the hunger-pig in your closet",
    "resolution": "3840x2160",  // in awesome 4K HD!
    "script": "scripts/main.js",

    "minimumPlatform": {
        "recommend": "minisphere 3.0 or later",  // note: for display purposes only
        "apiVersion": 2.0,
        "extensions": [
            "sphere-legacy-api",
            "sphere-obj-constructors",
            "sphere-obj-props",
            "sphere-map-engine",
            "sphere-rng-object",
            "sphere-s2gm",
            "sphere-spherefs"
        ]
    }
}

I'll update the documentation.  I also added a log line when an S2GM file can't be parsed to avoid confusion in the future.

Follow-up note: JSON also doesn't allow comments.

That made it work, thanks! Man, I didn't know JSON parsing was so much stricter, I thought it was pretty much just a JS object...

On a related note, the deb package associates sgm files with minisphere (at least, I *think* so... if I didn't do this before by myself). But not the s2gm. That opens with a text editor by default, and is recognized as a regular text file (so even associating it with minisphere will make *all* text files associate to minisphere).

That's weird... the debs are built using pbuilder-dist which just runs "make" and "make install" in a chroot and then packages the installed binaries.  I didn't add any file association logic to it.  Somehow the package manager must know that .sgm files should be associated with minisphere, but I have no idea how.

And yeah, JSON is ridiculously strict.  I could have just eval'd the manifest but that leaves open the possibility of making malicious (but ultimately harmless of course) S2GMs that enter infinite loops or other such shenanigans.  Since it's just metadata, I figured parsing it as pure JSON was better.

Follow-up note: JSON also doesn't allow comments.

The "traditional" way around this is adding "comment" elements to objects.
Some parsers accept comments anyway, though. I personally wish they all did 

We have Doug Crockford to blame for that.  He was apparently all "OH NOES people might put nonstandard parsing directives in the comments!!!1111"

That's weird... the debs are built using pbuilder-dist which just runs "make" and "make install" in a chroot and then packages the installed binaries.  I didn't add any file association logic to it.  Somehow the package manager must know that .sgm files should be associated with minisphere, but I have no idea how.

Never mind me, then -- I might have associated the filetype myself at some point. It works perfectly and is definitely something to add by default if you ask me.

I guess I'll look into it before release, then.

By the way, true to form, I decided to tackle the letterboxing issue now.  minisphere's window scaling/resizing logic was in need of some refactoring anyway.  main.c being the oldest file in the codebase, it's quite a mess of spaghetti code compared to the rest of the engine and could definitely use some cleanup sooner rather than later.

minisphere 3.0rc5 is now available, with fixes for several bugs found in 3.0rc4 by DaVince, and one fairly large change that really shouldn't have been done during code freeze but oh well: I added letterboxing support.  Linux deb packages also now automatically associate Sphere file types (.sgm, .s2gm, .spk) with minisphere.

Just posted 3.0rc6, the final release candidate.  miniRT has been overhauled and is now provided in module form, loadable using require('miniRT/threads'); etc.  Full API documentation for miniRT is finally included as well, so hopefully that'll make the library more discoverable.  It's definitely worth looking into if you don't want to reinvent the wheel--it includes a lot of useful stuff like my threading library, a version of Scenario, and a text console with built-in command parser (you just have to provide the command names and implementations!).

This will be the final 3.0 release candidate.  I don't see any further changes being needed and the engine has been bug-free in my own use, but if anything else comes up I'll just make the fixes to the final release without doing more RCs.  If I don't draw the line here, my perfectionism is going to be the death of me.

So anyway, go download rc6 and have fun!

I'm running into an issue when I try to put a game into windowed mode with F10 - it stays fullscreen, but the windowed game goes in the corner without any window border and everything else is black.

What's your graphics card?  Is it an Intel iGPU?  I have this too on my laptop (Core i3-5500U), but it affects all OpenGL games, not just minisphere--I think it's a driver issue with the newer Intel chips.  So there's not a lot I can do short of putting Allegro in D3D mode (which disables shaders).

It works fine when I made minishpere use my dedicated nVidia card. Thanks for the lead.