Skip to main content ↑ ↓
Topic: Future of Sphere: SGM v2 and beyond (Read 72419 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Future of Sphere: SGM v2 and beyond

As recently as this post in the TurboSphere thread the limited ability of the current SGM format has come into question and once again discussion of extending it has arisen. I agree that the existing format is limited and vanilla Sphere 1.5 doesn't even allow keeping manual edits!

The main topics at hand are the text format of the file (with the most popular choices being XML, BML, and retaining its current INI style), what per-game settings would be stored, and nomenclature for those settings.

Each text format has its pros and cons, with INI style having the primary advantage of being backwards compatible with current implementations of Sphere (unhandled settings being ignored in forks and in vanilla Sphere once that bug is fixed and pushed). BML is fairly custom but easily parsed. XML is XML.

Continue the discussion in this thread!

Re: Future of Sphere: SGM v2 and beyond

Reply #2 –
Indeed.

Here is how TS engine files look. I like sectioned INI files. T5 at least even has support for non-contiguous sections and section resetting (lack of a section is equivalent to "[]" being prepended to the file).

These have the advantage of being easy to read, easy to parse (even in C++, where XML would be an extra complication), maintaining a certain amount of backward compatibility, and still being extendible.

For TurboSphere at least, I will make the engine.ini format follow the format of the s2gm files. I would actually like to see the engine.ini being a file for defaults, and the s2gm would override selected settings, in addition to containing the game's meta data.

As for what settings would be included, here is what I was thinking (plus what DaVince pointed out):

1. Game Title
2. Author
3. Description
4. WxH
5. Scale
6. v-filter
7. Fullscreen
8. launguage (as in locale?)
9. Known usuable Sphere version
10. Things to disable (plugins, networking, maybe other stuff)

I would think that there could also be engine-specific stuff in there, too. Like the info at the end of TurboSphere's stock engine.ini file, which would go under a 'TurboSphere' section.

Re: Future of Sphere: SGM v2 and beyond

Reply #3 –
Hmm, I was hesitant on using ini since in C# there are zero ini readers. I'll have to P/Invoke it out of the core windows library, and I don't want to do that, ever. XML is 1000x easier to use under .NET, oh well. I'll have to construct or find an ini implementation that doesn't use P/Invoke... or at least is mono compatible. But I digress, I think I found one long ago, but never used it. Here it is: https://code.google.com/p/ini-parser/

Anyways, I like your layout for the ini, Jest.

So, I was thinking 'Language' as in programming language. Because I meant for this to be an open format for any kind of sphere. 'Locale' would be used for spoken language. I was also thinking about adding an associated icon to it. Because I was thinking it may come in handy when packaging your game up. It might be possible to change the icon of a packaged exe - even if it means somehow changing the icon of engine.exe.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here
 

Re: Future of Sphere: SGM v2 and beyond

Reply #4 –
Quote from: Radnen – on

Hmm, I was hesitant on using ini since in C# there are zero ini readers. I'll have to P/Invoke it out of the core windows library, and I don't want to do that, ever. XML is 1000x easier to use under .NET, oh well. I'll have to construct or find an ini implementation that doesn't use P/Invoke... or at least is mono compatible. But I digress, I think I found one long ago, but never used it. Here it is: https://code.google.com/p/ini-parser/


Yeah, it's the opposite over in C++. Almost all XML libraries are pretty ugly (either WAY larger and more resource hungry than a file parser should be, or way more complicated to use than they should be).

But if it was a matter of writing an XML parser in C++ or an INI parser in C#, I'd tend to prefer having to write INI functionality in C#.
Actually, I already did write an INI parser in C++, and it was pretty easy. That's what libT5 (T5) does.

Quote from: Radnen – on
It might be possible to change the icon of a packaged exe - even if it means somehow changing the icon of engine.exe.


The last few releases of TurboSphere that had the turbocharger icon didn't have the icon baked in by the compiler--I used the Resource Hacker. So you can really change any exe's icon (as long as it has a resource section to hold it to begin with, if you use Resource Hacker).

Re: Future of Sphere: SGM v2 and beyond

Reply #5 –
Regarding XML in c++, there's a nice XML lib for C++ called TinyXML that I used to use, and it's exactly what it says on the tin: an easy-to-use, tiny XML parser (a single .cpp file IIRC), and I believe it's under a BSD or similar license. You wouldn't have to roll your own this way.

Re: Future of Sphere: SGM v2 and beyond

Reply #6 –
Next to having a Sphere version, having a game version available would be nice too. And full multi-line descriptions should be using \n. :)

Re: Future of Sphere: SGM v2 and beyond

Reply #7 –
I love how the forums are so dead here that we can necropost and nobody bats an eye.  Okay, no, I don't really like it, it's kind of depressing sometimes. :'(  I feel like it must be a bad thing that a thread at the bottom of the [/i]first page[/i] is over a year and a half old...

Incidentally, minisphere won't overwrite the SGM file on startup.  I never did figure out why Sphere does that... Maybe as a sanity check to ensure the game directory is writable?  That's the only thing that would make sense to me.

Re: Future of Sphere: SGM v2 and beyond

Reply #8 –
Maybe we could ask Chad?

Re: Future of Sphere: SGM v2 and beyond

Reply #10 –
So... I'm just going to casually necropost again to mention that minisphere 2.0+ includes support for a new S2GM format which is JSON-based and exposes all values in the file to script, even the ones not directly used by the engine.  Since we're using JS pervasively (even Cell uses it!), JSON was a no-brainer.

So... I guess we can consider this a solved problem now. :)

The great thing about the JSON-based format is that it's extensible.  For example you could have a library that read some of its settings from the manifest, without having to keep adding options to the initialization API.  Call GetGameManifest() and everything defined in the S2GM is there.

Re: Future of Sphere: SGM v2 and beyond

Reply #11 –
Well, the only real issue with ini over json is that it is not as standardized. In T5, all the features of JSON are included in INI as extensions. You can losslessly convert from one to the other (using the t5convert utility).

TurboSphere has long supported game.sgm being JSON (and required it if pointed at a file with the 'tsgm' extension). I agree that JSON is the obvious choice, and in general we should never really have very many uses for XML in a Sphere-like environment.

Re: Future of Sphere: SGM v2 and beyond

Reply #12 –
I actually really like the INI format.  It's incredibly easy to parse even without a regex, scales well to large numbers of values (Windows applications got by for years putting all their settings in win.ini), and is simple and intuitive to read and modify.  I just felt that, for Sphere games in particular, JSON was a better fit since I could just make the data available verbatim to game code, with no conversion needed other than JSON.parse() already built into all modern JS engines (and failing that, good old eval() works just as well).

One feature of TurboSphere I really like that I will probably steal at some point is the ability to have any filename for the .s2gm file.  Currently it's limited to game.sgm or game.s2gm for simplicity of implementation, but being able to name it anything would make it a lot more flexible.