It's only needed for two fields of a single Sphere filetype, and only for single precision, but I've added the ability to load binary fields of data as floating point numbers of arbitrary precision. To do this, I ported a Node.js module that handles ieee754 numbers.
A fellow on the v8-users group
pointed me to a trick that Chrome uses for CanvasData. So even Google knows their API is almost useless in the real world!
This makes maps load instantly, since I don't need to make two allocations and three copies for every ArrayBuffer I fill in native.
With that, we can efficiently use readers for everything, and take advantage of the different widths of typed arrays for almost all data conversions.
So, from a 'how much works yet' standpoint, still where we were last time. But from both a speed and stability perspective, things are much better.
Another cool thing--V8 supports PowerPC now. This also means it has support for any of its targets in BE mode (theoretically, only tested for PPC I've heard). The IBM team did this, so I assume it mainly supports BE.
The main issue that remains is that TurboSphere uses modern OpenGL. Before Leopard, I am pretty sure that it won't work out of the box. Fortunately, this
is something I have dealt with before. I use Mesa3D on my Windows box to fix the fact that it has Intel graphics, and I believe that the same could be done on older OS X.
So, if one was going to port TurboSphere to PowerPC OS X, here's what you would need to do:
- Get Clang 2.9+ or GCC 4.7+ (which means not using XCode at all)
- Compile V8 for native-endian PowerPC. Good luck.
- Compile Mesa3D for PowerPC OS X. This should be pretty easy.
- Fix any endian issues with Sapphire. This should be almost totally restricted to api.hpp and api.cpp.
I may dig out my old G3 iBook soon just for this.