Skip to main content ↑ ↓
Topic: Is Sphere less of an engine and more of a standard now? (Read 106742 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is Sphere less of an engine and more of a standard now?

I used to dislike the fact that there were multiple forks of the original engine, but now I don't think it's such a bad idea. Originally, there was just one Sphere, the main engine, from its origin to its stagnation at v1.5. Now there's TurboSphere, miniSphere, Sphere 2.0, the beta of Sphere 1.6 (which from what I understand has ceased development?), Sphere SFML, and at one point, JavaSphere and web-sphere.

So it seems now that rather than Sphere being one engine, it has turned into a standard. Like HTML, with multiple browsers and their goal at being compatible via different methods.
What do you guys think?

Re: Is Sphere less of an engine and more of a standard now?

Reply #1 –
Probably not, no.

tl;dr: The answer is to use minisphere, unless you know exactly why you shouldn't use it. All the other implementations either died out or are now not really Sphere compatible. minisphere is probably the only engine anyone who just "wants to use Sphere" should use, or maybe 1.5/1.6 in certain circumstances (since they still work).

Sphere 1.5/1.6 is still preferable for very, very obscure platforms.

TurboSphere is kind of a dead end for Sphere-related games. It implements the entire map engine, but other than that its API is now not very similar to Sphere's, since I let it drift so far with the promise that I'd write a compatibility shim later. "Later" probably means never at this point. This is compounded with there only being a Mac OS X and a Solaris port anymore, so 90% of everyone can't use it, and there is no editor for either of those platforms.

However, given that minisphere implements the Galileo API from TurboSphere, and contains almost all of the 1.5 API, it has most of the benefits of TurboSphere (unless you are doing some really crazy stuff that needs ultra-speed, or you need ArrayBuffers (question mark?)), and is fully compatible with Sphere 1.5.

Using Sphere 1.6 in combination with FJ-GL will give you close to the same performance as minisphere, but there are a few cases it still pulls away, and the difference will probably become greater and greater as Allegro and Duktape keep getting upgraded and SpiderMonkey 1.7 remains the same.

I'm not sure where Sphere-sfml ended up, but I believe it's at "mostly works with the 1.6 API". However, its JS engine is Windows only, and probably will stay that way for a long time. I wouldn't hold my breath.

Sphere 2.0 ended up the same as TurboSphere in a lot of ways, and I totally see how and why Kyuu took it the direction he did now. It's no longer compatible with Sphere (even less than TurboSphere, where you can still kind of fake it since it still uses JS).

This is, as far as I am concerned, the endgame of Sphere 1.6 and the original engine. No one is really interested in upgrading its JS engine, and my experience with FJ-GL proved to me that the actual engine design has reached its limits for performance. Additionally, the engine is fairly complex, and no one is really left who understands it enough and/or cares enough to try to actually modernize it. I tried once, but I believe it's not worth the time. It would be easier and better to just start from scratch, or use an existing engine (minisphere or TurboSphere) as the basis for any improvements.

Re: Is Sphere less of an engine and more of a standard now?

Reply #2 –
Quote from: Flying Jester – on

However, given that minisphere implements the Galileo API from TurboSphere, and contains almost all of the 1.5 API, it has most of the benefits of TurboSphere (unless you are doing some really crazy stuff that needs ultra-speed, or you need ArrayBuffers (question mark?)), and is fully compatible with Sphere 1.5.


Duktape added ArrayBuffer support the last release.  minisphere has supported them since at least 2.0, and possibly earlier.

Re: Is Sphere less of an engine and more of a standard now?

Reply #3 –
The wall of text that FlyingJester posted about the varying degrees of completeness of independent attempts at modernizing Sphere is essentially the reason that I pretty much unilaterally declared the need for the designation "Sphere-compatible" and almost exclusively define it to mean the API is the same and file format loading produces the same results as vanilla Sphere 1.5/1.6b, irrelevant of what's going on under the hood.

If there are bugs to be fixed like map engine implementation issues or improvements to be made like code optimizations or attempts to use a different I/O library like switching from Audiere and Corona to Allegro they can be made and the given project still retain the "Sphere-compatible" designation. It's when API and/or base functionality deviates a significant amount from existing or proposed API that the "Sphere-compatible" designation cannot be met 100%; implementing a shim either internally or with a script is enough for the API to retain it, though for the engine itself to retain it the ability to load Sphere file formats (including maps) is also necessary.

Proposed API like Galileo and other Sphere 2.0 functionality only retain 1.x compatibility if they implement 1.x API, likely through a shim, and load 1.x file formats. Sphere 2.0 will have some breathing room to expand because it has different goals from 1.x and it's been proven that 1.x compatibility can indeed be achieved and maintained through a shim. Something like web-sphere, on the other hand, has an explicit goal of reimplementing 1.x for the web purely using web-compatible JavaScript (mostly to remove the need to Emscripten an entire JS engine like Spidermonkey to an asm.js compatible script); this is achievable once I get off of my ass and get to work on the most important bit, the map engine.

Re: Is Sphere less of an engine and more of a standard now?

Reply #4 –
A big point I made during minisphere development was to treat the Sphere 1.x API as completely orthogonal to Sphere 2.0 stuff like Audialis, Galileo, etc.  For example, when I was hammering out how SphereFS would work in minisphere 2.0, a few of the decisions I made would have broken compatibility with Sphere 1.x games if I had applied the standard unilaterally.  Nonetheless, the changes were needed.  The solution was to allow the old resource-loading APIs such as LoadImage to use the old semantics, while if you use the 2.0 API, e.g. new Image(), it uses SphereFS semantics (Sphere 1.x not having the constructors helped a ton here).

So, to answer the original question, yes, "Sphere" as such is basically just a designation for a standard for a 2D game engine.  It just so happens that, right now, minisphere is the only engine (besides the original) which meets that standard.  In some ways, it seems I may actually be leading the charge in codifying it. :)

 

Re: Is Sphere less of an engine and more of a standard now?

Reply #6 –
Yes, minisphere is pretty much the standard now.  As for cross-platform, the official releases are for Windows (maintained by myself), but it's been proven to build on Linux and OS X, as well.

Re: Is Sphere less of an engine and more of a standard now?

Reply #8 –
@Eggbert: Just a quick update on this, minisphere now gets .deb and tarball releases starting with the 3.0 betas.  For the tarballs you only need Allegro 5.0 or later and libmng to build (Allegro 5.1 is recommended if you can get it).