Difference between revisions of "SHP & Graphic info page"
Jump to navigation
Jump to search
m |
|||
| Line 1: | Line 1: | ||
| − | + | SEQ (Sequence) 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. |SPR2 |SPR+ | | ||
| + | 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. | ||
| + | *SPR2 - first frame to load from SPR2 instead of SPR1 | ||
| + | *SPR+ - first frame to load from SPR3 (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: | 0x00: | ||
- 0x07 - No. graphics to load | - 0x07 - No. graphics to load | ||
- 0xf8 - pointer to pre-existing Y rotation | - 0xf8 - pointer to pre-existing Y rotation | ||
0x01 | 0x01 | ||
| − | - | + | - 0x61 - VRAM flags for this frame (needs investigating, 0x40, 0x20) |
| − | - | + | - 0x01 - only checked if not loading from SPR2 or greater? |
| + | - 0x1e - ? | ||
- 0x80 - ? | - 0x80 - ? | ||
0x02: x shift | 0x02: x shift | ||
| Line 39: | Line 50: | ||
- 0x001f - load location of top-left corner in x tiles | - 0x001f - load location of top-left corner in x tiles | ||
- 0x03e0 - load location of top-left corner in y tiles | - 0x03e0 - load location of top-left corner in y tiles | ||
| − | - | + | - 0x3c00 - reference to pre-existing x/y size (in tiles, see above) |
| − | - 0xc000 - | + | - 0xc000 - VRAM Flags? (0x8000 (right shifted to 0x4) can also be set if loading from SPR2 or greater, or from either EVTCHR) |
0x02 - 0x05 are repeated depending on how many graphics are loaded. | 0x02 - 0x05 are repeated depending on how many graphics are loaded. | ||
Revision as of 02:07, 10 November 2022
SEQ (Sequence) 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. |SPR2 |SPR+ | 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.
- SPR2 - first frame to load from SPR2 instead of SPR1
- SPR+ - first frame to load from SPR3 (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) - 0x01 - only checked if not loading from SPR2 or greater? - 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 - VRAM Flags? (0x8000 (right shifted to 0x4) can also be set if loading from SPR2 or greater, or from either EVTCHR) 0x02 - 0x05 are repeated depending on how many graphics are loaded.
