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.
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.
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.
Print("A pig ate everything at 8:12");
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"]
$ scons cellscons: Reading SConscript files ...scons: done reading SConscript files.scons: Building targets ...scons: building associated VariantDir targets: obj/cellscons: *** [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.