@Rahkiin - That is a good idea, as the file format docs that come with Sphere may be a bit outdated (especially the map and spriteset ones). If they're not documented on the forums for some reason, ask Radnen and Flying Jester for their findings on parsing Sphere formats (especially version inconsistencies) since they've worked with them more recently than I have. Lord English may also have a couple of notes after making some edits to Radnen's Sphere Studio. alpha123's worked with the most recent version of vanilla Sphere, but that may have been quite some time ago. The Web Sphere Utilities repo has my code for parsing the formats but it's all in web-compatible JavaScript. Pick your poison

I already implemented all file formats in my engine, by looking at the Sphere code in the sphere repo. I also tested on different files. Is that good enough? I even support all versions available (Although I might get rid of older versions later).

Keep support for older versions, or rather find some way to implicitly convert older versions to newer versions on load in the editor (eg, if old version then popup "<X> was made using an older version of the Sphere editor, would you like to convert it to the current format?").

I still recommend double-checking with at least Radnen (if you haven't looked at the Sphere Studio repo for reference) and Flying Jester as Radnen worked out some inconsistencies with the newest file versions and Flying Jester is trying to expand the formats in conjunction with the other TurboSphere expansions to Sphere.

Keep support for older versions, or rather find some way to implicitly convert older versions to newer versions on load in the editor (eg, if old version then popup "<X> was made using an older version of the Sphere editor, would you like to convert it to the current format?").

I still recommend double-checking with at least Radnen (if you haven't looked at the Sphere Studio repo for reference) and Flying Jester as Radnen worked out some inconsistencies with the newest file versions and Flying Jester is trying to expand the formats in conjunction with the other TurboSphere expansions to Sphere.

Alright then. It is there anyways. Loading takes all versions, and saving always uses the newest version. My editor could indeed ask for a direct save first.

I will look around in the other repo's later. Thanks. I have not come across any troubles really. Sometimes the format is odd, but that's about it. (For example, there are way to many reserved bytes. 248 reserved bytes to get 256 byte header is a waste of space )

// Rahkiin

The only main inconsistency I found was that when loading tilesets, the tiles name appears after the tile info block, and contains the length of the string in the block. You might already have this fixed if you followed the original C++ code, but if you followed the docs it was written wrong.

Correct tile info block:

Code: (text) [Select]

struct TILE_INFORMATION_BLOCK
  byte obsolete1_;
  byte animated;
  word nexttile;      // For animated tiles
  word delay;         // number of frames to wait until next tile switch
  byte obsolete2_;
  byte blocked;       // 0 = no obstruction data, 1 = old obstruction data, 2 = new obstruction data
  word num_segments;
  word name_length;   // see the name below the header segment
  byte reserved[20];
end struct

string name;          // strings are stored after the data block has name_length size

https://github.com/Jarvix/JSphere/blob/master/SphereRuntimeKit/SRKTileSet.m#L27
Yeah, I seem to have the correct structure. I do have a 'byte terraformed' after name_length tho. No idea what it really means, but it was there.

Thanks.

Wasn't that an addition by you, Radnen? To indicate whether a tile was filled in based on the terraforming stuff in your editor?

No, that was old. I planned on using it, maybe, but I never coded that in.

So it can be removed?

Well, yeah it can be removed, but it's still a header byte so make sure the header is the same size. If you want to continue talking about file formats I can split this topic into a new thread.

Yeah we can do that.

If you have looked at my code: I have static assertion that asserts the size of my headers at compile time No mistakes there.

I just split and moved this from 'The Wiki' in the Site Comments forum.

So the current state of the formats. I don't think much is wrong.

Then there is the SPK. As DaVince suggested, we could make a zip package and change its extension to SPK. ZIP also has the ability to use custom attributes on the package etc.
The SPK could have some default folder format, containing scripts, resources and some package descriptor.


I also want to add that the game.sgm file should really have an engine_version property. So that shims could be loaded automatically. Especially for future versions.

TurboSphere already supports a version field in SGM files.  But not in a great way for compatibility with other engines. It assumes that version=2 means that the game was designed for TurboSphere. WIthout a version field, TS loads a compatibility script, assuming the game was made for Sphere 1.5

I think we should use tarballs with gzip, zlib, or xz compression for the package format.

I think we should use plain ZIP, because that is so easy to support. I think almost all systems have native ZIP support. Tar and such is a hell to support on Windows. Also, it is a two-way extraction (first decompression, then untar).

For my standalone game release mode (MyGame.app), I am not going to use any SGM file at all. I think the format is horrible.

The version string however could be something other than just a digit. We could also make it sphere_1_6, sphere_1_7, turbosphere_1_0. (Split at underscore, combine digits, etc). I did not mean to use it for seeing if a version is older or not. I want to use it like this:

Code: [Select]

if(version == sphere_1_6)
    load_sphere16_shim()
if(version == sphere_1_5)
    load_sphere15_shim()

It would be more like an API version used by the game.