Skip to main content ↑ ↓
Topic: Future of Sphere: Sphere v2 and the Web (Read 74621 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Future of Sphere: Sphere v2 and the Web

I recently opened this GitHub issue for implementing browser-like behavior in the main engine so that we could experimment with writing Web-friendly Sphere games:
https://github.com/fatcerberus/minisphere/issues/78

The fact is, most of what's needed already exists.  The Dispatch API, to be introduced with minisphere 4.3, is an important piece of the puzzle as it brings the ability to set update and render hooks that work engine-wide rather than just in the map engine.  However because there is it yet an engine-provided frame loop, games still need to be written in the classic way:
Code: (javascript) [Select]

while (system.run()) {
    screen.flip();
}


Which works well for a PC game but would never fly on the Web unless you want your game to get killed by the browser in short order for "running too long".

In fact anything that blocks is right out, for exactly the same reason.  APIs like system.sleep() need to be disabled, but more importantly, we need some sort of nonblocking I/O.  It's proven that Sphere formats can be used on the Web, but Sphere's file API (including v2) blocks.  That will need to change.

Anything else I'm missing?

Re: Future of Sphere: Sphere v2 and the Web

Reply #1 –
With the API as it is right now, I'm not exactly sure where changes would need to be made and how, but I gotta say that the idea of Sphere makes me the most excited personally as that's kinda where I've wanted to move things myself. It's more popular on the web too now. :)

Oh, I just thought of something. I tend to rely on functions like Screen.setFrameRate() myself a lot. What would be the most elegant solution to handle that?

Also, I imagine that for stuff like the map engine, the exact time between one render and the previous render needs to be kept, and according to that calculate the right amount of updates that should have happened in-between the two. That would make it pretty resistant against missing updates, although maybe sound would have to be handled completely separately from that. I dunno. I'm just basically thinking out loud but I don't know the best solution here.

Re: Future of Sphere: Sphere v2 and the Web

Reply #2 –
Web browsers have window.requestAnimationFrame() for regulation of framerate but those can be skipped and I believe it's also tied to your monitor refresh rate.    So that's only useful for rendering, whereas Sphere uses your framerate to regulate updates as well (which is very convenient).  Not sure how that could work in a browser, but I imagine it's possible.  Perhaps something using setInterval() could work.

An asynchronous File API would probably work best if it's based on promises, which are standard in JavaScript since ES6.  They will also be available in minisphere starting with version 4.3 using a polyfill (Duktape doesn't support them natively).

Re: Future of Sphere: Sphere v2 and the Web

Reply #3 –
Here's a basic proof of concept:
https://github.com/fatcerberus/oozaru

It doesn't do much, just writes the engine version and sets up a do-nothing update and render handler using the Dispatch API.  Except for the document.write(), all the code in main.js would work identically in minisphere 4.3 with the addition of the standard game loop:

Code: (javascript) [Select]
while (system.run()) {
    screen.flip();
}
 

Re: Future of Sphere: Sphere v2 and the Web

Reply #5 –
@DaVince: minisphere 4.3.1 will add an engine-provided frame loop that starts after the main script finishes, mimicking a browser, and runs only as long as there are jobs in the Dispatch queue.  Because of that escape clause it'll be fully compatible with Sphere 1.x games.  Since v1 code can't create jobs, that extra loop never starts.

Adding this little thing means that any code written for Oozaru will work identically in minisphere, making it a proper subset.  That's important for eventual convergence.