CC Weapon Pack Structure

[FaustWolf]

M, are the image width/height identifiers in the wrong order in this encyclopedia entry on .TIMs?
http://www.chronocompendium.com/Term/TIM_Textures.html

Palette in a Classic .TIM always starts at offset 0x14 starting from the beginning of the Classic .TIM header in my experience. If these are different, we may have another image type on our hands or something. Whatever it is, it's detectable by PSicture I believe.

[Satoh]

It would seem that the shorter sections do contain the the models, at least I was able to identify what looked like a UV coordinate sturcture in it. I didn't get too far into it, but assumedly, the next part of the short-block is the vert pool.

Though from what we've seen thusfar, CC doesn't always stick to filetype standards....

[MDenham]

M, are the image width/height identifiers in the wrong order in this encyclopedia entry on .TIMs?
http://www.chronocompendium.com/Term/TIM_Textures.html

Well, based on what I'm seeing here, it's just IY and IW that need switched, apparently.

Would this have also caused the issues with the textures for battle models?

[Satoh]

The bold text below is a small portion o what I believe to be the UV data.
Does anyone else agree? I tried to map it be hand, but quickly lost track
having to keep switching windows...

01 00 00 80 48 00 5E 00-E0 0B 00 00 28 00 00 00
14 00 00 00 02 00 00 00-34 00 30 00 28 00 00 00
3C 00 2E 00 68 05 00 00-81 80 80 34 81 80 80 00
81 80 80 00 3D 07 C0 3F-52 17 16 00 3D 1B 2B 00
2A 00 2C 00 81 80 80 34-81 80 80 00 81 80 80 00
3D 07 C0 3F 52 0A 16 00-52 17 2C 00 2A 00 2D 00
76 74 7E 34 81 80 80 00-81 80 80 00 10 18 C0 3F
01 19 16 00 0E 1F 2F 00-2E 00 30 00 69 6C 88 34
69 6C 88 00 4B 53 6C 00-1E 46 C0 3F 2E 46 16 00
2B 41 38 00 37 00 39 00-81 80 80 34 81 80 80 00
6F 6C 75 00 47 2B C0 3F-50 26 16 00 52 17 35 00
3C 00 3D 00 69 6C 88 34-4B 53 6C 00 46 43 59 00

[MDenham]

It doesn't look like it's UV data to me - too many numbers that aren't multiples of 8 in positions where they'd need to be a multiple of 8.

[Satoh]

01 00 00 80 48 00 5E 00-E0 0B 00 00 28 00 00 00
14 00 00 00 02 00 00 00-34 00 30 00 28 00 00 00
3C 00 2E 00 68 05 00 00-81 80 80 34 81 80 80 00
81 80 80 00 3D 07 C0 3F-52 17 16 00 3D 1B 2B 00
2A 00 2C 00 81 80 80 34

Well this certainly seems to be a header of some kind, how do I interperet the bold part... what is ther 4th byte for?

The original file isn't even close 800001 long...

EDIT: Bah I suck at reading files....

[FaustWolf]

Normally UV data will have a pattern like the following:

## ## ## ## ## ## #0 ## - #0 ## 0# ## for triangles, in which the 0s could also be 8s. In this case six bytes for the UV coordinates that could be any value within the texture bounds, followed by an additional three byte pairs that are indices identifying the vertices to which the texture piece is assigned. The quads would have an extra two bytes (one for the additional U, one for the additional V) as well as an extra byte pair for the vertex index. The 0s and 8s are what to watch out for. If you've got three byte pairs that end in 0 or 8 in a row, you've likely got UV data.

HOWEVER! It appears that weapons use two textures if I'm correctly recalling what Satoh wrote. M, something very evil happens with the UV data when double textures are used. Let's say we've got a triangle texture piece encompassing coordinates (10,10; 20,20; and 30,30). We would expect to see something like this:

0A 0A 14 14 1E 1E C0 FF - A0 00 B8 01.

But what we actually see is this:

0A 0A 14 14 1E 1E C1 FF - A1 00 B8 01.

See how there's a "1" instead of a "0" in some cases for the vertex pointers? I'm not sure if the last nybble is used as a texture page or not, with an odd number simply telling the game engine to use the second texture. I haven't seen a case in which, for example, the B8 01 above would turn into a B9 01. I've been sidetracked for the longest time collecting all the Battle Models into one place, but after that I'm going to test the UV map and see if this might be some way of specifying texture pages.

A really neat trick I learned for mapping UV coordinates is to paste the data into Microsoft Excel, do text > columns if you have that option and get the bytes into proper order, then go over a few columns and do a HEX2DEC() function on the cells filled with hex values. HEX2DEC and DEC2HEX have saved me copious amounts of frustration, but I think one has to enable those functions manually via the data analysis tool package or something.

The classic .TIM flub in the wiki shouldn't have any effect on the model textures because I've been giving those to everyone in either .BMP or .PNG format. That saves Luminaire the trouble of having to address the .TIM format as well as the model format. However, thanks to your discovery, I may have an easier time viewing weird textures in TileMolester.

EDIT: Satoh, which weapon pack are you looking at and what's the offset at which the data you posted begins?

[MDenham]

HOWEVER! It appears that weapons use two textures if I'm correctly recalling what Satoh wrote. M, something very evil happens with the UV data when double textures are used. Let's say we've got a triangle texture piece encompassing coordinates (10,10; 20,20; and 30,30). We would expect to see something like this:

0A 0A 14 14 1E 1E C0 FF - A0 00 B8 01.

But what we actually see is this:

0A 0A 14 14 1E 1E C1 FF - A1 00 B8 01.

See how there's a "1" instead of a "0" in some cases for the vertex pointers? I'm not sure if the last nybble is used as a texture page or not, with an odd number simply telling the game engine to use the second texture. I haven't seen a case in which, for example, the B8 01 above would turn into a B9 01. I've been sidetracked for the longest time collecting all the Battle Models into one place, but after that I'm going to test the UV map and see if this might be some way of specifying texture pages.

Well, this would explain why it seems like the headers are wrong - there's not one, or two, textures here, but four.

Still, something seems a little fishy with the repeated 81 80 80 34 81 80 80 00 81 80 80 00 sequences (I see two of them just in the block above, along with one that starts 76 74 7E instead of 81 80 80).  I'm pretty sure that whatever this part is, it's not UV data.  That comes later (probably just before the vertex data).

[Satoh]

that 81 80 80 00 is the repeating pattern I was refering to a few posts ago,

the offset is...

0x15C8 in 3057.out, Serge's weapon pack, and I miscounted in the first post, there are exactly

7 1580block's

and 7 short-blocks  0x15C8 is a short-block

nd there are 2 sections at the end which are 4 bytes each.

[FaustWolf]

Just took a quick peek at the weapon pack in PSicture, and you're definitely looking at a model file...or what should be a model. I'm just not sure of the format - looks a bit different than what we dealt with for character battle models.

Yaz0r wrote some findings regarding weapon models awhile back; you might find them useful along the way:

In Serge model mine file, I looked into the very last weapon model, and I noted the following:
data arround 22E10 is most probably the texture palette. The texture seems to be in 4bit mode, so that can be checked easily.

Next to that, there is 3 distinct blocks:
block 1: starts at 22E40, stride is 0x1C, num entries is 0x24
block 2: starts at 23230, stride is 0x24, num entries is 0x39
block 3: starts at 23A30, stride is 0x8, num entries is 0x4D

There is a few things we can make out if this.
block 1 and block 2 share similar design, but after a bit of inspection, block 1 is obviously the triangle table and block 2 the quad table.
Block 3 will be discussed later

A few block 1 entries:

7070 6034 8080 7D00 6060 6000 534D C03F 5147 1600 4E4A 4C00 3B00 3700
6060 6034 8080 7D00 7070 6000 4E4A C03F 5147 1600 534D 3800 4C00 3500
6060 6034 6060 6000 6060 6000 534D C03F 4A4D 1600 534D 3800 3B00 4C00
6060 6034 6060 6000 8080 8000 454F C03F 454F 1600 4C4F 4600 3B00 3800

A few block 2 entries:

6060 603C 6060 6000 A0A0 A000 8080 8000 583D C03F 513A 1600 5E3A 5635 3900 4A00 4700 4300
8080 803C 6060 6000 A0A0 A000 6060 6000 5635 C03F 513A 1600 5E3A 583D 4300 4A00 4700 3900
7C80 703C 7080 7000 9090 8800 8080 8000 341B C03F 461B 1600 3810 4913 2800 2B00 2600 2D00
8080 703C 8080 8000 6A70 5000 7080 7000 5614 C03F 4913 1600 501B 461B 2E00 2D00 2C00 2B00
7080 703C 8080 8000 6A70 5000 8080 7000 461B C03F 4913 1600 501B 5614 0C00 0B00 0900 0100

As said, the sequence are similar, with 3 vertices for block 1, and 4 for block 2 (hence the triangle vs quad).

The actual format is:
for each vertice {
    3bytes (usualy similar and most of the time alligned on 16)
    1byte
}
1 float (around 1.5f, is that scaling ?)
1 32bit value (is that an offset ?)
2 8bit values in case of block 1 and 4 8bit values for block 2
for each vertice {
    a 16 bit value
}

Additionaly, the last table of 16 bit data (one for each vertice) seems to range from 0 to the max number of entry in block 3.

Now what is block 3 ? But the vertex data off-course !
Block3 is just a table of 16bits X, Y, Z values padded with a blank 16bit of data.

I do not pretend all this to be completly accurate. Anyway, the point of all this is that when working on a file format, you should always start from the smallest dataset you have, and look at different models at the same times, as one model might give you clues that another would not...

Hopes this help.

Subtract 0x14800 from all offsets he gave there, because I gave him a large chunk straight from the ISO to begin with. Even then he may have been referring to the beginning of a hex row when the data actually start as of the eighth byte in a row. Plus, we weren't discussing .TIM format at all at the time yaz0r posted this, so references he made to texture palettes may be slightly off.


For palettes, you may know it by now but the first weapon palette begins at offset 0x5C, or dec 92 if I'm not mistaken. The header for these may have a texture-model-texture-model scheme, but I'm not taking into account the possibility of two textures per weapon -- your first move should probably be to identify which pointers are pointing at textures so you can establish a definite pattern. You can use TileMolester's Navigate > Goto function for this; model data will just look garbled, while textures are recognizable. The proper codec in PSicture appears to be 4pbb linear reverse. I wonder if the "reverse" has something to do with the order switch M was talking about earlier...

You're certainly right about Chrono Cross not always being entirely consistent in the file structure. The tech and summon textures are a nightmare, because they're arranged in a way that is very difficult to deal with, though it may just be the case that TileMolester is incapable of widening the image data as wide as the textures need to go or something. In any case, I'm suspending my investigation of the tech visual data for now and just recording what little info I've established, so that I may get back to the battle models, and then turn to this and help you finish detailing the weapon model format. Keep it up, it may seem like you're just muddling through, but you're doing a great job!

[Satoh]

ok I don't have the first clue about tech data, but a thought occurred to me, you said something about them being labeled elsewear in the files in a certain order and the techs you were looking at now are in a different order...

the logical order in my mind would be as such


Serge:1
Serge:2
Serge:3
Kid:1
Kid:1
Kid:1
Guile:1
Guile:2
Guile:3
Norris:1
Norris:2
Norris:3
<name>1
<name>2
<name>3
etc.

followed or led by the standard element data.

Is that not the order it's in?
(Note you should definitely start from the beginning since not every character has 3 techs, sprigg for instance has 2.)

unless the techs are also stored in packs like weapon data... (which would royally SUCK)

And the file structure is definitely tex model tex model until the two 4byte ambiguous data sections...

[FaustWolf]

To my uber frustration all week, the actual techs are not stored in the same order in which they are labeled in the game executable. AAARGH!

The ambiguous data might just be our weapon trails. It will take some experimentation to figure those out.

[Satoh]

I've been wondering, how exactly are you doing (to do, done) the in game tests?

Are you hexing the ISO itself and then just re-saving the file and running it in pSX?

[MDenham]

The ambiguous data might just be our weapon trails. It will take some experimentation to figure those out.

I can confirm that it has nothing to do with the color of the weapon trails - the last three are 20 77 77 77, 20 77 77 77, and 00 00 00 00.  (Kid's weapon pack is missing the last four bytes.)

As far as the rest of the model-data header, the two bytes that I wasn't sure about are a polygon count.

And Yaz0r's information there looks...  um, extremely wrong.   I've got a pretty good idea of how the entries are set up, though:

(CR CG CB CA) x 3-4
U1 V1 C0 3F U2 V2 16 00
U3 V3 [U4 V4 if needed]
(Vx) x 3-4

No ideas what the C0 3F and 16 00 are, but they seem to be consistent.  CR CG CB CA might be related to weapon trails (I'm a bit leery of saying it is, because while Guile's is a dark grey for the most part, Serge's and Kid's are both kind of a greyish color), but I'm thinking it's like the battle models' Section 1-4: unused lighting-color information.

[FaustWolf]

Excellent, thanks M!

Yeah Satoh, I keep a pristine CD image, insert changed files into it, and then save the whole thing as an "adulterated" game image. I'm told that I can simply make changes to savestates, which are much smaller, but I'm stubborn. Plus, while ePSXe savestates can be uncompressed very easily by changing them to a .rar extension and then extracting, and thereafter examined, I'm not sure what format pSX savestates are in. That's the emulator I prefer using.