I really like that idea. It opens up interaction with other games, sequels, or even stuff like save file managers.

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.

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?

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.

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

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.

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).

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.

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.

New Sphere v2 Sample object (analogue to the v1 SoundEffect API):
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-api.txt#L1001-L1047

In the spirit of reusing a sample for multiple playbacks of a sound effect, the playback parameters (pitch, speed, volume) get passed as options to play() instead of being associated with the Sample object.  I always found the way Sphere v1 handled that to be weird and unintuitive, never sure whether setting a value would apply to currently playing instances of a sound or only future playbacks (spoiler: it's the latter).  At least this way the API is very clear.

New Sphere v2 Sample object (analogue to the v1 SoundEffect API):
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-api.txt#L1001-L1047

In the spirit of reusing a sample for multiple playbacks of a sound effect, the playback parameters (pitch, speed, volume) get passed as options to play() instead of being associated with the Sample object.  I always found the way Sphere v1 handled that to be weird and unintuitive, never sure whether setting a value would apply to currently playing instances of a sound or only future playbacks (spoiler: it's the latter).  At least this way the API is very clear.

Now that is an awesome feature I like the sound of - when are you planning the next miniSphere release to include it?

I'm planning a 4.6 release soon, but there are a few more changes I want to work out first (such as the engine not installing on Ubuntu 16.10 and later).  Should be within the next couple of weeks if all goes well.  I was originally going to hold off on doing any more releases until 5.0, but there are a few annoying bugs that need to be fixed--Dispatch jobs rendering in the wrong order, for example--so an interim release is called for.

I'm planning a 4.6 release soon, but there are a few more changes I want to work out first (such as the engine not installing on Ubuntu 16.10 and later).  Should be within the next couple of weeks if all goes well.  I was originally going to hold off on doing any more releases until 5.0, but there are a few annoying bugs that need to be fixed--Dispatch jobs rendering in the wrong order, for example--so an interim release is called for.

Ok I've got a few other things on as well at the moment as well, I'll plan on building a mac version of 4.6 and uploading it.

If anyone wants to see what a real Sphere v2 game will look like, see the code for my kh2Bar showcase.
https://github.com/fatcerberus/kh2bar

The demo uses the engine's event loop rather than running its own and thus should be compatible with Oozaru in the future too.

Note that the code will only run on miniSphere 4.6, which is not released yet and requires building from source.  The release is almost done, but there are a couple loose ends I have to tie up (like Ubuntu 16.10+ compatibility).

miniRT is now called Sphere Runtime and is an official part of Sphere v2.  Here's what the API for it will look like in miniSphere 4.6:
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-hl-api.txt