Difference between revisions of "SHP & Graphic info page"

From Final Fantasy Hacktics Wiki
Jump to navigation Jump to search
m
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
<font face='Courier New'>
+
SHP (Shape) files contain the information to construct each frame of animation for a [[unit]] or a [[weapon and its effect]]. While [[SEQ & Animation info page|SEQ]] files describe in what order these frames are strung together, Shape files contain the raw data describing how they are loaded from the sprite sheet and constructed on screen.
 
   
 
   
−
  This is a list of the currently discovered SHP info and quirks, particularly for woosh effects, weapons, and units. Currently, ability effects are unexplored.
+
==Section 1==
 +
Using Type 1 SHP as an example:
 +
          |Swim Ptr. |Atk |SP+ |
 +
00000000: B2 0E 00 00 54 00 FF 00
 +
these first few bytes dictate some information regarding loading graphic data:
 +
*Swim Ptr. - this number points the game to where the start of the swimming graphics start. for type 1/2/cyoko units, this is about halfway through the file. monsters do not have swimming graphics.
 +
*Atk      - first frame to load from the second half of a unit's spritesheet
 +
*SP+      - first frame to load from SP2 (or greater if iron giant) (UNSURE)
 +
 
 +
The structure is slightly unique for WEP/EFF files. using WEP1 as an example:
 +
          |Zero      |Fists|Knife|Sword|KnSwd|...
 +
00000000: 00 00 00 00 00 00 00 00 28 00 28 00 ...
 +
these first few bytes dictate the 0-frame of the weapon to be animated. The data that seems to be related to hats/helmets in this category is actually for bombs and shuriken. (0x2c & 0x2e)
 +
 
 +
==Section 2==
 +
Using Type 1 SHP as an example:
 +
          Frame 1    |Frame 2    |Frame 3    |Frame 4    |...
 +
00000008: 00 00 00 00 06 00 00 00 0C 00 00 00 12 00 00 00 ...
 +
These are all pointers to each frame. This section is 0x400 bytes long, except for WEP/EFF, in which it is 0x800 bytes long. (0xff frames, or 0x1ff frames.)
 +
 
 +
==Section 3==
 +
Using Type 1 SHP as an example:
 +
          Size |Frame 1          |Frame 2          |...
 +
00000408: A8 0A 00 00 FC FC DE 02 00 00 EF DD 00 2C ...
 +
*Size - this is the size of the block of frame data.
 +
This information consists of the data to compile each frame. (see Below.)
 +
 
 +
==Noteworthy RAM locations==
 +
0x800962f4 - Location of first unit sprite loaded section 1 + 2 (minus swimming sprite pointer)
 +
 
 +
0x800bdf0c - location of first WEP/EFF loaded section 1 + 2 (may be variable?)
 +
 
 +
0x800946c8 - Graphic size pairs (words, only loaded in pairs, height and width)
 
   
 
   
−
  SHP unit data layout:
+
==Frame Data Layout==
−
  0x00 - start of attacking frames (load from second half of sprite sheet)
+
each byte here is represented in bit-combined form, as that is how the data is constructed (0x7 for example means all 3 bits 0x1, 0x2, and 0x4 contribute to the information)
−
  0x04 - ??
+
  0x00:  
−
0x08 - Frame pointers (+ frame * 4)
+
  - 0x07 - No. graphics to load
−
   
+
  - 0xf8 - pointer to pre-existing Y rotation
−
TYPE1 : 0x800962f4
+
  0x01
−
TYPE2 : 0x8009697c
+
  - 0x61 - VRAM flags for this frame (needs investigating, 0x40, 0x20)
−
CYOKO : unsure
+
- 0x60 - transparency type (see [[P00 GetTpage]])
−
MON  : 0x8009768c
+
- 0x01 - transparent flag
−
RUKA  : unsure
+
  - 0x1e - ?
−
KANZEN: unsure
+
  - 0x80 - ?
−
 
−
SHP weapon data layout:
 
−
  0x00 - + weapon type ID * 4 gives 0-frame for weapon
 
−
0x40 - frame pointers (+ frame * 4)
 
−
 
−
WEP1  : unsure
 
−
WEP2  : unsure
 
−
EFF1  : unsure
 
−
EFF2  : unsure
 
−
 
−
0x800946c8: Graphic size pairs (words, only loaded in pairs, height and width)
 
−
 
−
Graphic information layout:
 
−
0x00 - 0x01:
 
−
  - 0b[_ _ _ _ _] Rotation pointer (only values up to 0b11001 (0xc8) point to anything other than no rotation)
 
−
  - 0b[_ _ _] # of graphics to load - 1 (0 is one graphic, 1 is two graphics, so on and so forth)
 
 
  0x02: x shift
 
  0x02: x shift
 
  0x03: y shift
 
  0x03: y shift
−
  0x04 - 0x05:
+
  0x04 - 0x05 (values are when loaded as a half word)
−
- 0b[_ _ _ _ _ _] Size pointer, points to two values that are raw graphic height and width. This roughly coincides with locking to an 8x8 grid on a spritesheet.
+
  - 0x001f - load location of top-left corner in x tiles
−
- 0b[_ _ _ _ _] Y tile offset, how many 8x8 grids down is the graphic
+
  - 0x03e0 - load location of top-left corner in y tiles
−
- 0b[_ _ _ _ _] X tile offset, how many 8x8 grids down is the graphic
+
  - 0x3c00 - reference to pre-existing x/y size (in tiles, see above)
 +
  - 0xc000 - reversal bytes
 
  0x02 - 0x05 are repeated depending on how many graphics are loaded.
 
  0x02 - 0x05 are repeated depending on how many graphics are loaded.

Latest revision as of 02:52, 29 November 2023

SHP (Shape) files contain the information to construct each frame of animation for a unit or a weapon and its effect. While SEQ files describe in what order these frames are strung together, Shape files contain the raw data describing how they are loaded from the sprite sheet and constructed on screen.

Section 1

Using Type 1 SHP as an example: 

         |Swim Ptr.  |Atk |SP+ |
00000000: B2 0E 00 00 54 00 FF 00

these first few bytes dictate some information regarding loading graphic data:

  • Swim Ptr. - this number points the game to where the start of the swimming graphics start. for type 1/2/cyoko units, this is about halfway through the file. monsters do not have swimming graphics.
  • Atk - first frame to load from the second half of a unit's spritesheet
  • SP+ - first frame to load from SP2 (or greater if iron giant) (UNSURE)

The structure is slightly unique for WEP/EFF files. using WEP1 as an example: 

         |Zero       |Fists|Knife|Sword|KnSwd|...
00000000: 00 00 00 00 00 00 00 00 28 00 28 00 ...

these first few bytes dictate the 0-frame of the weapon to be animated. The data that seems to be related to hats/helmets in this category is actually for bombs and shuriken. (0x2c & 0x2e)

Section 2

Using Type 1 SHP as an example: 

          Frame 1    |Frame 2    |Frame 3    |Frame 4    |...
00000008: 00 00 00 00 06 00 00 00 0C 00 00 00 12 00 00 00 ...

These are all pointers to each frame. This section is 0x400 bytes long, except for WEP/EFF, in which it is 0x800 bytes long. (0xff frames, or 0x1ff frames.)

Section 3

Using Type 1 SHP as an example: 

          Size |Frame 1          |Frame 2          |...
00000408: A8 0A 00 00 FC FC DE 02 00 00 EF DD 00 2C ...
  • Size - this is the size of the block of frame data.

This information consists of the data to compile each frame. (see Below.)

Noteworthy RAM locations

0x800962f4 - Location of first unit sprite loaded section 1 + 2 (minus swimming sprite pointer)

0x800bdf0c - location of first WEP/EFF loaded section 1 + 2 (may be variable?)

0x800946c8 - Graphic size pairs (words, only loaded in pairs, height and width)

Frame Data Layout

each byte here is represented in bit-combined form, as that is how the data is constructed (0x7 for example means all 3 bits 0x1, 0x2, and 0x4 contribute to the information) 

0x00: 
	- 0x07 - No. graphics to load
	- 0xf8 - pointer to pre-existing Y rotation
0x01
	- 0x61 - VRAM flags for this frame (needs investigating, 0x40, 0x20)
		- 0x60 - transparency type (see P00 GetTpage)
		- 0x01 - transparent flag
	- 0x1e - ?
	- 0x80 - ?
0x02: x shift
0x03: y shift
0x04 - 0x05 (values are when loaded as a half word)
 	- 0x001f - load location of top-left corner in x tiles
 	- 0x03e0 - load location of top-left corner in y tiles
 	- 0x3c00 - reference to pre-existing x/y size (in tiles, see above)
 	- 0xc000 - reversal bytes
0x02 - 0x05 are repeated depending on how many graphics are loaded.
Retrieved from "https://ffhacktics.com/w/index.php?title=SHP_%26_Graphic_info_page&oldid=26805"