It might still be useful to _render_ in floating-point thoigh, e.g. In the case of procedural audio.  Allegro automatically mixes it down, which is nice.

Thinking about the JS map engine some more, I'm beginning to think it might actually be outside the scope of the minisphere project itself.  It would be a great thing to have certainly, I just think it would be healthier as a project if it was maintained independently, instead of shipping with the engine.

The classic map engine will be kept in the minisphere 2.0 core for backwards compatibility (and as a convenient starting point for newbies), but I'd say any map engine projects going forward would be better off in the long run as independent projects.  Especially with Sphere Studio's plugin system being actually usable now, map engines don't have to be shackled to the RMP format anymore and thus there's no longer any need for the "one map engine to rule them all" model used thus far.

@DaVince Looked at that Tiled editor, it's pretty neat, but I'm not a big fan on the XML format for maps.  It also seems to be more complex than necessary and would require changes to the engine itself to fully support (e.g. changeable render order for tiles... weird, and kind of pointless).  And are there even any XML parsers for JS?  I'm not familiar with any if there are.

Tiled can also output JSON, and many other formats.

Do you lose the full feature set if you do though?  or would it be like saving an MS Word document in RTF, it keeps most of the formatting but you lose the more intricate stuff?

New minisphere 2.0 beta up with a few more engine improvements and previewing the recent Sphere Studio overhaul.  minisphere is finally starting to look like a real development platform!

Awesome work.

Do you lose the full feature set if you do though?  or would it be like saving an MS Word document in RTF, it keeps most of the formatting but you lose the more intricate stuff?

From what I could see, it makes a perfect copy of all the data in the map. I tried all the different layer types, tile rotation, objects, custom properties, basically all of the major features in the editor. See attached file.

I'm thinking I'm going release minisphere 2.0 as-is, with only basic file copy and SPK creation for Cell.  I started out a bit more ambitious than this, I wanted it to have various builders for maps, spritesets, etc. but that will require a bit more effort than anticipated--there's no way to specify collision data with only images, for example.  So implementing that will need more thought.

The only other improvement I might make for 2.0 is a new SGM format, probably JSON-based.  The current format is starting to show its age, especially in light of the recent SphereFS enhancements and such.

Want to hear something awesome?  Cell is completely compatible with Sphere 1.5.   I added a Cellscript to "In the Steps of the Blackfoot" (if anyone remembers, that was my first minisphere compatibility target), then used Cell to make an SPK from it and Sphere 1.5 ran the SPK with no issues.

I wasn't sure if it would work because I've had issues in the past with SPK creation where minisphere will read the package just fine but Sphere 1.5 either locks up or crashes when given the same package.  So it's good to know I finally got it right.

That's awesome!

Progress report:
2.0 release has been delayed somewhat due to unforeseen issues.  I wanted to release it last week, but decided to implement a game.sgm replacement... and that uncovered a few shortcomings in the way the engine is currently set up.

Long story short: JS context handling is broken.  minisphere uses a single Duktape context which is created at launch and whose pointer is stored in a global variable.  This is normally fine--only one game can be run at a time.  The issues show up when a startup game is used: calling GetGameList() creates new temporary sandboxes which share the global JS environment and clobber stuff.  This in turn causes weird crashes when switching games that are difficult to pin down.  Fixing this will require a bit of refactoring, not sure how much actual work is involved yet.

Cell is basically finished though, so that's good.

This was a huge issue in V8 and SM, too.

I for one don't really think that the game loading functions are that useful, and they go pretty hard against how modern JS engines actually work.

The way I implemented it in minisphere is actually pretty clean: ExecuteGame() is simply a longjmp back into main() which shuts down everything and restarts with the new game (Duktape uses longjmp itself so it tolerates such antics).  The fix for this is easy in theory: Duktape contexts are completely independent of one another, so sandboxing is trivial.  The main issue preventing a quick fix is that API functions are also registered globally.

Good news: I managed to fix the bug without a huge amount of refactoring.  Which is good, because the Duktape context wasn't even the half of it: There are file-scoped static variables all over the place, etc. that would need to be sandboxed as well.

The game.sgm replacement I came up with is nifty: It's JSON-based, and all properties contained in it are exposed to script by calling GetGameManifest().  This is useful for embedding game-specific data directly in the manifest, for example debugging options, and in the future it would even be possible to store the debugger map directly in the .s2gm file (Cell currently writes it to a separate file, sourcemap.json, by analogy with MSVC's .pdb files).

Just fixed the bug this morning where minisphere can't load images with the wrong file extension.  The latest Allegro release (5.1.12) includes a fix for this, but building it in Windows is a pain (its CMake script can never find all the dependencies, making it work is an exercise in frustration) so I added a workaround myself.  I'm determined to get KR running out of the box, hehe.

I may have mentioned this above but const works now, thanks to a quick hack by the author to add it as an alias for var.

The only thing I really have left to do is give the code another quick lookover to make sure there are no inconsistencies with the new behavior and perhaps strengthen the sandbox somewhat (it currently allows relative paths to go out of the game directory when it probably shouldn't).