CHRONO CROSS FILE EXPLORATION THREAD

[torin]

wow, well done, i didn't know that there was job on chrono cross. Well, sorry for my bad english xD, this is a surprise to me, becouse i was working on chrono cross spanish translation (never finished by the way) a long long time ago. Maybe i can bring a little help for u guys; I'm programming a windows interface tool to dump the cd's, and a tool for translation.

congratulations again xD

[FaustWolf]

Welcome torin! A Windows interface dumper would be extremely handy. Have you seen Terminus Traductions' source for their CD dumper? It works with the first game CD, but not the second as far as I know, so having a dumper for both CDs would be really awesome.

Did the Spanish translation stall because you needed more people to help with the translation from English to Spanish itself? The Compendium probably has a fair amount of fans with Spanish skills, and I'm looking for exercises to keep up my own Spanish speaking / reading / translating skills. Let us know if you need help.

[torin]

yeah, i've stopped the translation becouse i was alone and my time to work with the project was too short ( university). Anyway, i'll be very happy for anyone help. The cctools from terminus translations work with both cd, they released two cctools into one rar file, one for cd and the other for cd 2. The other tool that i'm traing to program, is a translation tool, to view by blocks the script

[FaustWolf]

Torin, how much of the script have you translated already? I wouldn't mind translating, say, one dialogue box's worth every evening, and we've got the script dump courtesy of ZeaLitY and Terminus Traductions (not sure if it's in game CD order). Eventually we could get it busted out. If you're up for continuing the translation project, you could start a new thread in Kajar Labs sometime.

Creo que yo tenga bastante habilidad con la lengua para ayudarte. Y mas importante, un buen diccionario. 

[Luminaire85]

I have solved the issue with the textures around Serge's waist. Turns out that Blender decided the order the model file has the faces in wasn't good enough, and changed a few around without warning. I have adjusted my plugin to correct for this.

Now to fix the texture at Serge's wrists. A question in that regard: are all of the battle model texture files 128 x 252?

Pictures later tonight may be good enough for front-page update.

[ZeaLitY]

Yep, all 128x252.

[FaustWolf]

SIIII! Er - YEAAAH!

Yeah, ZeaLitY's correct. All the playable characters seem to have 128 x 252 textures for the battle models -- overworld models are 128x128 though. At least some of the enemies have 128x252 textures, though Garai might have a really huge texture if I'm not mistaken (that's for his regular TIM texture viewable in PSicture/TIMViewer; not sure what his battle texture is like).

Here's an example of what happens when a character's battle texture doesn't need the full 128 x 256 texture space. Hopefully this sort of situation won't generate the need for any extra work on your part Luminaire:

[attachment deleted by admin]

[Luminaire85]

A certain silent protagonist would like to say "...".

I am 98% sure that that's what he's supposed to look like. I had to play around with the UV coordinates in order to get rid of a few minor texture artifacts, and the solution for the wayward vertex is temporary at best, but nonetheless, we have successfully extracted Serge's battle model.

[attachment deleted by admin]

[ZeaLitY]

Yikes, I accidentally overwrote the scan of Serge's battle model from Ultimania while uploading this new image in the encyclopedia. But that's okay, because I've pretty much overwritten a crude facsimile with the REAL THING IN LOSSLESS IMAGE FORMAT!

Hah!

[FaustWolf]

*does the happy dance*

Serge looks perfect. This goes on the front page first thing tomorrow morning!

[halkun]

I would like to amke some observations.

First I think you have the leg rotations mis-calculated. They should not be pitched forward. The feet should be planted firmly on the ground. I think this is the same error that is causing Kid's model to be messed up. (Are you missing a bone?)

Second of all, looking at your alterations, what you have is the "rest" pose that all animations are based off of. Now a little thing about the animation format...

Most likely the animation is stored in a "delta" format. This means that bone rotations are not explicitly stored for every frame of animation for every joint. What are actually stored are only the changes from the reference pose (delta), and then only the changes from the last frame to the current frame for each frame of animation.

Inf FF7, the first frame of animation was the reference frame, and then then each animation frame deltas off of that. In CC here, it would seem that the reference pose is all by itself, and then all animations will delta from that.

Information on FF7's delta animation format is duplicated here for reference

   Notes for rotational delta compression scheme
   =============================================

   The delta values are stored in compressed form in a bit stream. Consecutive
   values share no bit correlation or encoding dependencies, rather they are
   encoded separately using a scheme designed to optimize small-scale rotations.

   Rotations are traditionally given in normalized PSX 4.12 fixed-point compatible
   values, where a full rotation is the integer value 4096. Values above 4095 simply
   map down into the [0,4095] range, as expected from rotational arithmetics. When
   encoded, only the required 12 bits of precision are ever considered.

   In some animations, the author can choose to forcibly lower the precision of
   rotational delta values below 12 bits. Though these animations are naturally not
   as precise, they encode far more efficiently, both because of the smaller size of
   'raw' values, and also because of the increased relative span of the 'close-range'
   encodings available for small deltas. The smallest 128 [-64,63] sizes of deltas
   can be stored in compressed form instead of as raw values. This method is
   efficient
   since a majority of the rotational deltas involved in skeletal character animation
   will be small, and thus doubly effective if used with reduced precision. Precision
   can be reduced by either 2 or 4 bits (down to 10 or 8 bits).

   The encoding scheme is capable of encoding any 12-bit value as follows:

   First, a single bit tells us if the delta is non-zero. If this bit is zero, there
   is no delta value (0) and the decoding is done. Otherwise, a 3 bit integer
   follows, detailing how the delta value is encoded. This has 8 different meanings,
   as follows:

   Type   Meaning
   ------ -------------------------------------------------------
   0      The delta is the smallest possible decrement (under the
      current precision)
   1-6    The delta is encoded using this many bytes
   7      The delta is stored in raw form (in the current precision)

   The encoding of small deltas works as follows: The encoded delta can be stored
   using 1-6 bits, giving us a total of 2+4+8+16+32+64 = 126 possible different
   values, which during this explanation will be explained as simple integers (the
   lowest bits of the delta, in current precision). The values 0 (no change) and -1
   (minimal decrement) are already covered, leaving the other 126 values to neatly
   fill out the entire 7 bit range. We do this by encoding each value like follows:

   - The magnitude of the delta is defined as the value of its most significant
     value bit (in two's complement, so the highest bit not equal to the sign bit).
     For example, the values '1' and '-2' have magnitude 1, while the value '30' will
     have a magnitude of 32. For simplicity, we also define the 'signed magnitude' as
     the magnitude multiplied by the sign of the value (so '-2' has a signed
      magnitude of -1).
   - When encoding a value, we subtract its signed magnitude; essentially pushing
     everything down one notch towards zero, setting the most significant value bit
     to equal the sign bit and thus ensuring that none of the transformed values
     require more than six bits to accurately represent in two's complement.
   - The transformed value is then stored starting from its magnitude bit (normally,
     you would have to start one bit higher to include the sign bit and prevent
      signed integer overflow). Small values will be stored using fewer bits, while
      larger values use more bits. The two smallest values, 0 and -1, are not
      encodeable but are instead handled using the previously mentioned scheme.

   When decoding, you only need to know the number of bits of the encoded value, use
   the value of its most significant bit (not the most significant value bit!) as
   the magnitude, multiply it by the sign of the encoded value to get the signed
   magnitude, and then add that to the encoded value to get the actual delta value.

   Some examples of encodings:

   Delta value *      Encoded            *) in current precision, as integer
   ------------------ ------------------
    0                 0
   -1                 1 000
   -5                 1 011 111
   15                 1 100 0111
   128                1 111 xxxx10000000  (length depends on precision)


   (Note: The reduced precision is treated as rounding towards negative infinity)

More information can be found here...

http://wiki.qhimm.com/FF7/Battle/Battle_Animation_%28PC%29

[FaustWolf]

Whoah, animation. Might as well tackle it if we can. I've some questions for you halkun:

1.) If I hit a delta frame and changed its hex values, would that affect all delta frames thereafter, making for easy observation during experiments? I could at least use this to detect the presence of animation data.

2.) Also, would it theoretically be possible to get a rough estimate of the number of frames in an animation by recording how long an animation lasts and multiplying that by the frames-per-second the game is running on? Like, if an attack took 2 seconds to complete and the game runs at 30FPS, there would be 60 frames for that attack animation?

3.) I imagine that there will not be a set length in bytes for each frame while the data is compressed, but after it's uncompressed should there be, say, two bytes each devoted to X, Y, and Z rotations?

Ha, I've been remiss in wiki scribing. Luminaire, how did the rotational data in Section 2 work out for you? Is there some way to determine consistently which order the X, Y, and Z rotations are stored?

If Luminaire gets Kid's model working, I need to take a look at the structure of Guile's model, which is different from either of the first two, and get the nature of that structural discrepancy settled before moving on to animation experiments.

[halkun]

The problem is that the delta data is a variable-length bitwise data stream. If you change data in the stream, you corrupt all the data after the point. It's kind of a pain

[MDenham]

Well, after a little bit of staring cross-eyed at Section 3, I can determine...  absolutely nothing.   Aside from that it doesn't have a header at all.

Section 4 seems somewhat promising, however.  It starts off with a header - 0x16 entries (so 22), and pointers for each of them into Section 4.

However, it's a little interesting as far as what happens between the header and where the first entry is...

Code: [Select]

01 00 00 00  00 00 00 00  00 00 00 00  10 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00
Awful lot of blank space in that particular spot for them to be worrying too much about whether or not the animation data is compressed, I'd say - however, I could be wrong (it's happened before).

Animations are in the following format:

* Frame count (4 bytes)
* Unknown (8 bytes)
* Frame pointers (4 bytes each)
* Frames (variable length - first frame is longer than all others, but all others are generally of the same length; the first three animations use 96, 114, and 102-byte frames.  THE FIRST FRAME SEEMS TO CONSISTENTLY BE 276 BYTES.)

The fact that frames are landing at a multiple of 6 bytes does nothing to help my suspicion that rotation data isn't compressed.

[FaustWolf]

Oh my goodness, if the animation data wasn't compressed that would be, like, so awesome. Great work M! I'm not even sure how I'd go about testing this, but at least I'll have a pretty good idea as to what I'm looking at once I get to it.

Grr, I'm short on time and I'm going to be attending a conference for the week with little or no Internet access. Just to make sure that interested parties have Guile's battle model in the meantime, it's attached to this post. If you look at the file structure wiki you'll see that Guile has an extra section specified in his model header; I'm not sure if this will be a problem. Guile's texture is inside the zip in .bmp format -- I think that's the type Luminaire's been using. If not, let me know and maybe I can excise the native format version before I head out tomorrow.

[attachment deleted by admin]