Skip to main content

News

Topic: TurboSphere (Read 190655 times) previous topic - next topic

0 Members and 4 Guests are viewing this topic.
Re: TurboSphere
Reply #600
Out of order rendering can happen, but it's quite rare in practice. You can only have every third frame be out of order with three queues (and only two with five). It requires the engine thread be running notably faster than the rendering thread, and then suddenly slow down to less than half the speed.

In the worst case scenario with three queues, you would get two frames in a row and then one back. But the chances of that happening more than once in row are very low, since the engine thread would need to be slowing down and speeding up at a highly specific rate relative to the rendering queue.

Far more common is the engine thread running at more than twice the render thread's speed and consistently overwriting multiple frames before they are drawn.

Re: TurboSphere
Reply #601
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 Plan

I 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.
  • Last Edit: December 22, 2015, 05:37:40 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #602
Honestly the only reason minisphere ended up as a Sphere 1.x replacement is because it acted as a guide for me, something to work towards, which I later built on.  Originally, I wanted to make a whole new API which was more idiomatic for modern JS--but incompatible with Sphere 1.x--but realized early on that had I done so, it would have been a disaster; my aversion to planning ahead would have turned it into an unfocused, inconsistent mess.  Writing to the 1.x API first let me build something which had long been proven to work, and work well, then once that was finished I was able to build on it with Sphere 2.0 stuff.

UltraSphere sounds like it could be awesome.  The focus on ArrayBuffers worries me though; I've always said Sphere's main strength was that, despite its use of a full programming language and the engine's overall hands-off nature (as you say, the JS controls everything, including the event loop), it is deceptively approachable; this was further proven to me further the other day by my cousin, who has very little programming background, got interested in learning JS thanks to minisphere.  UltraSphere's planned more-low-level approach using buffers and such would lose that accessibility, I think.  This is a big reason I consider the Sphere 1.x API (however it's implemented) to be instrumental in any Sphere engine regardless of its aging facade: It offers something for new users to latch onto while still being reasonably powerful, and once they become proficient they can transition over to the more advanced stuff like Galileo, Audialis, etc. which require more discipline to use properly.

All that said, I wish you luck with UltraSphere and hope it turns into something great.  Honestly though?  I think the biggest thing that killed TurboSphere as a project wasn't anything technical, but more the lack of focus.  Somewhere along the lines I feel like the project lost its focus and didn't really know what it wanted to be.  Which, keep in mind, could kill UltraSphere as well, due to the second-system effect.  Something to keep in mind.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #603
Regarding RMN: I checked it out real quick, but I'm not sure how to go about getting minisphere on there.  And they already have a section for Sphere; would minisphere fall under that category instead of being considered a separate engine?  I guess I would have to sign up for their forums and make some posts about it.

I've already done some advertisement of minisphere on the Allegro forums, but it seems Allegro is largely in the same boat as us, with a dwindling userbase (still much healthier than us though... :() and the library itself considered something of a relic, even in spite of Allegro 5 being a complete rewrite and modernization of the API.  So I don't think it gained me much.  RMN would be a better bet, and might even do something to get Allegro back in the spotlight as well.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: TurboSphere
Reply #604
On RMN, there are a number of RPG Maker clone engines that are listed as games (even though they are not games theselves). You could do that, although that never really struck me as a great solution.

Alternatively, you could add Spectactles and ask Kentona to add minisphere so that you can list Spectacle's engine properly. He generally wants there to be at least one game for an engine before he puts it on the list, and you could use it as a showcase for minisphere, as well.

But also, I think that waiting around and suggesting minisphere when people as "what's the best engine for xyz?" questions could be a good idea. There are a lot of people just starting out on RMN, and even if their games don't really go anywhere most of the time (don't we all have large libraries of games we only barely start to make? :P ) it would give minisphere some listed games on RMN, improving its presence.

Those were pretty much my plans with TurboSphere once I started a good looking game using it, but I always held back because once TurboSphere was actually useful since it wasn't for Windows anymore.
  • Last Edit: December 24, 2015, 01:18:08 pm by Flying Jester

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: TurboSphere
Reply #605
Ideally I'd like to see existing complete Sphere games like Beaker's, Radnen's, sdhawk's, Tengu's, etc stuff and certain tech demos like kamatsu's destructive terrain demo confirmed working on minisphere, and minisphere updated if there's missing or lacking functionality, so that we have a decent amount of results we can point to when demonstrating Sphere's capabilities.

This was kind of the point of the sphere-games repo and my stickied call for devs to provide demos and games, where there would be free complete games distributed with the engine/editor that people could just "pick up and play"  and/or learn from; I dropped the ball on finishing Flappy Sphere even though I had at least 80% of the thing done, though, and I apologize for that.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #606

Ideally I'd like to see existing complete Sphere games like Beaker's, Radnen's, sdhawk's, Tengu's, etc stuff and certain tech demos like kamatsu's destructive terrain demo confirmed working on minisphere, and minisphere updated if there's missing or lacking functionality, so that we have a decent amount of results we can point to when demonstrating Sphere's capabilities.


After Christmas I'll look through the download repo again and test more stuff there.  A big hurdle for a lot of Sphere games has been minisphere's lack of mp3 support, and converting them all to Vorbis (and performing the requisite find-and-replace in the game scripts) is tedious, particularly with large games like Aquatis.  I want to remedy that, but since Allegro is unlikely to ever support it natively I'll have to do it myself using Audialis internally.  Anyone know of a liberally-licensed (zlib/MIT/BSD/etc) mp3 decoder library?
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: TurboSphere
Reply #607
All the MP3 decoders or frameworks that handle MP3 that I know of are GPL.

Maybe hook into Windows Media Foundation on Windows and GStreamer elsewhere?

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #608

All the MP3 decoders or frameworks that handle MP3 that I know of are GPL.


Indeed, some quick Googling corroborates this.  That explains why Allegro doesn't support it, actually: it's zlib licensed and including a GPL decoder would make it impossible to keep such a liberal license.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: TurboSphere
Reply #609
It's also why libsndfile doesn't support MP3. TurboSphere only supported it way back in the day when I was using BASS, before I wised up.

  • FBnil
  • [*][*]
Re: TurboSphere
Reply #610
Note that you now have to compete with http://div-arena.co.uk/ and https://love2d.org/
they support many platforms to reach a high amount of users.

Also about the deep-programming thing: Someone will write a library eventually that just plays a sound, when I want it, without me having to worry about the buffering. But it is nice to know that you can, say, delay and dim the left channel to have a sound swooshing from the right...

BTW, have you seen this? The commodore 64 impossible mission in a browser: http://impossible-mission.krissz.hu/

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: TurboSphere
Reply #611

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'm a bit late, but I'd like to respond to this too.

As a pure user of Sphere (and only occasionally so), what I looked for in TurboSphere was a stable new version of Sphere. So I agree the compatibility let me down, but more importantly, it always kept crashing in different ways until I basically grew tired of it myself. And then I grew out of Sphere for a while again. This is a rather harsh truth, I suppose. Maybe it's a lot more stable now than it's used to be, but at this point it's a little too late. (Note that I definitely think your efforts with TS were very helpful and I was definitely enthusiastic about it early on until it kinda changed into something I was no longer familiar with, though!)

Now there's minisphere, and it became surprisingly stable, compact and elegant surprisingly quickly, and I don't even feel like anyone should be trying to create yet another version of Sphere. No offense to your plans at all, of course - I just personally feel this way. To me, the "solution" of modernizing the Sphere engine itself has more or less arrived, and at this point it might be better to focus development on that instead (as well as advertising it to the world).

UltraSphere still really sounds cool, but to me at least it feels like it might do better as a whole new engine that happens to borrow concepts from good ol' Sphere. :)

Re: TurboSphere
Reply #612
I totally agree. I didn't really support Windows at all, and almost all the crashes were because I simply didn't test my Windows builds.

And a big part of the issues with TurboSphere were because I was torn between making a new Sphere and making something altogether new.

I chose the name UltraSphere to relate it to TurboSphere, but in reality it shares the new Turbo aspects much, much more than the Sphere aspects.

Maybe I should rethink the name. Plus, it would be nice to keep the "Turbo" prefix :)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: TurboSphere
Reply #613
Maybe just call it the Turbo engine?  The vast majority of commercial engines seem to go for one-word names (Source, Rage, Build), so it would fit right in.  The name doesn't seem to be taken either, surprisingly. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: TurboSphere
Reply #614
I agree; I rather like the name "Turbo". :)