Author Topic: CHRONO CROSS FILE EXPLORATION THREAD  (Read 64729 times)

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #345 on: January 11, 2008, 07:30:14 pm »
Wow, you're quire experienced! I typically make changes to a file taken from the game image, paste that altered file back into a test game image, and see what the results are when I fire up my emulator. That's no doubt the most inefficient hacking method ever, but it's what I'm personally comfortable with, and I've honed it into as fine a science as I possibly can.

I'm not sure how similar Nights would be to Chrono Cross in model format, though there are no doubt similarities between all model formats I imagine. Can you tell if the model formats you've investigated are similar at all to what halkun described for Final Fantasy VII here?: http://wiki.qhimm.com/FF7/Kernel/Low_level_libraries#Model_formats_for_PSX

All the info we've confirmed so far regarding the Chrono Cross models (with the exception of the quad and triangle pointer schemes) can be found at the Chrono Cross File wiki: http://www.chronocompendium.com/Term/Chrono_Cross_File_Structure.html#Character_Battle_Models

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #346 on: January 14, 2008, 01:00:27 pm »
Cross, I have not forgotten thee!

I've finally finished my evaluation of the quad pointers, and the results are unfortunately confuzzling. Here's the data from Section 1-2 (the UV map) that I tested:


000026E0                          3B A5 3B AD 39 AF 3A B2
000026F0  10 20 F0 21 E8 10 00 11-3B B2 3B AD 3D AF 3B A5
00002700  10 22 C0 FF 50 11 C8 FF-63 FC 5D F6 67 FB 5D EB
00002710  B0 FF C0 FF C0 FF E0 FF-5D EB 5D F6 56 F9 56 FA
00002720  F0 FF C0 FF C0 FF A8 FF-34 EA 3A F1 37 F5 3E F1
00002730  40 22 60 22 40 11 48 11-3C F1 3E F1 56 F9 5A EF
00002740  F0 FF C0 FF C0 FF 38 11-51 F2 4F F0 36 F4 34 EA
00002750  E0 21 70 20 10 11 40 10-69 EC 7F E7 67 FB 7F F0
00002760  50 20 C0 FF 60 FF C8 FF-3E F1 3A E0 5A EF 51 E3
00002770  50 FF C0 22 A8 FF 58 11-32 E0 3B E0 34 EA 3A F1
00002780  D0 22 C0 FF 50 FF C8 FF-5A EF 51 E3 5D EB 5D E1
00002790  A0 FF A0 FF 10 FF 18 10-3A E0 3B DB 51 E3 51 D9
000027A0  90 FF 00 21 D8 FF C8 10-51 D9 5D DC 51 E3 5D E1
000027B0  F0 FF 10 21 E0 FF C0 FF-32 E0 33 DC 3B E0 3B DB
000027C0  00 FF F0 20 B0 FF B0 FF-69 E0 7F E0 69 EC 7F E7
000027D0  C0 20 A0 20 10 FF 10 FF-4F F0 44 DF 34 EA 30 E0
000027E0  F0 FF C0 FF 40 10 48 10-5D E1 69 E0 5D EB 69 EC
000027F0  30 FF 70 FF 40 FF B8 FF-6A D9 7F DA 69 E0 7F E0
00002800  60 21 E0 20 D8 FF B0 FF-5D E1 5D DC 69 E0 6A D9
00002810  80 FF 80 FE E0 FF C8 FF


Now here are the rules by which I tested:

QUADS...

Rule for Positive Pointers
*If you're in one of the first two columns, divide the byte pair value by 2. This value is the positive pointer into the vertex pool.
*If you're in one of the last two columns, the byte pair value is the positive pointer into the vertex pool.

Rule for Negative Pointers
*If you're in one of the first two columns, divide the byte pair value by 16. Go backward that number of positions into the non-UV data.
*If you're in one of the last two columns, divide the byte pair value by 8. Go backward that number of positions into the non-UV data.

The rules for negative pointers for quads work out just fine; in the data above, the negative pointer of a certain color leads to the positive pointer of the same color but underlined. The point on the UV map corresponding to each pointer of the same color are identical or maybe a pixel or two off, meaning that these points are mapped to the same vertex.

Now for the positive pointers. By the rules above, the first vertex (red) has a positive pointer of 0x22C0, which is divided by two to yield 0x1160 (which leads to address 0x3A48).

The second vertex (green) has a positive pointer of 0x2100, which is divided by two to yield 0x1080, and leads to address 0x3968.

The third vertex (purple) has a positive pointer of 0x1158, which is undivided and leads to address 0x3A40.

The fourth vertex (yellow) has a positive pointer of 0x10C8, which is undivided and leads to address 0x39B0.

Here's where the vertices should be on Serge, judging from the UV map:




And here's where the vertices actually are:





So something screwy is afoot. I should note that when I tested the quad rules previously, everything pointed into parts of 1-3 that were in "8-byte mode", whereas here each pointer points into "16-byte mode" parts.

EDIT: I should also note that there IS one pointer that points into "16-byte mode" while working as MDenham had theorized. It was one of the pointers in the non-UV data for Serge's belt, and it's highlighted in this post:
http://www.chronocompendium.com/Forums/index.php/topic,4770.msg85432.html#msg85432

It's at address 0x10D6 (pointer value 0x0968). Being in the third column, it is a straight pointer to address 0x3250 -- which happens to be the very beginning of "16-byte mode" in Section 1-3. The next pointer over, value 0x0990, didn't work for me back then as a straight pointer, but it points a bit further into Section 1-3. If we can get that last pointer to work in Serge's belt buckle through some adjustment, then we'll be well on our way to a really full understanding of the pointer scheme. I'll have to brood on this tonight over alcohol to figure it out...
« Last Edit: January 14, 2008, 01:33:45 pm by FaustWolf »

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #347 on: January 16, 2008, 12:57:54 am »
I find truth in the bliss of sleep. No, really -- an idea came to me as I hung in the altered state of consciousness between sleep and waking hours. I shall name it "vertex index theory."

Let's revisit Serge's belt buckle and the pointers associated with it on the UV map:


It is now my belief that the pointers all behave as M said, but that in addition, they do not report raw offsets -- they report vertex indices in the vertex pool. The red-boxed pointer, value 0x0968, when divided by 8 yields an index of 12D, or 2D 01. We have already confirmed that this vertex is where the bottom of Serge's belt buckle is applied. If you take the last pointer value for quad #1 and divide it by 8, you get an index of 132. For the first and second pointers you must divide by 2, but then you must divide by 8 on top of that to get indices 139 and 13E. Look what happens when the vertices labeled 32 01; 39 01; and 3E 01 are altered:



It would appear that the correct vertices are altered (there's a bit of clipping with Serge's shirt and arm in the lowest cap, but that's normal). This facet of the non-UV data's nature was imperceptible at first because my later examples stuck mainly to areas that pointed into Section 1-3's "8-byte mode" data. Raw offsets and vertex indices coincided, so everything seemed to check out fine. Since "16-byte mode" data progresses at half pace, things got out of whack, but with this interpretation the quads seem to check out.

So when we see "16-byte mode" data like this in Section 1-3:

YY ** ZZ ** XX ** 00 00 - YY ** ZZ ** XX ** 00 00
YY ** ZZ ** XX ** 01 00 - YY ** ZZ ** XX ** 01 00

...the underlined bytes we were wondering about earlier are in fact the indices of each vertex. If a first-column pointer were to point to the first vertex, its positive pointer would be 00 00; if it were pointing to the second, its positive pointer would be 10 00.

Does this sort of thing sound realistic? If so, we have the following for the quad pointer rules:


QUADS...

Rule for Positive Pointers (as interpreted in hexadecimal)
*If you're in one of the first two columns, divide the byte pair value by 0x2, then by 0x8. This value is the index for the vertex to which the UV point is mapped.
*If you're in one of the last two columns, divide the byte pair value by 0x8. This value is the index for the vertex to which the UV point is mapped.

Rule for Negative Pointers (as interpreted in decimal)
*If you're in one of the first two columns, divide the byte pair value by 16. Go backward that number of positions into the non-UV data.
*If you're in one of the last two columns, divide the byte pair value by 8. Go backward that number of positions into the non-UV data.

I'm not sure how the heck that would be written in pseudocode though. Luminaire, do you think your viewer could be adjusted to accomodate this altered interpretation of Section 1-2's non-UV data? In any case, I have to confirm the triangle pointers yet. We'll know for sure this is right if those also work best interpreted as vertex indices.
« Last Edit: January 16, 2008, 11:33:32 am by FaustWolf »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #348 on: January 16, 2008, 09:54:43 pm »
It is now my belief that the pointers all behave as M said, but that in addition, they do not report raw offsets -- they report vertex indices in the vertex pool.
I can't remember if I'd mentioned this idea once off-handedly or not (doesn't help that my computer died for the second time in two months, hence no work on anything useful, or even RPG-related, aside from beating Star Ocean 3 on Universe :lol:) but it sounds correct - and so what it boils down to is this (in a mishmash of C code and plain English):

(Notes: pd_uv[][] is the UV data array; pd_vptr[][] is the array of vertex "pointers"; pd_vertex[][] is the array of vertices to use for rendering; and vertex_pool[] is, well, the vertex pool after the step that converts all two-part vertices into a single value.)

* Load polygon data (2N bytes of UV positions, 2N bytes of vertex values) into pd_uv[cur_poly][0..N-1] and pd_vptr[cur_poly][0..N-1].
* If N = 3, divide pd_vptr[cur_poly][1] and pd_vptr[cur_poly][2] by 2.  Otherwise, divide pd_vptr[cur_poly][0] and pd_vptr[cur_poly][1] by 2.
* for(i=0; i<N; i++) {
* If pd_vptr[cur_poly] < 0: { pd_vptr[cur_poly] = **(pd_vptr + pd_vptr[cur_poly]); i--; continue; }
* pd_vertex[cur_poly] = vertex_pool[pd_vptr[cur_poly]];
* }

And yeah, it's amazing what ideas come to people when they're either just about to get to sleep or just about to wake up.  I lose more sleep from the former than from anything else. :D

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #349 on: January 16, 2008, 10:42:28 pm »
Welcome back, M! Sorry to hear about the computer problem. It seems to happen to everyone who dabbles in game hacking, so I'm wondering when the bell will toll for my Compaq Presario *knocks on wood.*

Thank goodness, we're making progress then. I'll have a finalized report on the triangle pointers tomorrow night hopefully. The scheme for the positive pointers for triangles seems to work like this:

TRIANGLES...

Rule for Positive Pointers (hex)
*If you're in the first column, divide the byte pair value by 0x8. This value is the vertex index.
*If you're in one of the last two columns, divide the byte pair value by 0x2, then by 0x8. This value is the positive pointer into the vertex pool.

Which corresponds to what you had earlier -- it's the last two positions that are half value. I believe the negative pointers also behave as expected, though something really weird's going on -- it seems that the first UV coordinate might get the second-position pointer, the second UV coordinate might get the third position pointer, and the third UV coordinate might get the first-position pointer. That's what I jotted down in my notes, anyway. I'm not sure why that sort of thing would occur, but I'll post my findings when I can get my mind dis-discombobulated. Until then, take a look at the twelve triangles that are contained within offsets 0x2658 through 0x26E7 and see what you think:


00002658  69 EC 67 FB 5D EB-08 10 50 20 D0 21
00002664  5A EF 5D EB 56 F9-50 11 70 22 D0 FF
00002670  51 D9 3B DB 4B D6-D8 10 90 21 00 21
0000267C  3B DB 33 DC 37 D7-E0 10 D0 FF F0 20
00002688  33 DC 33 D7 37 D7-E0 FF D0 FF A0 21
00002694  3B DB 37 D7 3C D7-A0 FF 80 FF D0 FF
000026A0  6A D9 6E D6 7F DA-70 10 60 21 20 21
000026AC  47 DC 36 D5 32 DA-68 10 E0 FF 30 21
000026B8  32 DA 36 D5 33 D7-A0 10 E0 FF C0 FF
000026C4  47 DC 3A D5 36 D5-D8 FF 80 FF 40 FF
000026D0  30 DB 24 D7 2A D7-38 FF 80 FE 80 21
000026DC  31 DA 2B D6 25 D6-B8 10 40 FF 50 FF


The first six bytes in each row are the UV map coordinates; the last six bytes are the positive and negative pointers.

Looking at the first two triangles (0x2658 ~ 0x266F), for example, I ran an experiment showing that these triangles share one vertex. It would make the most sense if that shared vertex had the same UV coordinate -- 5D EB -- in both triangles. The other possibilities (69 EC and 67 FB) are too far away from triangle #2's UV coordinates for the mapped vertices to be plausible shared points IMO. I'll post visuals tomorrow night.
« Last Edit: January 16, 2008, 10:55:29 pm by FaustWolf »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #350 on: January 16, 2008, 11:04:33 pm »
Welcome back, M! Sorry to hear about the computer problem. It seems to happen to everyone who dabbles in game hacking, so I'm wondering when the bell will toll for my Compaq Presario *knocks on wood.*
Yeah...  according to what I'm seeing as far as the mobo manual online, supposedly the memory isn't working right.

I don't believe it. :D  I'm going to try rearranging the memory when I get home (currently up the hill at the local community college) and see if I can get the stupid thing to boot up.  If not, I'm computer-less for at least another 2-4 weeks so I can save up the money for new memory (as things stand, it looks like I'm probably looking at ~$60 if I'm only getting the system back up to 1GB of memory [it's currently got 1.25 - 2x512MB and 1x256MB]...  but who knows, I may try and push the system up further as an early [or late - 2/2] birthday present. :D).

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #351 on: January 16, 2008, 11:56:38 pm »
Jeez, good luck with that. If I have to carry on without your genius for another week or two, just be sure to send me some brainwaves -- must've been what happened the other day.  :P  Hopefully we'll get through this triangle weirdness and find the bone data by the time your computer's back in shape.

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #352 on: January 17, 2008, 01:28:41 am »
Jeez, good luck with that. If I have to carry on without your genius for another week or two, just be sure to send me some brainwaves -- must've been what happened the other day.  :P  Hopefully we'll get through this triangle weirdness and find the bone data by the time your computer's back in shape.
Did we find the bone data yet? :D

Computer's back up and running - the oldest one of the three memory sticks (the 256MB one, thank God) is thoroughly flaked out so I'm down to just (:D) 1GB of memory.  I'm thinking that I will be spending $60 on the damn computer anyway just to double it up.

Anyway...  LET THE GAMES CONTINUE!

Cyberman

  • Architect of Kajar
  • Earthbound (+15)
  • *
  • Posts: 44
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #353 on: January 17, 2008, 07:48:33 am »
I suspect the model is still boneless there.
:D

Oh yes I'm still watching the thread, not much to add currently.

Cyb

halkun

  • Architect of Kajar
  • Earthbound (+15)
  • *
  • Posts: 50
  • Ayumi Hamasaki Fanboy
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #354 on: January 17, 2008, 08:51:39 am »
I'm still watching too. I'll pipe up when I see anything I can offer.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #355 on: January 17, 2008, 01:11:45 pm »
YEAH! All we need is Luminaire, and the team will be fully assembled!! :lee: Yeah, I haven't even tried investigating bone data in depth yet; I've gotta review and digest halkun's notes on that once we get the UV triangles nailed down. I'll write up a report on the triangles tonight.

UPDATE: The triangles are still bothersome, but I'll report my findings so far. First, the really good news -- it seems the UV triangles are consistent wth M's description of them as far as which columns have positive pointers that must be divided by two and which are "straight" positive pointers, though they all need to be divided by 8 on top of that to yield vertex indices. I conducted some experiments with the UV triangle beginning at address 0x2658, and it would seem the rules for positive pointers lead to the correct vertices in the vertex pool.

The UV and non-UV data for this triangle are as follows:

00002658  69 EC 67 FB 5D EB-08 10 50 20 D0 21
And here's where that exists on the UV map:

Coordinate #1 is 0x(69, EC); #2 is 0x(67, FB); #3 is 0x(5D, EB).

The non-UV value 1008, divided by 0x8 due to its first-column position, yields vertex 0x201. The next slot over, value 0x2050, is divided by 0x2 because it's in the second column, then by 0x8 to yield vertex 0x205. Rinse and repeat for the third non-UV slot, value 0x21D0, to get vertex 0x21D. Here's what happens when each of those vertices is altered:




Now notice something really interesting. It's quite clear that coordinate #1 is mapped to vertex 205! So the first UV coordinate for a triangle apparently gets the second pointer!

This odd swap principle can be further illustrated. Take a look at the following code for the first triangle followed by another triangle in this section of UV & pointer data:


00002658  69 EC 67 FB 5D EB-08 10 50 20 D0 21
00002664  5A EF 5D EB 56 F9-50 11 70 22 D0 FF


There is one negative pointer in the second triangle beginning @ address 0x2664. To make sure it points somewhere back into the first triangle's non-UV pointers, let's see if the triangles are connected by blacking them out:


It's not 100% conclusive (clipping issues may make it appear as if the triangles are separated by a pixel or so), but highly suggestive that the triangles are connected at the third coordinate, or 0x(5D, EB). But how can we use the negative pointer such that the 0x(5D, EB) in the second triangle is mapped to the same vertex as the 0x(5D, EB) in the first triangle?

According to my notes, it would appear that the second UV coordinate gets the third pointer. The value of the negative pointer is 0xFFD0, which leads 3 spaces back in the non-UV data when converted to decimal and divided by 16. That would lead three spaces back in the non-UV data, and we would land at the last pointer of the first triangle. Problem with that is, my notes tell me that the third UV coordinate might get the first pointer; the last goes to the second UV coordinate.

I'll have to spend more time theorizing on this weirdness later. At least we can conclude with some certainty based on actual visual evidence that the first UV coordinate gets the second pointer for triangle data. Anyone know why the heck that would be the case? For the quads, I always believed that the first UV coordinate got the first pointer, the second the second, etc, in logical order. This is very illogical at first glance.

EDIT: Looking at the positive pointer experiments for that first triangle, it does seem that the second UV coordinate is mapped to the third vertex pointer and the third is mapped to the first. I'll have to see if the scheme works out consistently via another thought experiment.
« Last Edit: January 18, 2008, 04:14:50 pm by FaustWolf »

MDenham

  • CC:DBT Dream Team
  • Chronopolitan (+300)
  • *
  • Posts: 330
  • Glowsticks are not a weapon.
    • View Profile
    • Java IRC - konata.echoes-online.com
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #356 on: January 18, 2008, 07:07:05 pm »
I'll have to spend more time theorizing on this weirdness later. At least we can conclude with some certainty based on actual visual evidence that the first UV coordinate gets the second pointer for triangle data. Anyone know why the heck that would be the case? For the quads, I always believed that the first UV coordinate got the first pointer, the second the second, etc, in logical order. This is very illogical at first glance.
Obviously we now have to test this for quads to see if they are ordered "correctly" or not.

BTW, negative pointers may not be resolved until after the vertices have all been processed otherwise - in which case the routine that's reading the vertex pointers for triangles is reordering them prior to associating them with UV values.  As things stand (and assuming that quads have their vertices ordered correctly), however, it means that the pointers associated with the first two UV coordinates are always divided by 2 initially, regardless of where they actually land in the data as stored.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #357 on: January 18, 2008, 07:32:22 pm »
Thanks M! Yes, I agree that regardless of where the last two negative pointers in any triangle fall after reordering, they are still divided by whatever amount their original location would suggest. There are several negative first-column pointers that are only divisible by 8 (and not 16) for example, so even if they're reordered during processing they have to be divided by 8 still. I guess the next thing I'll do is a thought experiment in which I reorder all the positive pointers according to the scheme I've arrived at, then figure out how the negative pointers can point to those.

Luminaire85

  • Guru of Time Emeritus
  • Chronopolitan (+300)
  • *
  • Posts: 311
    • View Profile
    • Chrono Cinema
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #358 on: January 18, 2008, 10:42:17 pm »
I too continue to lay in wait to a time where I can be useful.

Question, if I may: have you ever encountered a pointer data trajectory that crosses between triangle data and quad data? For example, say you started at a pointer in the 0x2658-0x26E7 triangle data. In the process of figuring out what that pointer actually should be, are you ever sent outside of the 0x2658-0x26E7 range? (I hope I'm still following well enough for that to make sense.)

The way I have the C++ program I used to make those images set up assumes that this never happens.

FaustWolf

  • Guru of Time Emeritus
  • Arbiter (+8000)
  • *
  • Posts: 8972
  • Fan Power Advocate
    • View Profile
Re: CHRONO CROSS FILE EXPLORATION THREAD
« Reply #359 on: January 18, 2008, 10:59:15 pm »
Thanks for the question Luminaire. I haven't seen anything like that yet, though I haven't checked all quad-triangle boundaries yet. From what I've seen on my part, it appears that the first quad/triangle after a boundary will start with all positive pointers, then succeeding polygons may have negative pointers that go back no further than that first polygon.