imported>Ikskoks at 21:33, 21 January 2021

2021-01-21T21:33:46Z

← Older revision	Revision as of 21:33, 21 January 2021
(No difference)

imported>Ikskoks at 21:33, 21 January 2021

2021-01-21T21:33:46Z

← Older revision		Revision as of 21:33, 21 January 2021
Line 88:		Line 88:
	* Empty images may occurr.		* Empty images may occurr.
	* There is probably some kind of animation delay value coded into one of the headers.		* There is probably some kind of animation delay value coded into one of the headers.


			[[Category:File Format]]

imported>WATTO at 15:48, 12 December 2005

2005-12-12T15:48:52Z

← Older revision	Revision as of 15:48, 12 December 2005
(No difference)

imported>WATTO at 15:48, 12 December 2005

2005-12-12T15:48:52Z

New page

== SS ==

SS files contain sprite data. They can bring their own palette and usually contain multiple sprites and thus even animations.

=== Format specifications ===

Since an SS file can contain multiple images, it has been divided into several blocks. The identification header looks this way:

<tt>
 ''' // *.ss main header ''' 
: char {4}     - Identifier ("SS4M")
: uint32 {4}   - '' Unknown '' 
</tt>

Following this main header are several blocks, each having this block header:

<tt>
 ''' // block header ''' 
: char {4}     - Block Type
: uint32 {4}   - Block Size (including header) 
</tt>

The Block Type field determines what data this block will contain. These are the currently observed block types:

==== Palette block ====

This block contains the palette for the SS file. The Block Type is<tt> "LAP "</tt>. It has its own header:

<tt>
 ''' // palette header ''' 
: uint32 {4}   - Entry Number 
</tt>

* The Entry Number value defines how many colour entries (composed of R/G/B bytes) follow this header. These are then to be set as the first entries of the complete 256 colour palette.
* The R/G/B values have been saved in the range<tt> 0..63</tt>.

==== Animation block ====

This block is a container for sprite animations. It has the Block Type<tt> "SS  " </tt>and the following header:

<tt>
 ''' // animation header ''' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - Maxmimum Sprite Width 
: uint32 {4}   - Maxmimum Sprite Height 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - Number of Frames 
</tt>

This header is then followed by a list of block-relative offset values (determined by the Number of Frames value) to the sprite images. 
At each such offset the actual sprites with their own header can be found:

<tt>
 ''' // sprite header ''' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - X Position (?) 
: uint32 {4}   - Y Position (?) 
: uint32 {4}   - Sprite Width 
: uint32 {4}   - Sprite Height 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: uint32 {4}   - ''Unknown'' 
: byte {X}     - Image Data 
</tt>

===== Notes and Comments =====

* The image data has been [[RLE|RLE]]-compressed.
* The resulting image data is stored top left to bottom right, line-wise and paletted.
* In some cases, there are consecutive identical relative offset values in the sprite list. For some reason, the following (but only the identical!) offsets have to be increased by the correct multiple of the sprite header size (since the sprite headers all exist anyway). The reasoning for this is still unknown.
* Empty images may occurr.
* There is probably some kind of animation delay value coded into one of the headers.

The Riddle of Master Lu SS - Revision history

imported>Ikskoks at 21:33, 21 January 2021

imported>Ikskoks at 21:33, 21 January 2021

imported>WATTO at 15:48, 12 December 2005

imported>WATTO at 15:48, 12 December 2005