RAI PAY ATTENTION TO THIS TOPIC, YU Sprites Options

[jcdietz03]

External libraries is cheats

[Yourself]

It's an included library. Anyway...



I can rip all of the individual sprites of the animations for at least three files. I even got the right invisible background color now. I pretty much solved chunk 1.

The only thing left to do is to figure out chunk 0 table fields. There are two tables:
- Table 0 starts at 00C0.
- Table 1 is actually a bunch of smaller tables, indexed by the array at 0010-00C0.

Legend:
- 04.2 means offset 4 from start, 2 bytes.
- All values are ints. Usually signed ints.

A table 0 row represents a processed sprite, and looks like this (8 bytes):
+00.2: Index into the sprite array of chunk 1.
+02.2: X offset?? (Usually negative.)
+04.2: Y offset?? (Signed.)
+06.2: (Either 0000 or 0010?)

The variables probably indicate that something needs to be done to a raw sprite. That's why there are multiple rows using the same indexed sprite.


Each table 1 represents an animation, and looks like this (8 bytes):
+00.2: Pointer (from start of file) to a table 0 row, or 0 if end of current animation.
+02.2: (Always zero?)
+04.2: Number of sprites to grab from that pointer.
+06.2: Time?

The number of sprites to grab allows the overlay of multiple sprites in a single instance of the animation. For example, in Valkyrie (0731-0), this row in a table1 (during the Revolution animation):

CODE

F0 06 00 00 03 00 06 00

means to grab these (consecutive) rows in table 0:

CODE

000006F0    DC 00 BC FF 14 00 00 00
000006F8    96 00 BC FF 14 00 00 00
00000700    D0 00 BC FF 14 00 00 00

which correspond to instances of:
0. Valkyrie's after-image.
1. Valkyrie.
2. The lightning on the sword.
which are placed on top of each other in that order, so the shadow is on the back and the lightning is in front.

I believe that the last row of an animation table (i.e. the row that starts with 00 00) holds some metadata about the animation. Possibly determines looping/stopping.

It may even indicate which row to loop once you reach the end. For example, the 11 at the end might indicate that you jump to row 0x11 to loop.

CODE

58 04 00 00 01 00 06 00
60 04 00 00 01 00 0C 00
68 04 00 00 01 00 06 00
70 04 00 00 01 00 06 00
78 04 00 00 01 00 0C 00
80 04 00 00 01 00 0C 00
88 04 00 00 01 00 0C 00
90 04 00 00 01 00 0C 00
98 04 00 00 01 00 0C 00
A0 04 00 00 01 00 06 00
A8 04 00 00 01 00 0C 00
B0 04 00 00 01 00 0C 00
B8 04 00 00 01 00 0C 00
C0 04 00 00 01 00 06 00
C8 04 00 00 01 00 06 00
D0 04 00 00 02 00 06 00
E0 04 00 00 01 00 0C 00
E8 04 00 00 01 00 0C 00
F0 04 00 00 01 00 0C 00
F8 04 00 00 01 00 0C 00
00 00 00 00 00 00 11 00

[Carnivorous Sheep]

I consider this work pretty much complete.


There are three remaining issues:
1. Transparency. It is currently bothersome to get these Python image libraries to make animated GIFs with transparency.
2. Image x,y offsets. The offset interpretation of the data was correct, but the sprites can be offset beyond the bounds of the canvas. I can correct for this by detecting how far they're off-bound and offsetting the entire image, but you'd lose information about the original.
3. Palette swapping. There's no palette-swap info in these files.

These can all be taken care of in-bulk using an image processing program like ImageMagick.

The loop index interpretation seems to be right, but I know of no way to represent that in an image file.

[Buddhu]

Cool shit, thanks Rai
I haven't looked at these files in at least 30 years though so I don't know what's a valkyrie \_(ツ)_/

[San]

I doubled the size of the canvas (halfway in each direction) to fix the offset issue, since it turns out that you can't automate it based on the subsprite offsets. I used ImageMagick to fix transparency (SLOOOOW).

I put up a repo on GitHub.