Difference between revisions of "SHP & Graphic info page"
MrGudenheim (talk | contribs) m (Added link to Update Sprite display data for details on how Swim Ptr is used) |
|||
| Line 6: | Line 6: | ||
00000000: B2 0E 00 00 54 00 FF 00 | 00000000: B2 0E 00 00 54 00 FF 00 | ||
these first few bytes dictate some information regarding loading graphic data: | 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. | + | *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 | *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. | *SP+ - this value is deprecated. theoretically it may have had a use if there was more space in the frame buffer. | ||
| Line 64: | Line 64: | ||
[[SEQ & Animation info page]] | [[SEQ & Animation info page]] | ||
| − | [[ | + | [[Unit Animations]] |
[[Weapon Animations]] | [[Weapon Animations]] | ||
| − | |||
| − | |||
[[Weapon Zero Frames]] | [[Weapon Zero Frames]] | ||
| Line 75: | Line 73: | ||
[[Item Graphics]] | [[Item Graphics]] | ||
| + | |||
| + | [[Load WEP/EFF graphics from WEP1/EFF Sheet]] | ||
| + | |||
| + | [[Update Sprite display data]] | ||
Revision as of 03:13, 29 December 2024
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.
Contents
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.)
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?)
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.
