Skip to main content

News

Topic: Question regarding RSS spriteset format (Read 1835 times) previous topic - next topic

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Question regarding RSS spriteset format
I'm having a hard time deciphering the RSS spec.  V1 is easy, it's just a header and then 64 bitmaps total (8 directions, 8 frames each).  V2 is a stumper though:

Code: [Select]
== VERSION 2 ==

There are num_direction directions stored in the file. A direction is just a row of sprites.
The first eight directions actually represent directions that the character can walk, in
the following order:

north
northeast
east
southeast
south
southwest
west
northwest

The rest of the directions can represent anything, including emotions or special movement such
as jumping or running.

---- direction header (64 bytes) ----
word num_frames;
byte reserved[62];

---- frame header (32 bytes) ----
word width; // obsolete
word height; // obsolete
word delay;
byte reserved[26];


Where in this are the bitmaps stored?  Interleaved with the headers, before them, after them...?  The spec doesn't say.  Also, only V3 allows custom-named directions; when loading V2 spritesets with more than 8 directions, what do I set as a default name for directions past the eighth?
  • Last Edit: February 13, 2015, 11:15:14 am by Lord English
miniSphere 5.2b3 (stable: 5.1.3) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

Re: Question regarding RSS spriteset format
Reply #1
https://github.com/FlyingJester/TurboSphere/blob/master/bin/system/scripts/turbo/spriteset.js#L71
https://github.com/sphere-group/formats/blob/master/spriteset.json

In version 3, after the header, we have all spriteset images, nothing between the images.

After the images each direction has the following header:

Code: [Select]

{"size":2, "type":"number", "name":"num_frames"},
{"size":6, "type":"reserved"},
{"size":2, "type":"string", "name":"name"}


Following this, we have a frame header:

Code: [Select]

{"size":2, "type":"number", "name":"frame_index"},
{"size":2, "type":"number", "name":"delay"},
{"size":4, "type":"reserved"}


It's important to note that I have found strings NULL terminated here in the direction names. I have no idea why that is, they still have their lengths prepended.

I believe that V2 has the same kind of direction header, complete with name string.
  • Last Edit: February 13, 2015, 01:38:14 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Question regarding RSS spriteset format
Reply #2
Yeah, V3 I was able to figure out from the spec (which is a good thing otherwise minisphere would be useless ;)), it's just V2 that I can't figure out where the images are.  I assume they're all bunched together like the other two versions, I just don't know if they're before or after the direction and frame headers.

The NUL terminated strings are good to know about though, that explains the length - 1 in Sphere Studio's RSS loader.  In the case of such a string, does the stored length include the NUL or not?  If not, that complicates things.
  • Last Edit: February 13, 2015, 02:07:59 pm by Lord English
miniSphere 5.2b3 (stable: 5.1.3) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

Re: Question regarding RSS spriteset format
Reply #3
The length is the length of the string. In this one case, there may be NULL(s) on the end. So it's consistent in that way, the string includes the null, and really is that length.

I don't really know about V2. I read the images after the direction headers. But it doesn't really matter too much. I highly doubt any of us will see a V2 spriteset.
  • Last Edit: February 13, 2015, 02:36:01 pm by Flying Jester

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • miniSphere Developer
Re: Question regarding RSS spriteset format
Reply #4
Yeah, right now minisphere can load version 1 and version 3 spritesets, but V2 will just fail to load (gracefully, of course).  Shouldn't be too much of an issue, as you said--Sphere Studio won't even load anything below V3.

Honestly, I was just going for full compatibility, but Duktape is proving to me that I'm never going to get 100% Sphere 1.5 compatibility just by virtue of Duktape not allowing certain ancient constructs that Sphere 1.x SpiderMonkey includes.  For example, Duktape doesn't recognize __defineGetter__ and __defineSetter__, which I think a good number of existing Sphere games use.
miniSphere 5.2b3 (stable: 5.1.3) - Cell compiler - SSj debugger - thread | on GitHub
For the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enourmous man eating pigs ~Rhuan

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Question regarding RSS spriteset format
Reply #5
For reference, for spritesets (and pretty much all the bitmap Sphere formats except maps) you can also check the source JS of the format test loading web page I wrote to confirm that Sphere formats are indeed readable by modern web JS.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Question regarding RSS spriteset format
Reply #6

Yeah, right now minisphere can load version 1 and version 3 spritesets, but V2 will just fail to load (gracefully, of course).  Shouldn't be too much of an issue, as you said--Sphere Studio won't even load anything below V3.


I'm surprised games from 2003 still load, v3 goes way back. You'll rarely come across v1 (if ever) or v2(few) spritesets. I could have made full support here, but I thought, hey, only add this if it ever becomes an issue... and so far it really hasn't.
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