Yeah, we're really kicking ass, but it's all thanks to the knowledge everyone's bringing to the table here. If we can get these pointers nailed down and find the bone information, I think that may be all we need to do some rudimentary viewing of the models. I would assume the models exist in a frozen battle pose in their "natural" state, without animation data being applied to them -- I think that's how FF7 worked anyway, judging from the FF7 models I've seen with Mirex's viewing tools.
Halkun, major thanks for taking the time out to illustrate the triangle strips and fans. It certainly seems we've found quad strips, and I imagine if I mapped out some triangles on Serge's texture according to the data they'd be arranged the same way, or similarly. If the PSX GPU doesn't do such things, the model editing program the Squeenies used certainly did -- I wonder how much it would help if we knew which model editing program these were created in?
The next step is figuring out what these pointers are pointing to, exactly. And MDenham, I don't have a pic on hand at the moment, but there certainly is a texture boundary being crossed in the data I posted above. The pointer at address 0x1832 is referring to a vertex on the side of Serge's shoe from what I can tell, and the ones at addresess 0x1724 and 0x1736 refer to Serge's leg. The value 0x07E8 at address 0x1724 definitely works as a positive pointer into the vertex pool, because changing the coordinates of the vertex it's pointing to causes a texture spike from the area being mapped on the texture.
- - - - -
Okay, this evening's first experimental results are in. I did a test MDenham suggested earlier -- going back to the almighty "shoe" and changing Quad B's pointers (which are the negative kind we've been examining recently) to the values we believe they would point to based on the scheme M developed. The results are 50% successful, with some oddities hindering our full understanding of the pointers.
First, the code that's applicable here:
We're focusing on the data for Quad B. Its original pointer byte pairs are thus: D0FF B0FE E8FF 58FF
Let's trace where they go (or where they
should go) one by one...
0xFFD0 = -48, /8 = 6 positions back in the non-UV data. That brings us to address 0x1934, which in turn leads us an additional three positions back to address 0x1926.
0xFEB0 = -336, /8 = 42 positions back. That leads us to...address 0x18A6 if I'm counting right.
0xFFE8 = -24, /8 = an easy 3 positions backward to address 0x1946.
0xFF58 = -168, /8 = 21 positions backward to address 0x1904.
Thus, reading by our current scheme, Quad B's pointer byte pairs should be equivalent to: A008 6008 B008 8808
If we're reading the pointers correctly, then changing Quad B's pointers to these byte pairs should have no effect on the model -- those values should be the actual pointers into the vertex pool.
Now let's try altering the last two byte pairs so Quad B's non-UV data becomes D0FF B0FE
B008 8808. So far, so good -- no change:
http://img263.imageshack.us/img263/4103/lasttwopterschangedwu2.gifThat means we're reading the byte pairs E8 FF and 58 FF correctly.
Now let's try the first two byte pairs as well, so that Quad B's non-UV data is A008 6008 B008 8808:
http://img263.imageshack.us/img263/1993/allpterschangedvi1.gifIf you look closely, there's a bit of a graphical hiccup, a very thin texture stretch from Serge's sock. That means we're just slightly off. At first I thought something weird might be up with the value 0xFEB0, so I switched the second byte pair back to B0FE. But now things are even worse:
http://img263.imageshack.us/img263/8769/firstpterchangedox2.gifThis means that the first pointer value, 0xD0FF, isn't being read correctly, since it's the only one that could be causing a problem if the second byte pair is switched to its original state. So I figure, "okay, the problem is with the first pointer value." Yet switching only the second pointer is still problematic:
http://img263.imageshack.us/img263/7586/secondpterchangedyy6.gifSo I believe we're interpreting the values 0xFFE8 and 0xFF58 correctly, but something weird's up with our interpretation of 0xFEB0 and 0xFFD0. I wish it were my counting that was off -- let me know if that's the case, anybody, and I'll be a happier camper than I am right now. But as things stand, the interpretation of these as negative integers with division by 8 giving us the number of positions backward doesn't capture the full picture.
Discuss.