Author Topic: PS2 Fighting Games - Breaking It All Down  (Read 2209 times)

0 Members and 1 Guest are viewing this topic.

Insanius

  • Staff
  • Member
  • *****
  • Offline Offline
  • Posts: 1109
  • ffffffffffff
PS2 Fighting Games - Breaking It All Down
« on: May 24, 2011, 12:57:31 PM »
This is my most recent obsession, and now I'm sharing it with the willing.  I've been systematically breaking apart the data files for any PS2 fighting game ports I can get my hands on, specifically SNK and Capcom games.
NameSpritesPalettesAxisBoxesAnimations
King of Fighters XIYesYesIn Anim DataIn Anim DataPartial
Neo Geo Battle ColiseumYesYesIn Anim DataIn Anim DataPartial
King of Fighters 2002 UMYesYesNoNoNo
King of Fighters 2003YesYesNoNoNo
King of Fighters 2002YesYesNoNoNo
King of Fighters 2001YesNoNoNoNo
King of Fighters 2000YesNoNoNoNo
King of Fighters '99NoNoNoNoNo
Garou: Mark of the WolvesYesYesNoNoNo
King of Fighters '94 ReBoutYesYesNoNoNo
Capcom vs SNK 2YesYesYesNoNo
Marvel vs Capcom 2NoYesYesNoNo
Capcom Fighting EvolutionNoYesYesNoNo
Shin Gouketsuji Ichizoku: Bonno no KaihoYesNoYesYesNo

Some code will be posted later, but here's some info on the different data types:

AFS - Standard pack file for PS2 games, found in Capcom games and in KOF NESTS Collection.  http://wiki.xentax.com/index.php/GRAF:AFS_AFS

GRC - Used by SNK games as a compressed file format.  May store game data in early games, later games use these only for gallery art.  The compression scheme was figured out by mauve and is as follows:

Read in one byte at a time
If this byte is less than 0xc0 output it.
If this byte is 0xc0 end decompression.
If this byte is 0xc1 output the next byte directly.
If this byte is greater than 0xc1, subtract 0xc0.  This is the number of bytes that will be copied.  Read in the next byte, this is the number of bytes back to start copying data from.

The following games also use this compression scheme for sprite tile data:
KOF 2002
MOTW
KOF 2003
KOF '94 ReBout

SNK Pack Files -
The way SNK stores their character data is almost never the same, but they always have a few things in common.  The filenames are typically prefixed with a P or PL.  At the beginning of the file is always a table of file offsets, possibly preceded by a four byte integer containing the number of subfiles.  Among all these subfiles, the largest one for any character will be one containing sprite/tile data.  Sometimes the sprite data is separated from the tile data, sometimes it isn't.  If it is not separate, it will be compressed.

SNK Sprite Data -
Again, this varies immensely from game to game, but there are similarities.  There is always a table of offsets at the beginning of the file pointing to each sprite entry.  Offsets 0x80000000 and below point to invalid sprite data and should be ignored.  Each entry may or may not be preceded by a byte indicating the total size of the sprite header.  These usually also carry the tile data within.  Other common things in the sprite data include
4bit Palette # (Palettes are 16 colors, so effects and such will use a different palette.)
1byte X and Y dimensions (In tiles, tiles can be 8x8 or 16x16)
Every SNK game includes a tilemap as part of the sprite data.  If Y size is less than or equal to 8, then the tilemap is X size bytes.  If it is greater than 8, the tilemap uses double that size.  Each byte (or byte pair for the larger ones) represents one column of tiles in the sprite.  Starting with the highest bit, each bit in the tilemap is checked.  Zeroes represent blank tiles, and ones represent places where there should be tile data.

FIRST.GRC -
A lot of SNK games pack the palettes into this file.  After decompressing it, it's just a standard SNK pack file.  The first subfile will contain the palette data, although the exact format may vary.

Capcom vs SNK 2 tile data -
This was deceptively easy to figure out, and I'm still not sure I have it totally right even though my sprite rips are fine.  Data starts with a four byte header.  The first two bytes are the actual dimensions of the tile (multiply by 8 ) and the second two bytes are the dimensions required to decompress properly.  After the header, read in a byte and check each bit starting from the highest.  For each 0, read in a byte and output it.  For each 1, read in a byte and split it.  The lower 4 bits +2 are the number of bytes to copy, the higher 4 bits +1 is how far back in the output buffer to copy from.  Decompression should stop when the output buffer is full.
If the decompression dimensions have a greater X than Y, the data needs to be rearranged.  Use the Y dimension as the tile size and move data so that it is tiled horizontally instead of vertically.

Capcom vs SNK 2 sprite data -
In CvS2 sprites are drawn as the data is parsed, so you need an arbitrarily sized canvas and an arbitrary point to draw a sprite from.  It starts with two bytes as the number of tiles, then loops.  Keep track of the current axis (CAXIS) and start it at your arbitrary point.  For each tile, read in two shorts.  Add these as X and Y coordinates to your CAXIS.  The next two bytes are data flags.  The second byte determines if the tile needs to be flipped horizontally (0x80), vertically (0x40), or both (0xc0).  The last short is the tile index.

Gonna upload all my code soon, it's a mess though!

Anjel

  • V.I.P.
  • Member
  • *****
  • Offline Offline
  • Posts: 39
Re: PS2 Fighting Games - Breaking It All Down
« Reply #1 on: May 26, 2011, 10:59:51 AM »
 :phappy:

 

general forums