I've been thinking of why TurboSphere didn't really live up to what I wanted it to be, and how I would redo it. I think there are the main failings of TurboSphere:
- Murky Concepts of Compatibility
- No Real Releases
- No Discoverability
I think that because of these three issues, TurboSphere sort of failed, despite having a basically complete API and good stability. But there were some good points. I think a few really key features to TurboSphere are:
- Low Level Plugin System
- Extensive Use of Engine JavaScript
- Powerful Graphics Stack
I still like the concept behind Sphere and TurboSphere (and minisphere and all the other engines). But I have a new plan for what a modern Sphere-related engine will look like.
The New PlanI want to fix the main failings of TurboSphere, while still retaining the good points. The new effort is called
UltraSphere. UltraSphere still uses JS with SpiderMonkey, and is mostly a rewrite of the native components, but will use the same Turbo Runtime as TurboSphere did. It also features a similar plugin system, although it is slightly more object-oriented--slightly. Mostly a plugin's interface matches the lifetime of a context now, which is a big improvement. But the engine is still rich in script and sparse in native. I think that I was really on to something with pulling absolutely as much out of native as possible, and I want to continue this.
However, maintaining acceptable performance (particularly in regards to memory usage), while using JS as much as possible and
also maintaining real compatibility with Sphere 1.5/1.6 is just not feasible. I tried, and I can tell you it's not a good idea. So, I have decided that UltraSphere will
not be directly compatible with Sphere 1.5 or TurboSphere. This will be particularly notable with regards to loading images/surfaces, loading audio files, drawing primitives and images, and input handling. Everything that the Turbo Runtime already supports (Map Engine, Fonts, WindowStyles) will remain compatible as much as it already is. I actually plan on extending some Sphere 1.5 compatibility with regards to drawing.
With regards to releases, it was never really a goal of TurboSphere to work on Windows. It would have been nice, but this wasn't where I put my effort. This is not really a good idea if I want anyone except myself to actually use it. I intend on really making UltraSphere work on Windows, and I will make actual releases (like I used to with TurboSphere, long, long ago). This is important for two main reasons. One is that most people run Windows. But I could make a case for "Best engine for OS X and Solaris!" for TurboSphere. Just as important is that there are no existing editors for anything but Windows, and since I still use the Sphere formats this is a serious issue. I could change formats, but I don't really see the need to do so. I think much more beneficial is to just run on Windows and be able to use Radnen's editor or the 1.5 editor.
Finally, I built TurboSphere with a sort of "If you build it, they will come" philosophy. I suppose I intended to ride on the advertising the original Sphere engine would give me. But it's clear to me now that Sphere has almost no discoverability anymore, either. We do not promote the engine actively, and in places like RMN where the engine is known it's almost solely considered to be a relic of a bygone era, similar to ika or verge. (Hint to LordEnglish: Get minisphere on RMN!
). I need to actually make real demonstrations and not be so reclusive with the engine if I want any kind of actual usage. Riding on the coattails of the original engine buys any new engine very little.
So, on to how UltraSphere is actually like TurboSphere.
One part of TurboSphere that worked really well was Sapphire (the graphics plugin) and the Galileo API. I was able to get extremely good performance with Sapphire, cycling through asynchronous drawing queues combined with the object-oriented Galileo API which mirrored actual GPU resource usage. I plan on basically copying a lot of the renderer code, and Galileo will mostly stay as it is. However! I have, in my travels, discovered efficient means to draw software overlays on top of OpenGL windows on every platform I care about, including Windows. On an unknown platform this could even be implemented using pure OpenGL, although it would be less efficient. So I plan on making a few more changes to the graphics system. I will add a software overlay. It will be an ArrayBuffer of uint32's, an RGBA framebuffer that will be drawn over the current Galileo scene. It will be totally up to script how to utilize this, but it will alleviate a lot of the issues with using Galileo in the same way one would utilize the Sphere 1.5/1.6 drawing API. This will also make for a clean distinction between procedural drawing and the object-oriented Galileo method. Both are useful in certain circumstances, but the characteristics are quite different. It is important that they not be conflated either in the API or implementation.
I additionally don't want to implement "LoadImage" or "LoadSound" or their similar constructors the way I did before. I had long thought that it would be more elegant to implement a "DecodeImage" and "DecodeSound" system, where decoders for formats are exposed, and it's then up to script to upload those images and audio to surfaces and sounds. An Image and Sound object would just have memory buffers holding the raw data. The decode functions would return ArrayBuffers (or possibly act directly on existing ArrayBuffers). It would be pretty simple to implement a LoadImage and LoadSound on top of these functions. But I think it's important that they are seperated at an engine-level.
The most important part of all of this is that I don't want to keep with the Sphere 1.5/1.6 API. We have just a handful of games that utilize it, and it has some limitations I want to go beyond. My new plan of course allows for shims to be written--just being a JS engine makes that
possible. But I will not write them. I know many people here have said it here before, but I agree that to really become a modern 2D engine, we need to look past the 1.5/1.6 API. UltraSphere is certainly less Sphere-like on the surface than even TurboSphere was. But I'm trying to keep the takeaways that I learned from Sphere. I still want to give JavaScript full control of the engine--even the event loop. I still want to provide a good set of graphics and audio features. But the long-fabled Sphere 2.0, this is not.