Author Topic: Sphere v2 API discussion  (Read 2954 times)

Offline DaVince

  • Who's an oracle? Not me!
  • Senior Staff
  • Hero Poster
  • *****
  • Posts: 742
    • View Profile
    • Vincent Beers portfolio
Re: Sphere v2 API discussion
« Reply #45 on: February 10, 2017, 03:38:13 am »
I really like that idea. It opens up interaction with other games, sequels, or even stuff like save file managers.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2117
  • *MUNCH*
    • View Profile
Re: Sphere v2 API discussion
« Reply #46 on: February 13, 2017, 01:34:50 pm »
Also, are these settings writable by the game itself in an intuitive manner?

That's not currently possible.  It wouldn't be too hard to have the engine detect changes to Sphere.Game and write them back to the manifest, but I'm not sure what to do about SPK-packed games in that case.
miniSphere 4.5.8 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline mezzoEmrys

  • Adventurer++
  • Verified
  • Low Poster
  • *
  • Posts: 70
    • View Profile
Re: Sphere v2 API discussion
« Reply #47 on: February 13, 2017, 06:07:29 pm »
It does seem like it would be a desirable thing to have it so that if a user enables fullscreen mode, the game would be able to load up in fullscreen mode again the next time the game starts up, without the user having to turn it on again. Maybe there should be some kind of save file that contains "runtime selected" settings which can overwrite the default on load?

Offline DaVince

  • Who's an oracle? Not me!
  • Senior Staff
  • Hero Poster
  • *****
  • Posts: 742
    • View Profile
    • Vincent Beers portfolio
Re: Sphere v2 API discussion
« Reply #48 on: February 14, 2017, 07:19:29 am »
Good point. Perhaps it could save a copy of the project file in a special folder, with a system in place to ensure same-named projects don't conflict of course.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2117
  • *MUNCH*
    • View Profile
Re: Sphere v2 API discussion
« Reply #49 on: February 15, 2017, 11:59:46 am »
If anyone's curious what proper Sphere v2 code will look like compared to legacy, this should give a good idea:
https://github.com/fatcerberus/kh2bar/blob/master/src/main.js
miniSphere 4.5.8 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline DaVince

  • Who's an oracle? Not me!
  • Senior Staff
  • Hero Poster
  • *****
  • Posts: 742
    • View Profile
    • Vincent Beers portfolio
Re: Sphere v2 API discussion
« Reply #50 on: February 16, 2017, 11:02:39 am »
Whoa. It's really interesting to see no initializing function, and to see every script basically have its own "global"-like scope for itself. That actually seems really good to avoid conflicts because importedfunctiona.property will never clash with importedfunctionb.property.

Thank you for this example, really. It certainly answers some questions for me, just having some sample main script like this. :)

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2117
  • *MUNCH*
    • View Profile
Re: Sphere v2 API discussion
« Reply #51 on: February 18, 2017, 11:41:42 am »
I'll probably need to rename Image to Texture to maintain cross-compatibility with Oozaru, because the browser platform already includes an Image class which is incompatible with Sphere.  The rename probably makes sense anyway, since it aligns with how images are used in Galileo (i.e. you don't draw them directly, they are used to texture shapes).
miniSphere 4.5.8 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

Offline casiotone

  • Administrator
  • Low Poster
  • *****
  • Posts: 62
    • View Profile
Re: Sphere v2 API discussion
« Reply #52 on: March 22, 2017, 09:46:38 am »
5.0 will change the save data handling so that games no longer have to share the same save file folder.  How that works is you set a "save ID" in the JSON manifest and miniSphere uses that as the name of the folder.  If you have want to have sequels be able to share save data, you can just give them the same save ID.

I'm thinking there should be a standardized format for save IDs to avoid clashes, something like this maybe (inspired by Android app IDs):
Code: [Select]
com.authorname.gamename
Could this not be set at runtime? A game may want to have its own save directory but still be able to access previous game data.

Perhaps the game ID could be set in the manifest, but an optional one also at runtime - and enforcing read-only access if it isn't the ID in the manifest.

Offline Fat Cerberus

  • miniSphere Developer
  • Verified
  • Legendary Poster
  • *
  • Posts: 2117
  • *MUNCH*
    • View Profile
Re: Sphere v2 API discussion
« Reply #53 on: March 22, 2017, 09:53:29 am »
That's a good point; games may also want to access another game's data that it wouldn't necessarily need to share a save directory with.  I like the idea of enforcing read-only access too.  I'll add an issue on GitHub about it, thanks for the idea. :)
miniSphere 4.5.8 - Cell compiler - SSJ debugger
Forum Thread | GitHub Repo

 

anything