YesNoOk
avatar

SFFv2 Format Information (Read 41279 times)

Started by O Ilusionista, September 29, 2009, 01:25:26 am
Share this topic:
SFFv2 Format Information
#1  September 29, 2009, 01:25:26 am
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
Elecbyte SFFv2beta format information
-------------------------------------------------
by Romhack( 09/28/2009 )

WARNING: Poor English!

Update 09/29/2009


NOTES:
24bit, missed;


SFFv2 Header

+--------+------------------------------+------+
| Offset | Description                  | Size |
+--------+------------------------------+------+
|  +$00  | ElecbyteSpr signature        |  12  |
+--------+------------------------------+------+
|  +$0C  | VersionLo3                   |   1  |
+--------+------------------------------+------+
|  +$0D  | VersionLo2                   |   1  |
+--------+------------------------------+------+
|  +$0E  | VersionLo1                   |   1  |
+--------+------------------------------+------+
|  +$0F  | VersionHi                    |   1  |
+--------+------------------------------+------+
|  +$10  | ??? set to 0                 |  10  |
+--------+------------------------------+------+
|  +$1A  | Palette map offset           |   4  |
+--------+------------------------------+------+
|  +$1E  | ??? set to 0                 |   6  |
+--------+------------------------------+------+
|  +$24  | SpriteList offset            |   4  |
+--------+------------------------------+------+
|  +$28  | Number of sprites            |   4  |
+--------+------------------------------+------+
|  +$2C  | ??? set to 0x200             |   4  |
+--------+------------------------------+------+
|  +$30  | Number of palettes           |   4  |
+--------+------------------------------+------+
|  +$34  | Palette bank offset          |   4  |
+--------+------------------------------+------+
|  +$38  | OnDemand DataSize            |   4  | <- Palettes + SpritesData(OnDemand)
+--------+------------------------------+------+
|  +$3C  | OnDemand DataSize Total      |   4  | <- Header + PaletteMap + SpriteList + OnDemand DataSize
+--------+------------------------------+------+
|  +$40  | OnLoad DataSize              |   4  | <- SpritesData(OnLoad)
+--------+------------------------------+------+
|  +$44  | unused???                    | 444  |
+--------+------------------------------+------+



SpriteList Node Header

+--------+-----------------------+------+
| Offset | Description           | Size |
+--------+-----------------------+------+
|  +$00  | Sprite group          |   2  |
+--------+-----------------------+------+
|  +$02  | Sprite number         |   2  |
+--------+-----------------------+------+
|  +$04  | Sprite image width    |   2  |
+--------+-----------------------+------+
|  +$06  | Sprite image height   |   2  |
+--------+-----------------------+------+
|  +$08  | Sprite image Xaxis    |   2  |
+--------+-----------------------+------+
|  +$0A  | Sprite image Yaxis    |   2  |
+--------+-----------------------+------+
|  +$0C  | Sprite linked index   |   2  |
+--------+-----------------------+------+
|  +$0E  | Compression method    |   1  |
+--------+-----------------------+------+
|  +$0F  | Color depth           |   1  |
+--------+-----------------------+------+
|  +$10  | Offset to data*,**    |   4  |  see notes
+--------+-----------------------+------+
|  +$14  | Data length**         |   4  |  see notes
+--------+-----------------------+------+
|  +$18  | Palette number        |   2  |
+--------+-----------------------+------+
|  +$1A  | Load Mode             |   2  |
+--------+-----------------------+------+
 
Palette map:
+--------+-----------------------+------+
| Offset | Description           | Size |
+--------+-----------------------+------+
|  +$00  | Palette group         |   2  |
+--------+-----------------------+------+
|  +$02  | Palette number        |   2  |
+--------+-----------------------+------+
|  +$04  | Total of colors       |   4  |
+--------+-----------------------+------+
|  +$08  | Offset to data*       |   4  |  see notes
+--------+-----------------------+------+
|  +$0C  | Palette length        |   4  |
+--------+-----------------------+------+
 
NOTES:
-------
 *   To calcule effective file address:
     OnDemand:  (PaletteBank Offset + Offset to data)
     OnLoad:    (SpriteData Section Start Offset + Offset to data)

 **  Linked sprites has length 0, but the offset is
     the same of his parent;
 
Load Modes:
 OnDemand(default) - 0x00 (sprite.decompressonload=0)
 OnLoad            - 0x01 (sprite.decompressonload=1)

Compression Method:
 NONE  - 0x00
 ???   - 0x01
 RLE8  - 0x02
 RLE5  - 0x03
 LZ5   - 0x04

 
SFFv2 file structure:
------------------------------------

 +---------------------------------+
 | SFFv2 Header                    |
 +---------------------------------+
 | Palette Map, linear             |
 | 16bytes per map                 |
 +---------------------------------+
 | Sprite List, linear             |
 | 28bytes per node                |
 +---------------------------------+ PaletteBank Section
 | Palette bank, linear            |
 | size is 4*colors of current pal |
 +---------------------------------+ SpriteData Section
 | Sprite data OnLoad, linear      |
 +---------------------------------+
 | Sprite data OnDemand, linear    |
 +---------------------------------+






  
It is also important to note that the images are not saved in the PNG file they are turned into raw data and then compressed with algorithms.

TOPIC UPDATED
Last Edit: September 29, 2009, 08:02:18 pm by .(O).
Re: SFFv2 Format Information
#2  September 29, 2009, 12:27:56 pm
  • ***
  • I never really was on your side.
    • www.mugenguild.com/~davidgee
Re: SFFv2 Format Information
#3  September 29, 2009, 01:55:58 pm
  • ***
  • Snake Man
    • tunglashor.webnode.com
I take that to mean the actual sprite data in the SFF is not in PNG format (unlike in the old format, where each PCX file was embedded in SFF).  So it won't be as easy as just reading in that data and treating it as a PNG - it needs to be decompressed first.
Re: SFFv2 Format Information
#4  September 29, 2009, 05:24:57 pm
  • ******
  • [E]
    • Mexico
does the same thing apply to pcx files?
Re: SFFv2 Format Information
#5  September 29, 2009, 05:29:09 pm
  • ******
  • Just a butcher on a mission
    • www.justnopoint.com/lbends
Seeing how there's no identifier for the sprite data other than the compression scheme I'd have to say yes.

This is a good thing from an implementation standpoint.  When more editing programs get developed the only requirement for them to add sprites is to be able to read them.  PCX and PNG are not required, whereas with the old sff format a conversion to PCX (by the user or the program) was necessary.
Re: SFFv2 Format Information
#6  September 29, 2009, 05:57:36 pm
  • ******
  • [E]
    • Mexico
the raw data is also faster to put in memory, specially considering that sdl suport those raw data formats, so it should improve performance.
Re: SFFv2 Format Information
#7  September 29, 2009, 11:27:38 pm
  • ***
  • I never really was on your side.
    • www.mugenguild.com/~davidgee
OK so the "raw data" is some SDL class then? Anyone read the images yet? And I wonder if SDL also deals with the compression.
Re: SFFv2 Format Information
#8  September 30, 2009, 12:06:12 am
  • ******
  • [E]
    • Mexico
I checked out sdl a few years ago, it could handle rle8 raw data sprites, which meant far less memory use; maybe the current version can handle rle5 as well.

Re: SFFv2 Format Information
#9  September 30, 2009, 02:25:38 am
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
topic updated, I forgot to tell.

and yes: AFIAK, it applies the same to pcx.
Re: SFFv2 Format Information
#10  October 04, 2009, 06:47:39 pm
  • **
  • 7|-|ê ®è©£ü§É
    • www.youtube.com/rkmugen
Praying for an updated FighterFactory!  ='(
Re: SFFv2 Format Information
#11  October 04, 2009, 10:15:06 pm
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
Its on the way...
Re: SFFv2 Format Information
#12  November 12, 2016, 01:18:45 am
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Bigass bump due to me doing some development with this...


Compression Method ==0x01 seems to be for linked sprites, and most likely means "use the same compression algorithm as used for the linked sprite"
Re: SFFv2 Format Information
#13  November 18, 2016, 09:34:13 pm
  • ***
  • Snake Man
    • tunglashor.webnode.com
I wouldn't rely on that as according to Elecbyte a value of 1 = "invalid (no use)".
I'm pretty sure any sprite with length = 0 is treated as a link and the compression method flag is ignored.
Re: SFFv2 Format Information
#14  November 20, 2016, 11:26:32 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Yeah, that's the definition for a linked sprite. Still, may be best to treat 1 as "use the same compression as linked," that is, if it's linked. Which seems to be the case for the sprites I've found.

Also, 24-bit (and 32-bit, in SFFv2.1) sprites are still uncompressed only as of 1.1b, correct?
Last Edit: November 20, 2016, 11:32:30 pm by Jesuszilla
Re: SFFv2 Format Information
#15  November 21, 2016, 10:36:12 pm
  • ***
  • Snake Man
    • tunglashor.webnode.com
Yeah, that's the definition for a linked sprite. Still, may be best to treat 1 as "use the same compression as linked," that is, if it's linked. Which seems to be the case for the sprites I've found.
What would you do differently if the length was 0 and this value wasn't 1?  You will always need to use the decompression method of the linked sprite, so there's no reason to interpret this value at all.  It may be that whatever software encoded the SFF always writes a 1 for linked sprites but that's not in the spec, so it's best not to depend on it (otherwise you'll potentially get errors reading correctly-encoded SFFs that don't share this quirk).

Also, 24-bit (and 32-bit, in SFFv2.1) sprites are still uncompressed only as of 1.1b, correct?
No, SFFv2.01 also supports PNG compression:

comp method     meaning
0x0APNG8
0x0BPNG24
0x0CPNG32

These are just embedded PNGs so you can pass the data straight to a suitable decoding routine.  Just remember to skip the first 4 bytes, which contain the size of the sprite data in bytes (if I remember right that's the case for all formats).
Re: SFFv2 Format Information
#16  December 10, 2017, 05:35:05 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Bump again!

I'm creating a new SFF tool that I want to be compatible with SFFv2.0 and SFFv2.01. However, MUGEN doesn't seem to be applying alternate palettes to the character sprites. The Palette number is set to 0, the palette keymap is defined, the pal.defaults are defined... I even tried blanking out the PNG PLTE section with 0's with the correct checksum, yet MUGEN 1.1 doesn't seem to want to apply the selected palette no matter what I do. I tried saving with Fighter Factory too and it seems to have this same problem. Any ideas?

@O Ilusionista: @tunglashor:
Last Edit: December 10, 2017, 08:10:50 pm by Jesuszilla
Re: SFFv2 Format Information
#17  December 22, 2017, 01:21:08 am
  • ******
  • A living Mugen dinossaur :)
  • 23 years of Mugen O_o
    • Brazil
    • www.brazilmugenteam.com
Sorry, I just saw this now. I've reported this to Virtualtek
Re: SFFv2 Format Information
#18  December 22, 2017, 11:51:14 am
  • ***
  • www.virtualltek.com
    • Brazil
    • www.virtualltek.com
The sprites you want to have alternate palette are set to a palette of group 1?
Re: SFFv2 Format Information
#19  December 22, 2017, 03:50:45 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
Correct.
Re: SFFv2 Format Information
#20  December 28, 2017, 06:18:22 pm
  • ***
  • www.virtualltek.com
    • Brazil
    • www.virtualltek.com
I'm doing some tests on this and really, it's very strange. It just ignore alternate palettes, even on Mugen 1.0 and SFF 2.0.
The docs just says about group 1,1 to 1,6 and no other clue. Tried reordering palettes and sprites (if must be in some order), forced 0 on alpha values, removed PLTE chunk of PNGs (but the problem happens on RLE8 too). Seems to be unrelated to compression method.