CHRONO CROSS FILE EXPLORATION THREAD

[FaustWolf]

Thanks everyone! Halkun, as for why the battle screen v. the character menu screen for observation, the game actually uses separate models for the character menu, believe it or not! The models are roughly identical to the character battle models, understandably lacking animation data. In addition to the lack of animation, Serge's simplified model has data that isn't aligned in the same way as Serge's "real" model -- Serge's "real" model is actually easier to look at in a hex editor.

Now that you've given me more ideas for experiments, it's time to get cracking!

- - - - -

BOY, have I got interesting news!

It appears that both "slots" in "16-byte mode" data do the EXACT SAME THING!! Here's an illustration. It's big, so click. The pic on the left is offset 0x3258's right-left coordinate function in action, compared to 0x3250's on the right. Neat, huh? So both control the same vertex's coordinates:
http://img107.imageshack.us/img107/633/3258xfunctionleftad4.gif

But that ain't all, folks. It just so happens that when a vertex is in "16-byte mode", both "slots" interact to produce the vertex's location in 3D space!! Look at the next pic; the altered code shows what happens when both this vertex's X functions are assigned the same magnitude and direction -- the magnitudes build on each other, producing a coordinate that is way farther to the left than possible with one "slot" alone. The pic on the right is just a back view showing just how far out the vertex extends under these conditions.
http://img338.imageshack.us/img338/7362/doublexfunctionleftoi4.gif

Now I'm really excited. I guess this shows that the second "slot" isn't devoted to a normal, but at least we now know the purpose of "16-byte mode" in Section 1-3! So the data enters "16-byte mode" for vertices that, for some reason, need two interacting coordinate data "slots".

Any more ideas for experiments? We are totally kicking ass once again. I've tried and failed again to get Section 1-1 into testable state; even being very careful with a data transplant from Kid's Section 1-1 to Serge's, the game still cries bloody murder when it tries to load the character models in battle.

I still can't get the working pointer from address 0x10D4 to address 0x3250 out of my mind; I wonder if every vertex that's in 16-byte mode has such a working pointer, while the vertices that are in 8-byte mode are pointed to in a bizarre way, perhaps exactly what MDenham suggested earlier about a collection of bits and not the entire byte pair being used as the pointer for those. That's just a crazy hunch on my part though, but it's fairly easy to test -- I'll just go to the next set of "16-byte mode" slots, calculate the pointer that would be needed to point there relative from the beginning of Section 1-3, and see if such a pointer value actually exists in Section 1-2.

- - - - -

Breaking News from the FW laboratory: Another working pointer found. Update definitely tomorrow morning once a personal theory of mine is developed -- it isn't quite as simple as I supposed above, but we might be able to get a better understanding of what's going on, perhaps.

[FaustWolf]

Well, this isn't the breakthrough I was hoping for, because I can't make head or tail of what's going on with Section 1-2's non-UV pointer data just yet. But here's what may be three working pointers for everyone's perusal. Keep in mind that the data in Section 1-2 is stored as follows for quads:

                                    - U1 V1 U2 V2 U3 V3 U4 V4 
P1 P1 P2 P2 P3 P3 P4 P4

So here's a section of code from Section 1-2. Suspected pointers are highlighted in red boxes, and their corresponding UV map coordinates are boxed in blue.


The first red box almost certainly points to a certain vertex on Serge's belt buckle -- that's the very vertex I've been manipulating for all of today's experiments. The pointer's value (0x0968) behaves as a relative pointer (relative to 0x28E8) to address 0x3250, the start of the two 8-byte slots that control the vertex. The corresponding UV map coordinate is at the bottom of Serge's belt buckle, which corresponds perfectly with where we would expect the vertex to be.

Click on the pic below for proof of the second red box's possible pointer status:
http://img257.imageshack.us/img257/7045/pointerexample3260wo5.gif
Here's the interesting thing: we would expect the pointer value (0x0970) to point to address 0x3258. However, I believe it actually points to 0x3260 based on the visual evidence. I.e., the alteration of the 0x3260 / 0x3268 pair in Section 1-3 warped the circled vertex on the UV map; alteration of 0x3258 is the same as alteration of 0x3250 as proven in my earlier post. Therefore, I will call this a "questionable" pointer, since it doesn't point precisely where we would expect it.

Next is proof of the third red box's possible pointer status, this actually might not be a pointer, on second thought; the vertex affected doesn't seem to be in the right place on the quad map after all]:
http://img257.imageshack.us/img257/2441/pointerexample3270ay6.gif
The value in the third red box (0x0988) [might] behave as a relative pointer to address 0x3270, and alteration of the "slot" beginning at said address appears to warp the circled vertex on Serge's model [or not].

For awhile I thought the following pattern might hold:

Pointer value 0x968 points to 0x3250.
Pointer value 0x970 should point to 0x3258, but gets "bumped up" to 0x3260 because 0x3258 is already linked to 0x3250.
Pointer value 0x988 points to 0x3270.
Pointer value 0x990 should point to 0x3278, but gets "bumped up" to 0x3280 because 0x3278 is already linked to 0x3270.

...Except for the fact that the value 0x0990 just to the right of the first red box does not point to 0x3280. Nor does it even point to 0x3278; altering either of those "slots" in Section 1-3 affects vertices completely unrelated to the quad being mapped out in this case. So I think we can scrap this proposal.

So, I'm still confuzzled. I would recommend treating the first red box as a real pointer, and the second and third red boxes I'm a little iffy on for the above-stated reasons. Also, the pointer at address 0x10D4 (the first red box) only occurs once. The value at address 0x10E4 (an adjacent quad) corresponds to the very same coordinate on the UV map, so this should refer to the same vertex as the pointer at address 0x10D4. Is there any way the values 0x968 and 0xFFE0 could possibly point to address 0x3250 in Section 1-3?

I'll try out some more potential pointers in this data range tomorrow. If that yields nothing conclusive, I'll move on to Sections 2 and 3 (big sections, not subsections) to search for bone data. The data in Sections 1-2 and 1-3 must be related to the bone data somehow, so finding the bone data may help solve our difficulties.

Also, if anyone needs clarification on anything I've reported in this post, just ask. Things are getting really complex now. Though animation data will be worse, I'm sure.

[Sora]

Is there any way the values 0x968 and 0xFFE0 could possibly point to address 0x3250 in Section 1-3?

if they're both pointing to it, or pointing to another pointer that is pointing to it.
im not 110% but i think you can have pointers of pointers.

IE
0x986 -> 0x1337 -> 0x3250.

[FaustWolf]

Interesting. I'll keep that in mind then. Real quick Sora, what's the relationship between 0x986 and 0x1337 in your example? 0x986 seems to point directly to 0x3250 but there's always the possibility that it's going through an intermediary in some way, I suppose.

[Sora]

it reads: 0x986 points to 0x1337 (i made up this pointer, btw) which is a pointer on its own that is pointing to 0x3250.
i am not basing this on anything i've seen in the chrono files (i havent looked at em) just on my programming knowledge (and pointers were always a pain in the ass for me, <3 Java)

[FaustWolf]

Ah, okay. Thanks for clarifying.

So as I see it now, there's two possibiliities for the pointers. First is the intermediary pointer possibility as Sora described above (which could apply to pointers besides the first and third red-boxed pointers I listed above; I'm fairly confident those are straight pointers).

Secondly, as MDenham described, the non-UV data may be composed of pointers as well as other unknown info. Perhaps bone info, perhaps some other kind of orientation info for the polygons. This info would not be needed for the first red-boxed pointer a few posts above, and probably not for the third one either if I'm correct in assuming it is also a "working" pointer. But this info might be in the second red-boxed pointer, meaning we would have to "discount" the pointer by some value to get the true pointer. Here's a theoretical illustration of what that would mean:

First red-boxed pointer: 0x968 = [(Pointer, value 0x968) + (other, value 0x00)]
Second red-boxed pointer: 0x970 = [(Pointer, value ???) + (other, value ???)]
Third red-boxed pointer: 0x988 = [(Pointer, value 0x988) + (other, value 0x00)]

One way to test would be to try and find the vertex to which UV coordinate #4 on Serge's belt buckle maps (I don't have a pic up for that, so don't worry if it doesn't make sense -- coordinate #4 would be the UV coordinate corresponding to the non-UV value 0x990, just to the right of the first red-boxed pointer above).

- - - -

UPDATE: I think I may have just found three more working pointers from the non-UV data in Section 1-2 to the vertex pool. I'm getting some pics together to illustrate where the pointers are in terms of hex addresses and their impact on vertices specified by the UV coordinates.

Also, I should point out that I've noticed the 3D coordinates for the vertices specified in Section 1-3 are given in reference to the bone the vertex is on. For example, I changed the up-down magnitude and direction for a vertex on Serge's sock, and the vertex crawled up his leg diagonally, i.e., the vertex moved in accordance with the bone's angle. So the vertex indices given in Section 1-3 may refer to bone data in some way.

- - - -

Promised Update: Okay, here's an illustration of four working pointers (i.e., what appear to be pointers relative to address 0x28E8, the beginning of the vertex pool), which will hopefully give everyone a full idea of what I've been looking at today. Sorry, pics are big, so click to view.

First pic: three working pointers on Serge's shoe. Hex code insets show the code in Section 1-2 (top inset) and the code in Section 1-3 the pointers point to (bottom inset). Pointers are in red boxes as always. There are three polygons numbered in red here, and I've given the order in which each each coordinate in each polygon's UV map is listed. So the label "1-#2" is the first polygon's second UV map coordinate on Serge's texture. The circled coordinates apparently correspond to vertices in Section 1-3, i.e., altering the coordinate in Section 1-3 suggested by the vertex's non-UV byte pair makes this vertex on Serge's model shoot out somewhere.
http://img257.imageshack.us/img257/5940/shoepointersyb6.gif

Let's run through an example. The coordinate "1-#4" (0x59, 66 in hex) has a suggested pointer of hex value 0x0898 (fourth byte pair of polygon 1's non-UV data). This points to address 0x3180 in Section 1-3, and when this vertex is altered, sure enough the circled point on Serge's model does funky things. It should be noted that this vertex is in "8-byte mode".


Second pic: one working pointer on Serge's belt buckle; this is the one I used to determine the various purposes of the byte positions in the vertex pool.
http://img339.imageshack.us/img339/3926/bucklepointersor4.gif

The coordinate "1-#3" (0x5D, DC in hex) has a suggested pointer of hex value 0x0968 (third byte pair of polygon 1's non-UV data). This points to address 0x3250 in Section 1-3, and when this vertex is altered, sure enough the circled point on Serge's model does the funky things I've reported in previous posts. It should be noted that this vertex is in "16-byte mode." Thus, the data starting at address 0x3258 pertains to the same vertex as the data starting at 0x3250.


To tell everyone the truth, I've never seen more than one "working" pointer in each row of Section 1-2's non-UV data. This "working" pointer doesn't seem to have a definite position in the row though -- the shoe pic shows that the working pointers are all the fourth byte pair of non-UV data, but the belt buckle pic shows a working pointer as the third byte pair of non-UV data. The next step I'm going to take is to pick a random triangle and a random quad and see if each has at least one "working" pointer. It may tell us that only one pointer is necessary for each polygon, and the rest of the data can somehow be devoted to bones or other orientational aspects.

Whew! I'm going to take a day off and go collect 2D data (the EASY stuff) from another game. This will hopefully give everyone some time to digest the findings from page 18 onward in this thread. I'll check back though to clarify on things as necessary.

[FaustWolf]

Behold, the first working negative pointer! 

http://img140.imageshack.us/img140/2973/negpointerpm3.gif

The non-UV data value at 0x2870, 0xFF50, yields the value 0x4198 when it's added to 4248 (b/c FF50 is negative when interpreted as a signed integer -- right?). And voila, when the data spanning addresses 0x4198 ~ 41A8 (it's in "16-byte mode") is altered, it appears that the proper vertex on Serge's model is affected!

Now, this certainly doesn't end our problems, and may generate more questions than answers. Firstly, I still haven't determined whether there's more than one "working" pointer per quad/triangle mapped in Section 1-2. In this case, the value 0x1168 (last non-UV byte pair for the quad) does not appear to point to its corresponding vertex, and I have yet to check the other non-UV byte pairs. For one thing, the value 0x22E0 in the byte pair next to the working negative pointer is too large to point into Section 1-3. I wonder what's up there? Anyone have any ideas? I've tried out Sora's idea, but interpreted as a pointer to another value in Section 1-2, it points to a value that's FFD0. Many other polys in Section 1-2 have non-UV byte pairs that are FFD0, so I'm in doubt as to the possibility that all these polys could be pointing to the very same vertex. I'll investigate the FFD0 conundrum later.

Secondly, how does the GPU/GTE know when to add the pointers to offset 0x28E8 or to 0x4248? BTW, 0x28E8 is the beginning of Section 1-3, whereas 0x4248 marks the end.

Thirdly, I have to reproduce similar results with another negative pointer before we can be absolutely sure. But I figure if we can successfully trace a vertex in Section 1-3 back to Section 1-2 based on a supposed pointer value, that happenstance is unlikely to be a fluke.

Fourthly, even if I'm able to reproduce this sort of thing, I expect that not all negative byte pairs will point correctly, just as not all positive byte pairs point correctly. I still think there might be other info stuffed in some of these pointers as MDenham proposed earlier. Maybe I was incredibly lucky and chose to investigate a vertex pointed to by a value for which this "extra" info is essentially zero, making the byte pair value point correctly without having to be decomposed.

[FaustWolf]

Come one, come ye all! THIS is what you've been waiting to see! THIS is what you've come here for! Watch as some of Section 1-2's and 1-3's mysteries unfold before your eyes!

First, I give you the almighty "shoe." This texture will have to account for both sides of both of Serge's shoes. That means we might be able to account for any bone data within the pointers eventually (but not yet; I shall show you other important things for the time being). Below is Serge's shoe texture, with some quads mapped over the cuff:


What follows is some code in Section 1-2 that acts on this texture piece. The red numbers to the left of each pointer data row correspond to the numbers of the quads mapped out above. "A" and "B" I've singled out as particularly interesting, because they both have the exact same pointer data, yet different quad UV maps are applied to them.


Now for my first trick. I shall ask and answer the following question: "If I set quad A's pointers to 00 00, will that quad map to the vertex at address 0x28E8 in Section 1-3? The answer: A resounding YES!!
http://img402.imageshack.us/img402/2503/experiment1resultsjj8.gif

How can we tell? The left and center pics show the effect on Serge's sock cuff of zeroing out quad A's non-UV data. It may appear as if the quad and the quads it connects to have disappeared, but the center pic shows that the UV map has merely converged on a point just below the back of Serge's jacket, probably warping some connecting quads along the way. The right pic shows what happens when the data starting at address 0x28E8 is altered; the coordinate to which the zero'd texture piece maps changes!!


Now for the second trick. I shall ask and answer the question: "Seeing as several of these quads map the same texture piece in Section 1-2, do these act on the same foot (bone)? The answer: a resounding YES! BUT ON BOTH SIDES OF THE SAME FOOT!!
http://img440.imageshack.us/img440/6842/experiment2resultsor6.gif

When the UV map data for quads "A" through "B" are blacked out, Serge's entire sock cuff gets blacked out on one foot! The pics are just the same alteration at different angles to prove that this section of data applies to both sides of the same foot. In other words, notice from the shoe texture that quads "1"; "2"; "3"; "4"; "5"; and "B" map the same three quads twice; that's because each quad gets used on one side of this foot. It's very difficult to tell, but I believe Quad "A" maps to the outer side of the foot; it's counterpart, which remains unlisted in this post, would black out the inner side of the foot if I could locate it.

What have we learned from this post? Well, that the non-UV data, when set to 00 00 in all byte pairs, are made to point to the same address -- 0x28E8. If I can find the counterparts of these quads on the other foot, we can see if the pointers are "situational" in any way -- if the symmetrical pointer values all point to 0x28E8 when they're zero'd out, then we know that regardless of which bone the texture applies to, it will always point to 0x28E8 if its non-UV data is 00 00 for each byte pair.

In addition, we might be able to tell if some kind of orientational info is in the non-UV data along with pointers. Quads "2"; "3"; "4"; and "5" have identical pointer values except for the last byte pair. They're on the same bone (I think? Since they're on the same foot), but on different sides. It's possible that the first three byte pairs of any UV map's quad data refer to bone information I suppose (Cyb suggested this earlier). We'll have to account for triangles as well, and I'd like to point out that the working pointsrs in the data being examined (the fourth byte pairs of non-UV data for quads "1"; "2"; "3"; "4"; and "5") point into "8-byte mode" sections of Section 1-3. The fourth byte pairs of "A" and "B" are not working pointers -- negative or otherwise.

And, of course, whatever anyone else sees fit to add. I'm going to see which quads map to which side of this foot next, and maybe we can glean some pointer information from that.

[FaustWolf]

S'more findings: http://images.jupiterimages.com/common/detail/02/00/23030002.jpg

Okay, that was a horrible play on words.  Looking at hex code for three days straight does weird things to one's sense of humor. Anyway, here's some more results.

FACT: Quads "A" and "B" map to the same side of Serge's shoe, the outer side. Here's what happens when one blacks out "A" and "B" 's UV data: http://img525.imageshack.us/img525/1803/abblackedss0.gif

Quad A's non-UV data values: D0 FF B0 FE E8 FF 58 FF
Quad B's non-UV data values: D0 FF B0 FE E8 FF 58 FF


FACT: Quads "1" and "2" map to opposite sides of Serge's shoe. They're both on the back of the shoe, but symmetrically opposite: http://img525.imageshack.us/img525/3342/12experimentza1.gif

Quad 1's non-UV data values: F0 FF D0 FE 88 08 90 08
Quad 2's non-UV data values: D0 FF D0 FE E8 FF 98 08


FACT: Quads "3" and "B" map to opposite sides of Serge's shoe:
http://img525.imageshack.us/img525/6194/3bexperimentpq8.gif

Quad 3's non-UV data values: D0 FF D0 FE E8 FF A0 08
Quad B's non-UV data values: D0 FF B0 FE E8 FF 58 FF


FACT: Quads "4" and "5" map to opposite sides of Serge's shoe. Like "1" and "2", they seem connected yet symmetrically opposite:
http://img525.imageshack.us/img525/4971/45experimentzq4.gif

Quad 4's non-UV data values: D0 FF D0 FE E8 FF A8 08
Quad 5's non-UV data values: D0 FF D0 FE E8 FF B0 08


Anyone notice any useful patterns in the hex code? It would appear that all quads for which the last byte pair ends in the digit "8" map to one side of Serge's shoe, whereas all quads for which the last byte pair ends in the digit "0" map to the opposite side.

Also keep in mind that the last byte pairs of non-UV data for quads "1" through "5" are working positive pointers, whereas the last byte pairs of quads "A" and "B" do not appear to behave as nicely. Also, it's really weird that when the non-UV byte pairs of "A" are altered to 00, they behave as pointers to 0x28E8, the beginning of the vertex pool. However, when they are in their present state, they do not behave as working pointers. Therefore, whether or not the value is a pointer seems to be intrinsic within the value itself.

But on the other hand, not all values that look like they should be positive pointers really are. Confuzzlement. Any ideas on how these non-UV data might work?

[MDenham]

Also keep in mind that the last byte pairs of non-UV data for quads "1" through "5" are working positive pointers, whereas the last byte pairs of quads "A" and "B" do not appear to behave as nicely. Also, it's really weird that when the non-UV byte pairs of "A" are altered to 00, they behave as pointers to 0x28E8, the beginning of the vertex pool. However, when they are in their present state, they do not behave as working pointers. Therefore, whether or not the value is a pointer seems to be intrinsic within the value itself.

I assume specifically that you mean that you're changing all of A's non-UV to 0, and not just the pointer part.

The only thing I'm seeing as any sort of flag is that the second word is 0xFEB0 instead of 0xFED0 for A and B, which makes it look like the first four bytes of non-UV data are flags pertaining to, for example, whether or not the last four bytes are two pointers, one pointer and one non-pointer, two non-pointers, or whatever.

However, since the same bit is set in quad 1's Flags1 (only without the other bit, 0x0040, reset to 0), it looks like the 0x0020 flag isn't strictly a "corresponding value is a pointer" flag.

---

Side comment, and thoroughly unrelated to the current line of research: I have a pretty good guess as to what the "gobbledygook" value may be, and why modifying Section 1-1 seems to wreak such havoc.

The "gobbledygook" value is probably a checksum for Section 1-1.  This would explain why a pointer is kept to it, why making changes to Section 1-1 crashes the game (it doesn't match the checksum, game halts; when the game was being tested, presumably it'd pass information to an external debugger saying "hey, check me out"), and so on.

The problem is that I'm not entirely sure if it's just a straightforward "sum of this and every four-byte entry in 1-1 is 0" checksum, or if it's a CRC32, or what - but there's my idea as to what's going on earlier in Section 1.

[FaustWolf]

Thanks MDenham! Yes, I've been changing all the non-UV data to 00, on the assumption that the pointers would work on a byte pair-by-byte-pair basis. So in my first example where I changed quad "A" 's pointers, the non-UV data went from its normal state:

D0 FF B0 FE E8 FF 58 FF

to: 00 00 00 00 00 00 00 00. It seemed to make the UV map for A extend out to the vertex defined at address 0x28E8. Actually, I haven't found a working pointer anywhere in A's non-UV data; the values all look like they could be negative pointers, but no go -- all the vertices mapped at the addresses they would point to are on Serge's jacket and not his shoes.

Plus, both "A" and "B" have the exact same non-UV data, which worries me incredibly -- if these data values were pointers, these UV maps should be drawn to the same polygon on Serge's model, which isn't the case. That really complicates things.

THANK YOU for the checksum suggestion regarding Section 1-1 -- that's certainly a most plausible explanation for what's going on there. Looking at my records, it appears I was actually able to change one byte per experiment in Section 1-1 without a hitch back in October. I really didn't have any clue as to what I was looking for back then, so I think I'll try again and see what happens. I'll report what the original and new values are for the data I change, and maybe you can tell from that whether there's a checksum involved.

In addition to re-examining Section 1-1 very carefully, I'll try searching for bone data in Section 2 and Section 3. It's possible that the bone arrangement can provide some insight into how the non-UV data in Section 1-2 works, hopefully.

And BTW, does my model for the vertex coordinates in Section 1-3 appear plausible based on the visual evidence provided? I welcome critiques. And I have yet to determine the purpose of the vertex indices that follow the 3D coordinate data. Could be that that's linked to the bone data in some way too.

[MDenham]

Thanks MDenham! Yes, I've been changing all the non-UV data to 00, on the assumption that the pointers would work on a byte pair-by-byte-pair basis. So in my first example where I changed quad "A" 's pointers, the non-UV data went from its normal state:

D0 FF B0 FE E8 FF 58 FF

to: 00 00 00 00 00 00 00 00. It seemed to make the UV map for A extend out to the vertex defined at address 0x28E8. Actually, I haven't found a working pointer anywhere in A's non-UV data; the values all look like they could be negative pointers, but no go -- all the vertices mapped at the addresses they would point to are on Serge's jacket and not his shoes.

Plus, both "A" and "B" have the exact same non-UV data, which worries me incredibly -- if these data values were pointers, these UV maps should be drawn to the same polygon on Serge's model, which isn't the case. That really complicates things.

Well...  from what I've seen so far, the vast majority of non-UV data consists of (negative multiple of 16, negative multiple of 16, possible pointer, possible pointer) - with the exception, so far, of 0x19B8-0x19C7's quad, which is somewhat different.  Therefore, my conclusion right now is that the code that "parses" this data has two major features:

* If a two-byte value isn't a multiple of 8, it'll error; and
* Certain numbers, mostly negative ones, are special cases (most notably 0xFFE8, which seems to be a "refer to last polygon's fourth pointer" code).  For the time being, I'd go on the assumption that 0xFF80-0xFFF8 are special codes, not pointers, although this would seem to hose the last 8 16-byte vertices (they're still reachable by way of positive pointers, though).

Note that a lot of the "negative pointers" seem to be multiples of 16, though, by comparison to the normal pointers.

Current tentative list of "special codes", based on what I've seen so far:

0xFEB0 - unknown
0xFED0 - unknown
0xFFD0 - unknown
0xFFE0 - refer to prev. poly's 1st pointer
0xFFE8 - refer to prev. poly's 2nd pointer
0xFFF0 - refer to prev. poly's 3rd pointer
0xFFF8 - refer to prev. poly's 4th pointer

And BTW, does my model for the vertex coordinates in Section 1-3 appear plausible based on the visual evidence provided? I welcome critiques. And I have yet to determine the purpose of the vertex indices that follow the 3D coordinate data. Could be that that's linked to the bone data in some way too.

It's possible, though I suspect it's like Section 1-4 - Square didn't bother stripping out unnecessary data, and since it provided padding to keep things at an 8-byte multiple, it stayed in.

Out of curiosity, what's with the "polygons" at 0x1958 and 0x1968?  Their UV maps appear to be a single line of pixels.  Are they really flat-colored or a simple stripe pattern, or is something screwy going on here?

Finally, the "reversed" polygon for A seems to be at 0x18B8, based on how its UV data is set up.  (It seems like if one polygon is X1 Y1 X2 Y2 X3 Y3 X4 Y4, the reversed polygon will always be X2 Y2 X1 Y1 X4 Y4 X3 Y3, which makes sense [aside from the whole "I'm wondering how the graphics loader works now" thing].)

[FaustWolf]

Whoah, MDenham, you've done some very impressive work! I *think* I can very easily test the special values based on what you've provided -- then we'll have a bit more of the puzzle worked out. Thanks again!

As far as the "quads" starting at 0x1958 and 0x1968, that happens quite frequently, actually. I'm not sure what's up with it; these might act as filler space between other polygons. You know what, I'll see what happens when I black these out (zero out their UV map data, that is).

Oh, and MDenham -- by this:

0xFFF8 - refer to prev. poly's 4th pointer

you didn't mean this, did you?

0xFF58 - refer to prev. poly's 4th pointer

I'm actually not seeing any byte pairs that are F8 FF in Section 1-2 at all. Lots of 58 FF though. But maybe 0xFF58 is yet another code, and there are no codes that refer to the previous polygon's fourth pointer?

And it's certainly possible that the negative pointers I've seen so far are merely coincidence. Maybe all the xx FF byte pairs are special codes.

- - - - -

First experimental result of the day: MDenham is correct that the UV map starting at address 0x18B8 is "A" 's counterpart on the opposite side of Serge's shoe. I'll call this counterpart "Quad X"

So...
Quad A's non-UV data values: D0 FF B0 FE E8 FF 58 FF
Quad X's non-UV data values: D0 FF E0 FE E8 FF 70 08

- - - - -

Just to let everyone know, the .. FF byte pairs run the gamut from 00 FF through F0 FF in the non-UV data. No F8 FF in Kid's model either, so I guess if these are codes for the GPU/GTE to work with, they could potentially go from 0xFF00 through 0xFFF0.

Also, it appears that the values 0xFFA0 ~ 0xFFF0 occur way more often than 0xFF00 ~ 0xFF98. Could mean the ones above 0xFF98 are all codes, and the ones below are negative pointers. But keep in mind, not all values that should be negative pointers really are, at least from my experience.

- - - - -

Also MDenham, when the quads beginning at 0x1958 and 0x1968 have their UV data zero'd out, tiny areas at the edge of Serge's sock go black. Interestingly, the areas that go black don't necessarily correspond to the exact area we would expect to find them; it's possible that their purpose is to lift small snippets from one part of the texture and apply those to another part of the sock. In any case, here's the non-UV data for those two for quick comparison. They're on opposite sides of Serge's shoe.

"Line" 0x1958's non-UV data: F0 FF D0 FE B8 08 C0 08
"Line" 0x1968's non-UV data: D0 FF D0 FE E8 FF C8 08

[FaustWolf]

Hey, I finally succeeded in changing a few bytes in Section 1-1 without the game crashing!

The results are fairly interesting considering I changed only two bytes. Two views to get a full idea of what happened:
http://img75.imageshack.us/img75/3328/jacketdisappeareo4.gif
http://img66.imageshack.us/img66/834/jacketreappearsx5.gif

I thought at first that the lower parts of Serge's jacket disappeared, but in reality it's been blown out of proportion and possibly misplaced, perhaps. Here's the code I changed in Section 1-1. Perhaps we can use this example to determine whether or not there's a checksum going on:


I changed the first boxed value (at address 0x2A5) from 3F to DF.
I changed the second boxed value (at address 0x2C0) from 05 to 88.

- - - - -

Okay, I am this close to being certain that Section 1-1 contains bone data as Cyb suspected all along. I very carefully picked at the data, producing results like this:


Too many changes were involved to take detailed notes; I just randomy made values way larger, being careful to pass anything that was already 00 in value. But you can clearly see Serge's calf muscle and sock cuff sticking out of his hand. I'll get a Youtube vid up so everyone can see a full 360-degree view. (Meh, it's too fuzzy to really see what's going on, but it'll have to do for now: http://www.youtube.com/watch?v=8-Ao4M1amWU)

Can anyone familiar with bone data comment?

- - - - -

Having spent some quality time with Section 1-1, I still can't characterize the nature of the data with any certainty. I was hoping I'd be able to stick Serge's shoes on his head or something, but I'm mostly getting weird texture stretches. The data in Section 1-1 seems to run on an 8-byte scheme from what I can tell, so I figured on taking two bytes at a time and seeing what happens. Here's some resutls...

First two bytes of random "slots" altered in various ways. Serge's textures go all haywire, and may even be trying to map to the other characters in the party:
http://img337.imageshack.us/img337/3650/bytes1and2fg1.gif

When I change the seventh and eight bytes of randomly-selected "slots", I get results that aren't all that much different -- texture stretches:
http://img444.imageshack.us/img444/7007/bytes7and8gb7.gif

But then again, Serge's foot and leg were floating in the pic in this post's previous update, so I dunno. Hopefully someone with more experience in these matters can tell whether or not bone data is being affected.

[MDenham]

Oh, and MDenham -- by this:

0xFFF8 - refer to prev. poly's 4th pointer

you didn't mean this, did you?

0xFF58 - refer to prev. poly's 4th pointer

Actually, what I had was off by a bit.  Serves me right for posting that late at night. 

Corrected table, under the "special codes" theory:

0xFFE8 - previous poly's Ptr4
0xFFE0 - previous poly's Ptr3
0xFFD8 - previous poly's Ptr2
0xFFD0 - previous poly's Ptr1

- OR -

0xFF?? is a negative pointer...  but not into the vertex data itself.  Instead, it points backwards relative to the "expanded" form of the vertex data (each poly's vertices, listed in order), like so:

(poly 1 V1) (poly 1 V2) (poly 1 V3) (poly 1 V4) (poly 2 V1) ... (poly X V3 or 4)

Keep in mind each of these entries is, presumably, 8 bytes, and there are duplicates.  Sometimes frequent duplicates, depending on how many polys actually share a vertex.

Now, 0xFFE8 happens to be -24, or -3 entries.  Since 0xFFE8 seems to be very common as a third entry, we count backwards three spots (not counting itself)...  and we run into the previous polygon's fourth vertex!  This also explains the prevalence of 0xFFD0 (-48, or -6 entries), possibly - though tracing back through a sequence of 0xFFD0 looks like it takes a while.

How do we check if it's actually working this way?  Well...  a run of triangles that have non-UV data of the form XX XX F0 FF (two bytes of real pointer) would be a damn good sign of this (you'd end up with a series of triangles where each one shares an edge with the preceding one).  Likewise, the first poly overall shouldn't have ANY of these back references, the second one can have ones up to 0xFFC8 (but probably will only have 0xFFE8), etc.