Re: TurboSphere
Reply #372 –
The new version is still coming along. I'm putting the new graphics core into a new graphics plugin, using the new plugin tools. Everything new and shiny!
The new graphics plugin will actually be callable from other plugins a lot like the Sphere video drivers are in Sphere. I needed to see that in action, writing FJ-GL, to see the advantages that a more detached API could provide. The API will be closer to the metal than Sphere's (the plugins still must agree on OpenGL), but it will be more useful than what I had before.
I've added the ability to dynamically switch between multi-threaded and single-threaded surface rendering. It doesn't really have a good use, but I'm working on adding more threading, and it will be important in other places and other threads to be able to do that. While I'm at it, I've been moving the surface renderer over from my own homemade concurrent queue (which uses a mutices) to use the Intel Thread Building Blocks or the Microsoft Concurrency Library (both options available at compile time), which are atomic spin-lock based (faster, easy to remove busy-waits). Obviously TBB is necessary on Linux, and MSCL is included with MSVC so that's easier on Windows. They are, in the case of concurrent container classes, API compatible.
I've also worked out a file type for scripts that contain embedded V8 compiler data. It's basically IFF-style, lacking a resource map, with specific magic numbers for script text and V8 data. It also hijacks a reserved field to store V8 version data (this is important!). It's extremely simple to read this kind of file, check if there is V8 data in it, and if not generate and append V8 compiler data to it. This speeds up subsequent compilation of large and complex scripts (this is a part of how V8's snapshot works). I'm using this for the new graphics plugin, which defines a couple functions in embedded scripts.
On a different note:
For laughs, I tried to compile TurboSphere for Raspbian on the Raspberry Pi. It looks like all it needs is more OpenGL ES support. SDL2 has code just for the RPi, Bass has an ARM-Linux version that works on Raspbian, and V8 has ARM and Linux as primary targets. TS already has some OpenGL ES support, added during my cursory looks at Android. I've been adding space for it now as I work on the new graphics plugin.