SHP & Graphic info page

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. This section is 0x08 bytes long. In general, if the unit is submerged in 1 deep water their SHP data is moved by the swim pointer to their swim SHP data, if the unit is submerged in 2+ deep water their SHP data is forced to frame 0 of the swimming data. See Update Sprite display data for full details.
• Atk - first frame to load from the second half of a unit's spritesheet
• SP+ - this value is deprecated. theoretically it may have had a use if there was more space in the frame buffer.

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

         |Zero       |Fists|Knife|NjSwd|Sword|...
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). For WEP/EFF this section is 0x44 bytes long.

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.) For SHP types with swim/submerged data, a second Section 2 exists starting at Swim Ptr location.

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.) For SHP types with swim/submerged data, there is a second Section 3 following the swim/submerged Section 2.

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?)

0x80094508 - Y rotation as indexed by byte 0

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.

Related Pages

Unit Animation Index

SEQ & Animation info page

Unit Animations

Weapon Animations

Weapon Zero Frames

Sprite Y Rotation Table

Item Graphics

Load WEP/EFF graphics from WEP1/EFF Sheet

Update Sprite display data