I don't know, at this point I feel like that would just be needlessly extending the vanilla engine's life for no real gain.  If I were to add the missing primitives the engine would be 100% backward compatible as-is (save some audio formats), no need to make a build with removed functionality.  We WANT to get new users to use the new stuff, and having separate stable and unstable/experimental versions might scare them off of doing so.  In fact the additional bells and whistles are the biggest reason I recommend minisphere over vanilla--a build limited to just the 1.x APIs would Have no real advantage over the original engine, IMO.  Duktape is faster, yes, but not enough to make-or-break.

It's tempting to want to wait until Sphere 2.0 has stabilized to commit to anything, but part of the reason I took the initiative with minisphere in the first place was because that process was going nowhere--note the sorry state Pegasus ended up in.

For all intents and purposes, the primary advantage a vanilla API minisphere would have over classic Sphere is the existence of reliable modern dependencies and cross-platform consistencies across modern systems. minisphere comes with Duktape bundled and only requires the easy-to-package Allegro, and is guaranteed to work on all three common modern systems (and probably will work on Windows < 7, OS X < 10.9, various older Linuxes, maybe the BSDs); Classic requires a slew of first-party dependencies that may or may not bundle/compile/package/etc cleanly and easily on modern systems (I'm sure y'all remember the PITA modernizing audiere was), and is only guaranteed to work on older Windows (I don't remember if 1.5 worked easily on >=Vista or not), OS X < 10.7 with the separate dependencies bundle, and maybe some Linuxes.

But yes, I understand the desire to "get new users to use the new stuff;" remember I was a web developer trying to convince clients to modernize sites to support Firefox & Chrome back when IE6 was still a thing

I think our best bet is to embrace the extension system I already have implemented and, instead of standardizing "Sphere 2.0" wholesale, we work on standardizing the individual components.  So you would have a standard for Audialis, one for Galileo, etc., each with a unique extension string exposed through GetExtensions() and they would all be Sphere 2.0 components.  This is how the Ecmascript specs are built, and the process seems to work very well.

Ecmascript, CSS3, and HTML5 use this modular draft system, and I agree with its methodology. The doc for GetExtensions says the strings returned are mostly self-explanatory, but honestly I feel the new ones (basically any string that's not "sphere-legacy-api") need some sort of explanation, and I'd probably like to see some sectioned, e.g. sphere-audialis sectioned into sphere-audialis, sphere-audialis-wav, sphere-audialis-mp3, sphere-audialis-midi, sphere-audialis-ogg, ..., as R/W capabilities warrant. I assume the preferred way to check for certain functionality is (GetExtensions().indexOf(theCapability)!==-1)  ?

The doc for GetVersion says minisphere 1.4 and needs the version number updated, FYI.

Does it?  ill have to fix it.  I make a point to update the GetVersionString() return value every major release, but may have missed an annotation elsewhere.  The actual function should return the correct API version (2.0) in any case.

indexOf is the best way to check for extensions, yes.

But anyway, I don't think actively stripping out functionality helps anyone when the engine is already compatible with vanilla.  Vanilla compatibility is neatly encapsulated by the sphere-legacy-api extension, if you need to code against the new stuff you check for the appropriate extension and either degrade gracefully or fail outright.  That's why the system exists.

Speaking of which, I don't know that it's a good idea to overly compartmentalize the extension system as you're suggesting.  Extensions are shorthand for a set of APIs, supported formats don't really need dedicated extensions as more formats might be supported via plugins or whatnot, a la TurboSphere--and depending on the backend used, may even change between platforms...

As for documentation, again, each extension string represents an API.  So to find out what each represents if it's unclear, you have to read the API reference.   Both Galileo and Audialis are covered via short descriptions and function documentation.  Even SphereFS is explained in that document.

Overall I just think that releasing a stripped-down engine is akin to saying "here's a modernized IE6, we know you're not ready for all the new technologies yet but at least it's new, right?"  Maybe that's just me though.

But anyway, I don't think actively stripping out functionality helps anyone when the engine is already compatible with vanilla.  Vanilla compatibility is neatly encapsulated by the sphere-legacy-api extension, if you need to code against the new stuff you check for the appropriate extension and either degrade gracefully or fail outright.  That's why the system exists.

[ ... ]

Overall I just think that releasing a stripped-down engine is akin to saying "here's a modernized IE6, we know you're not ready for all the new technologies yet but at least it's new, right?"  Maybe that's just me though.

I understand your approach better now. I was of an old mindset of "test if GetVersion() > X for Y functionality" to do stuff and forgot for a while that a modular extensions system like yours and testing for extension existence is indeed almost always the better option; it's the core tenet of Modernizr, among other libraries, and Crockford preaches about the methodology so hard in JS: The Good Parts that I really should have known better.

...crap. That it took me this long to put 2 & 2 together about this means the depression I seem to have is getting worse; the fact that I'm apparently losing focus and acuity in THIS aspect of my life is a pretty bad sign for me.

Yeah, that's pretty much it.  Technically GetVersion() never has to return anything > 2.0 now since 2.0 implies the existence of GetExtensions()--and if THAT exists, you should be using that to test for feature support beyond the vanilla subset.

So I'm working on a modification to Duktape that will allow minisphere to break into the debugger if an error is thrown.  Attached is a screenshot of the dialog which would be displayed by Sphere Studio if this is successfully implemented:

I think I want to make a command line debugger for minisphere.  Being able to do it in Sphere Studio is great (I always prefer an IDE for debugging), but this would allow debugging on any platform minisphere runs on, not just windows.  Especially if I coded it in C.

How do I send text to the console?

Code: (javascript) [Select]

Print("A pig ate everything at 8:12");

While debugging, this will also send it to the Sphere Studio console.

1.7.5 is now available for download with the previously mentioned debugger enhancement allowing the debugger to pause execution when an error is thrown.  Very useful!

minisphere 1.7.6 is up.  The redist engine now has JS debugging disabled as having it enabled hurt performance even when not actively debugging.  Debugging now requires minisphere Console to be used.

Sphere Studio has also been updated with the latest bug fixes and features, notably the new entity view implemented in the map editor by Radnen.

Okay, 1.7.7 is up, fixing misbehavior when infinite recursion is encountered--"double error" for a normal run, or an outright crash with the debugger attached.  Now it properly throws a RangeError in this case, which will be caught by the debugger.

I decided for minisphere 2.0, I'm going to deprecate ByteArray.  It will still be retained in the API for backwards compatibility, but all the new APIs (such as the new Sockets API) are being updated to use ArrayBuffers and TypedArrays instead.

I'm also going to try my hand at writing a new map engine in JavaScript.  Despite my misgivings in the past, I think this will ultimately be a good thing to have, if only because you'll be able to step into map engine code while debugging.  As with ByteArrays above, the classic map engine will be retained with its API fully intact.

Good news: minisphere 2.0 will support const.  Well, in the same capacity as Sphere 1.5 does anyway (i.e. it's a synonym for var).  This improves legacy compatibility even further.

Let me just say for the record here that SCons is a hellish nightmare to work with.  Things that should be simple like pulling in sources from minisphere to use in Cell cause no end of grief under SCons because it doesn't make a clear distinction between source and object files and treats one as a stand-in for the other.  That is, if you use the same source file in two programs, it compiles it once and tries to link the same object file into both programs.  And then if you try to use different compiler options between the two, SCons throws up its hands and gives up ("Two environments with different options for same target").

It doesn't help either that the SCons documentation is absolutely atrocious.  It took me forever just to find (on an obscure Stack Overflow question) that the solution was not to pass the .c file to Program() directly, but use the Object() method like so:

Code: (python) [Select]

cell_sources = [
	Object("duktape", "../msphere/duktape.c"),
	Object("vector", "../msphere/vector.c"),
	"engine.c",
	"main.c"  # <-- what this really means, to SCons, is "the object file created from main.c"
]

Ugh.

edit: GAAAAAAAAAAAAAAAHHHHHHHHHHHH *DBZ powerup* *goes Super Saiyan*

Code: [Select]

$ scons cell
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: obj/cell
scons: *** [obj/cell/engine.o] Implicit dependency `obj/cell/duktape.h' not found, needed by target `obj/cell/engine.o'.
scons: building terminated because of errors.

That didn't work either.  At all.  Seriously, whoever wrote this piece of software should be drug out into the street and shot.

edit 2: So it started building properly again for no apparent reason.  Well, I'm not going to complain, but it doesn't do much for my faith in this build system.  I wonder if CMake is any better.  In any case, SCons provides a good baseline of what not to do in Cell.

Chad Austin is in the credits for SCons. That's how I originally found it.

The docs are bad, mostly because SCons wiki was destroyed by spambots a few years ago. I usually use the archive.org'ed version of it, since it was never properly rebuilt.

SCons doesn't make any distinctions about what anything is. Everything has a way of being created, and may be needed for something else. If you only care about compiling that C file, then you pass in that C file. Since you care about more than that (compiler options), what you care about is the resulting object files. This is how any dependency driven build system works.

An alternative (I suspect the intended way) is to use static libraries, since using the static library builder lets you do what you want--different options on the same source to create different object files. In general, static libraries stand in for individual object files in SCons when you don't want to build something in just one step.

When you hit implicit dependency issues, try nuking the .sconsign and scons DB files.