New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Browser Mode" with central game loop #78

Closed
fatcerberus opened this Issue Nov 2, 2016 · 5 comments

Comments

Projects
None yet
1 participant
@fatcerberus
Owner

fatcerberus commented Nov 2, 2016

Implementing this feature would be another step towards making Sphere more web-friendly. In "browser mode" (final name TBD) Sphere wouldn't exit when the main script finished, but instead would enter its own flipscreen loop, like MapEngine() does in Sphere v1. This would in turn allow experimenting with games written around such a design, which mimics how a browser works, to see if "Web-Sphere" is feasible.

Checklist:

  • Implement the central frame loop (spins up after main script completes).
  • Figure out a good exit condition for the main loop.
  • Figure out what API changes are needed: Tracked by fatcerberus/oozaru#1

@fatcerberus fatcerberus added the feature label Nov 2, 2016

@fatcerberus fatcerberus added this to the v5.0.0 milestone Nov 2, 2016

@fatcerberus

This comment has been minimized.

Show comment
Hide comment
@fatcerberus

fatcerberus Nov 5, 2016

Owner

The main challenge here is figuring out the exit condition. It's not enough to say "Okay, job queue is empty, time to quit" because there might be tasks running without any actual outstanding jobs (yet). Naturally this only matters for a native engine - a browser-based engine needs no exit condition because the exit condition is always "whenever the user closes to tab".

Owner

fatcerberus commented Nov 5, 2016

The main challenge here is figuring out the exit condition. It's not enough to say "Okay, job queue is empty, time to quit" because there might be tasks running without any actual outstanding jobs (yet). Naturally this only matters for a native engine - a browser-based engine needs no exit condition because the exit condition is always "whenever the user closes to tab".

@fatcerberus

This comment has been minimized.

Show comment
Hide comment
@fatcerberus

fatcerberus Nov 5, 2016

Owner

I did some research on this, and Node.js apparently counts event listeners to determine when to quit, not dispatches. Sphere has no proper eventing system--at least not yet--so a different approach is needed here.

Owner

fatcerberus commented Nov 5, 2016

I did some research on this, and Node.js apparently counts event listeners to determine when to quit, not dispatches. Sphere has no proper eventing system--at least not yet--so a different approach is needed here.

@fatcerberus fatcerberus added the Core API label Nov 7, 2016

@fatcerberus

This comment has been minimized.

Show comment
Hide comment
@fatcerberus

fatcerberus Nov 7, 2016

Owner

The lion's share of the Sphere v2 API is already pretty Web-friendly. Unlike Sphere v1, blocking calls are far and few between, mostly limited to specialized stuff like system.sleep() that can be removed entirely because they don't make sense at all in a browser environment.

The File System API will need some thought. Like Sphere 1.x, file I/O in Sphere v2 is blocking. Read and write calls don't return until they are finished, which will never fly on the Web. If you tried to pull that, your game would be killed by the browser in short order.

So, long story short, some kind of nonblocking API is needed. It's probably best to base it on Promises, but beyond that it's an open question what it will look like. In any case, the blocking APIs should be disabled for Web games.

Owner

fatcerberus commented Nov 7, 2016

The lion's share of the Sphere v2 API is already pretty Web-friendly. Unlike Sphere v1, blocking calls are far and few between, mostly limited to specialized stuff like system.sleep() that can be removed entirely because they don't make sense at all in a browser environment.

The File System API will need some thought. Like Sphere 1.x, file I/O in Sphere v2 is blocking. Read and write calls don't return until they are finished, which will never fly on the Web. If you tried to pull that, your game would be killed by the browser in short order.

So, long story short, some kind of nonblocking API is needed. It's probably best to base it on Promises, but beyond that it's an open question what it will look like. In any case, the blocking APIs should be disabled for Web games.

@fatcerberus

This comment has been minimized.

Show comment
Hide comment
@fatcerberus

fatcerberus Nov 8, 2016

Owner

minisphere 4.3.1, released today, adds the central event loop. It starts after the main script finishes executing and goes until there are no pending jobs left in the queue (note: recurring jobs are always considered pending until cancelled). Because of the escape clause it's not an issue for backwards compatibility: Sphere 1.x doesn't have the Dispatch API, and the event loop will simply never start if there are no jobs.

Owner

fatcerberus commented Nov 8, 2016

minisphere 4.3.1, released today, adds the central event loop. It starts after the main script finishes executing and goes until there are no pending jobs left in the queue (note: recurring jobs are always considered pending until cancelled). Because of the escape clause it's not an issue for backwards compatibility: Sphere 1.x doesn't have the Dispatch API, and the event loop will simply never start if there are no jobs.

@fatcerberus

This comment has been minimized.

Show comment
Hide comment
@fatcerberus

fatcerberus Nov 8, 2016

Owner

With the release of v4.3.1, minisphere's debt to Web compatibility is satisfied (for now). Watch the Oozaru repository for further developments in this department: https://github.com/fatcerberus/oozaru

Owner

fatcerberus commented Nov 8, 2016

With the release of v4.3.1, minisphere's debt to Web compatibility is satisfied (for now). Watch the Oozaru repository for further developments in this department: https://github.com/fatcerberus/oozaru

@fatcerberus fatcerberus closed this Nov 8, 2016

@fatcerberus fatcerberus modified the milestones: v4.3.1, v5.0.0 Nov 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment