Skip to main content ↑ ↓
Topic: File Formats (Read 79497 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

File Formats

Quote from: N E O – on

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

Re: Re: The Wiki

Reply #1 –
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.

Re: Re: The Wiki

Reply #2 –
Quote from: N E O – on

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 :P)

// Rahkiin
 

Re: Re: The Wiki

Reply #3 –
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
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: Re: The Wiki

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

Re: Re: The Wiki

Reply #6 –
No, that was old. I planned on using it, maybe, but I never coded that in.
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: Re: The Wiki

Reply #8 –
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.
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: File Formats

Reply #10 –
I just split and moved this from 'The Wiki' in the Site Comments forum.
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: File Formats

Reply #11 –
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.

Re: File Formats

Reply #12 –
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.

Re: File Formats

Reply #13 –
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.