Timinfo

General Information[edit]

Chrono Cross[edit]

timinfo files consist of a header, a series of pointers, and a series of records. The header is twelve bytes long and consists of two zero bytes, a one-byte record count, one byte of undeciphered byte and texture info(texture x, texture y, clut x, clut y, each 2 bytes). Some examples:

00 00 36 80 C0 02 00 00 00 00 C0 01 (0201.00.face.timinfo)
00 00 06 80 D0 02 6A 00 C0 02 78 00 (0199.06.smok.timinfo)
00 00 01 80 F1 03 EC 00 F0 01 FF 00 (1967.10.bt1.timinfo)

Notes: though this type is named timinfo, the values in the header are actually vram positions, since tim will be uploaded to vram.

The pointers which follow are two-byte little-endians, each indicating the beginning of a record relative to the beginning of the file. There is no end-of-file pointer.

The records consist of a four-byte header followed by one or more 12-byte subrecords. The form with only one subrecord is the most common, but 2, 4, and 5 subrecords have also been observed.

The four-byte record header consists of a subrecord count followed by 3 zero bytes. The subrecord then consists of four bytes that seem to have to do with mirroring or rotation, followed by the x and y coordinates of the upper-left corner of the slice of texture being referred to, followed by two bytes which are normally constant within the same file but differ between files, followed by the width and height of the texture slice, followed by another byte that is constant within the file, and then one final byte which again seems to have to do with mirroring or rotation. (In other words, this hasn't been completely deciphered yet.)

Some examples:

0201.000.face.timinfo corresponds to a texture containing what appear to be the PC portraits used in the character change menu, plus three other symbols at the very bottom. Each portrait is a 24 by 24 (0x18 by 0x18) pixel square. This gives the file a nice regular structure:

01 00 00 00 00 00 00 00 00 00 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 18 00 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 30 00 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 48 00 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 60 00 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 00 18 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 18 18 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 30 18 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 48 18 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 60 18 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 00 30 00 70 18 18 8B 18
01 00 00 00 00 00 00 00 17 30 00 70 18 18 8B 10 <--
...
01 00 00 00 0D 00 0C 00 3B F3 00 70 09 0A 8B 10
01 00 00 00 0D 00 0C 00 53 F3 00 70 09 0A 8B 10
01 00 00 00 0F 00 0D 00 6E F3 00 70 06 09 8B 18

The bolded sections are the record headers. It's easy to see the pattern in the columns denoting the upper left corners of the portraits, and the nice constant size columns. One anomaly which I can't adequately explain at this time is the arrow-marked record, which corresponds to Luccia's portrait. Its upper-left corner appears to be shifted one pixel to the left, and the last column is different.

The three records at the bottom pertain to the non-portraits at the bottom of the texture. These are smaller than the portraits themselves, hence the smaller height and width, and I've verified that the upper-left corners really are in approximately those positions. The apparent rotation/mirroring information is probably a dud, since the values of the first two bytes nearly match those of the second two bytes (more on this later).

1967.018.asi1.timinfo corresponds to a mostly-black 32x32px square with a sort of shallow grey curve along the right side. It's probably intended to be mirrored along the right edge to produce a grey oval shape (although what purpose said oval is supposed to serve in the game, I have no idea).

02 00 00 00
00 00 F0 FF 11 00 8F 3F 0F 1F 0F 02
F0 FF F0 FF 10 00 8F 3F 10 1F 0F 18

Notice the first four bytes and last byte of each subrecord. These have to be controlling whatever kind of mirroring or rotation is taking place somehow, but I'm still not quite sure how. My best guess is that the first subrecord is saying, "map this corner to this non-canonical location" with those first four bytes and then indicating a rotation or mirroring with the last one, but I can't figure out how those first four bytes correspond to what the location has to be... (The other interesting feature here is the fact that the two subrecords define slightly different areas: the first starts one pixel to the right of, and is one pixel narrower than, the second.)

1967.010.bt1.timinfo corresponds to a fuzzy white quarter-circle in the lower right corner of a 20x20px square. It's clearly meant to be duplicated and mirrored/rotated to produce a full circle.

04 00 00 00
EE FF 00 00 01 01 DF 3F 12 12 0F 04
00 00 00 00 01 01 DF 3F 12 12 0F 06
00 00 EE FF 01 01 DF 3F 12 12 0F 02
EE FF EE FF 01 01 DF 3F 12 12 0F 10

The four subrecords should be sufficient to build up our circle. Once again, we have what looks like some kind of corner cross-mapping (in particular, the subrecord ending in 02 starts with the same 00 00 aa bb pattern as the subrecord with the same ending in 1967.18.asi1.timinfo, suggesting that this might correspond to the upper-right quadrant). A pixel is being clipped from all four edges of the image, presumably to deal with the 1px black border.

From: Modification