I can also now properly add an ArrayBufferToSurface function. This was quite literally not possible with V8.
I don't get it, is it because this is an ECMA6 Array Buffer going to a Sphere Surface, and on the C++ side you didn't have access to the array buffer or it's contents?
It's because ArrayBuffers are single-use in V8.
In V8, once you get the address of underlying memory of an ArrayBuffer, that ArrayBuffer can not be GC'ed anymore. Even worse is that until recently you could only get the underlying address once. You've either got to leak it and let script keep using it, or free it with no way to tell script that it's not usable anymore! Both totally unacceptable--either I've got a memory leak, or I can cause a segfault from script? How is this a useful API?
With SM, I can just get the ArrayBuffer's underlying memory buffer address without making un-GC'able. I don't see why this isn't the case for V8. It works fine in SM, and I've even hacked the same functionality into V8 a couple times. It works fine, it's how the API should work, but the V8 authors have some deep-seated fear of this.
This way it is simple to read a portion of a file representing a bitmap (like in a Sphere tileset, spriteset, or font), and totally from script, pass the resulting ArrayBuffer directly to an image. Fairly close to the efficiency of native, but still leaving it possible to modify the bitmap from script.
You can still get the contents, but since you can't just do a memcpy/std::copy from the native side, you have to actually iterate the ArrayBuffer using a JS array or a TypedArray, even in native. I tried to do that, since it's the 'correct' way with V8, but it is just horrifically slow. It's not an option for anything but a trivial example. That's why I am so disappointed with V8 ArrayBuffers, a lot of the advantages that having native memory available to script could have are made impossible by how V8 handles them. So it's technically possible, but it would actually be an ArrayToSurface function, applying the ArrayBuffer to a normal JS Array or iterating a TypedArray like a normal JS Array. This is unacceptably slow and complex. A map with 32 tiles, each 16x16, and a 4-layer playing field of 64x64 tiles, takes about 2 seconds to read this way on my Mac Book, it should be much, much less!
If that's the case then SM is definitely a huge win since I'm pretty sure you're intending to use ArrayBuffers quite thoroughly throughout, like for vertex maps and such.
ArrayBuffers are key to how I want to do I/O with TurboSphere, almost exactly how Sphere uses ByteArrays. It also allows for a lot of shortcuts when reading files (like above, read a bitmap from a file in one operation, turn it into a Surface with one operation, with only a single ArrayBuffer being passed around). So they aren't really much different from how ByteArrays are in Sphere 1.5, but they are obviously native to JS, and I intend to do much more I/O in script.