Just clarify for me: What is Sapphire exactly?  Is that just the codename for TS, or...?

Sapphire is the graphics plugin. It replaced the old SDL_GL_Threaded plugin last summer (which was a fork of SDL_GL, a fork of SDL_gfx).

It provides the primitives API, Image/Surface loading and API, and screen/window related functions.

The Map Engine for TurboSphere requires only ArrayBuffers, RawFile functions compatible with Sphere 1.5, input functions compatible with Sphere 1.5, and a Sapphire-compatible graphics API. That's why I focused primary on the ScriptFS plugin and Sapphire for the first SM-based plugins. InputSDL will be next!

The API for Sapphire is on the Sphere-Group/Pegasus repo, and is called Galileo. It's still a TurboSphere-named extension, mainly because nothing else supports it (yet?). I also wrote a mostly complete Sphere 1.5-compatible wrapper for it once.

I too would like to implement that API in SSFML.

We can say "Pegasus Ready" Sphere Engine. lol

It works. 100% functional parity with V8 TurboSphere. Except that I messed up the default UV attributes for Vertices, so Shapes with 4 Vertices and no explicit UV coordinates end up upside down.

Just ignore that

Wow, awesome. Looks like the dude is just sunbasking to me.

I fixed the default UV attributes, as well as added the finalizers for Sapphire.

I've put the current list of all functions, objects, and types on the TurboSphere github wiki. With the exception of ShaderProgram objects, it is 100% accurate.

I plan on adding a small tutorial for the new graphics API, as well as a bit of explanation for the plugin tools and plugin API.

I've exposed the old Surface methods for primitives again.

I've also created a page on the TurboSphere github wiki for using the Galileo API. It's not even close to complete, but it's good to at least have something.

Font loading now works, totally in script.



That shot also shows that SetRenderScript works.

I'm curious how well the font system from the Turbo runtime works in minisphere or Sphere 1.5. Without an in-engine way to read directly from a file to a surface or image from script, loading would be a lot slower, but it should be pretty close in speed to a native solution when running.

I'm not sure if Lord English or Radnen are aware of this, but I have been working on some JSON schemes that represent the Sphere filetypes: https://github.com/sphere-group/formats. I use these to make it easier to read files from script. I have no idea if they would be helpful for the other engines, but they are there.

I did see those, yeah.  Wasn't sure how exactly to utilize them, though.  Honestly Sphere's formats are simple enough anyway that it's pretty trivial to write loading logic (in any language) just by reading the format specs.  That's how I did the RFN loading in minisphere, by referring to this:

https://github.com/sphere-group/sphere-doc/blob/master/internal/font.rfn.txt

As I found out though, sometimes the docs are misleading--for example, the font spec above says the pixels in a v2 font are RGBA, when in reality the actual representation is ABGR.

I've been writing them using the internal docs from 1.6 as a reference.

What I do in TurboSphere is parse each component so that a script in the Turbo runtime, format.js can create objects from a RawFile and these schemes.

As an example:

Code: [Select]

Turbo.FontScheme = Turbo.LoadSystemScheme("font.json");

var font_header = Turbo.ReadBinaryObject(stream, Turbo.FontScheme.header);

// Now font_header has all the properties from the font.json's `header' array, loaded from the ByteArray reader `stream'.

if(font_header.signature != Turbo.FontScheme.signature)
    throw "Bad signature. Should be " + Turbo.FontScheme.signature + " instead of " + font_header.signature;

var characters = new Array(font_header.num_characters);
//...

It's mostly just to automate loading from a specific binary layout into a JS object with specified property names. If you aren't loading the files in script, or don't have a good way to load JSON in native, it won't really help much.

Honestly I'm not actually sure how slow Duktape is.  In debug mode it's abysmal, taking in excess of 1-2 seconds just to get through all the RequireScript calls in Specs, but in release mode the delay completely disappears.  I can't fully test until I can get minisphere running the Specs battle engine, then I might consider moving asset loading into script, as in TurboSphere.  For now though, I just want to try to replicate the Sphere 1.5 API natively, look at the results, and then decide where to go from there.

@FJ - is that Turbo.LoadSystemScheme essentially a LoadJSONFile function?

@NEO: Yes, specifically it loads a JSON file from the system/formats folder. I included a polyfill for JSON with the Turbo runtime too, just in case.

Sound now works again!
I've written a new, very simple audio plugin that uses libsndfile and OpenAL. That means no more of the weird licensing issues that seem to be endemic of every single all-in-one solution for sound (except for Audiere--no wonder people still try to use it!). It also is much, MUCH more cross-platform-capable than the old BASS plugin was.

I need to flesh out the rest of the sound system, but having used OpenAL a bit, it's really quite a nice API. A little old-fashioned perhaps, but extremely predictable and simple to use. It also is designed for 3D sound, so it will be relatively simple to add that later. I also need to add audio streaming, we only support fully buffering the files just yet.

WindowStyles fully work as well. Just as with Fonts, though, the old functions from Sphere 1.5 are gone, and now they can only be pre-rendered to surfaces. But they fully load and render.

So, this won't really be of much interest to anyone but me, but TurboSphere fully compiles using Solaris Studio on UltraSparc and Clang's standard library. I get a really nasty segfault on startup, likely because of the incompatibility of Clang's library and Solaris Studio, but a new release of Solaris Studio is supposedly coming out soon that includes a C++11-capable standard library (the compiler is already C++11 capable). In any case, this means I am very close to getting a Solaris 10 UltraSparc version compiled.

Which no one really has any reason to care about but me...I guess once it works it would be proof that TS is big-endian capable and works on generic Unices.

I also have the issue of Mesa3D not initializing correctly on my Solaris machines. But I think that a OpenGL 1.2/OpenGL ES 2 backend for Sapphire would be beneficial, both here and for Android and iOS. Yet another thing to add to the wishlist.

I've added basic networking support using the libfjnet library I wrote for Kashyyyk. Everything but listening is there.

I also fleshed out the Sound api a bit more.

Edit:
ListenOnPort works. So now 100% of the network API works, although using ArrayBuffers rather than ByteArrays. I included a script in the Turbo runtime (system/scripts/turbo) to make ByteArray-compatible objects from ArrayBuffers. But there's really no reason to use ByteArrays in an engine that has ArrayBuffers and TypedArrays.