Skip to main content
↑
↓
Spherical forums
Community for the
Sphere game engine
New?
Contact Us
to register an account!
1 Hour
1 Day
1 Week
1 Month
Forever
Community
Help
Search
Recent Posts
Log in
Contact Us
News
Spherical
Facebook
-
Twitter
-
Discord chat
New?
Contact us
to register an account!
Sphere Development
Sphere General
Future of Sphere: Sphere v2 and the Web
1
Print
Topic: Future of Sphere: Sphere v2 and the Web
(Read 4770 times)
previous topic
-
next topic
0 Members and 2 Guests are viewing this topic.
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Future of Sphere: Sphere v2 and the Web
November 07, 2016, 09:59:16 am
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?
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
DaVince
Legendary Poster
Posts: 1,001
Logged
Administrator
Used Sphere for, like, half my life
Re: Future of Sphere: Sphere v2 and the Web
Reply #1
–
November 07, 2016, 10:36:57 am
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.
Spherical Downloads Repo
||
My (really old) Sphere stuff
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Re: Future of Sphere: Sphere v2 and the Web
Reply #2
–
November 07, 2016, 10:51:38 am
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).
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Re: Future of Sphere: Sphere v2 and the Web
Reply #3
–
November 07, 2016, 03:01:04 pm
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();
}
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
DaVince
Legendary Poster
Posts: 1,001
Logged
Administrator
Used Sphere for, like, half my life
Re: Future of Sphere: Sphere v2 and the Web
Reply #4
–
November 07, 2016, 03:33:17 pm
Oh, I see. This works very well for the rendering indeed.
Spherical Downloads Repo
||
My (really old) Sphere stuff
Fat Cerberus
Big Chungus
Posts: 2,774
*MUNCH*
Logged
Global Moderator
Sphere Developer
Re: Future of Sphere: Sphere v2 and the Web
Reply #5
–
November 08, 2016, 03:59:31 am
@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.
neoSphere 5.9.2
-
neoSphere
engine -
Cell
compiler -
SSj
debugger
forum thread
|
on GitHub
1
Print
Sphere Development
Sphere General
Future of Sphere: Sphere v2 and the Web