Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Cyberman on 2004-08-18 06:26:55
-
Alright.. this has been a frustration for a few of us. So this is my thread to put the Coup De Grat to this nusance I mean .. problem :D
First What I know:
[list=1]
- The playstation version Model is Section 0
- The playstation version Bone data and visual data is in Section 0
- The tim section location is NOT PREDICTABLE in the playstation version. That is there is no reference to where it should be. It must be found by inspecting the 'Magic#' information for each section.
- Using Cloud as the 'reference' model for everything. There are EXACTLY 95 sections between Section 0 and the TIM
- There are 94 Animations in Cloud in the PC Version
[/list:o]
What does this mean?
Section one does not resemble anything of interest and isn't the same block size as anything on the PC.
SECTION 2 hower.. is almost IDENTICAL to the first animation block on the PC
Clues?
Ignore the 16 byte header of the PC version (more on this later :D ).
SECTION 2's next 7 bytes (starting at offset 0 of section 2)
Are exactly the same as the PC's data
PC
00000000 5E 00 00 00 18 00 00 00 14 00 00 00 5C 03 00 00
00000010 14 00 56 03 00 00 00 DD 2E 00 00 00 00 00 00 0C
00000020 00 38 61 00 F8 2F 73 46 A0 2B 0C 82 2B 38 2F 02
00000030 AE 61 86 40 12 2D 35 41 53 65 6E 53 00 00 00 02
PS1 SECTION 2
00000000 14 00 56 03 00 00 00 FE 2E 00 00 00 00 00 00 0C
00000010 00 EC E0 00 F8 2F E5 E8 A0 BB 0C 82 BC EC 2F 02
00000020 AE 61 86 40 12 C1 35 41 E4 EE 6E 53 00 00 00 02
This reveals the data to be almost identical save for one little discrepency at offset
( relative to MATCHING data in the PS1) 7 it's 0xDD in the PC and 0xFE in the Playstation otherwise everything else is identical.
SECTION ONE IN THE PLAYSTATION I suspect is critical to revealing something in the PC as well :)
Also of note there are 4 byte sections in the animation data of cloud
They all read
30 1A 00 00
I believe the best way to decode these sections is to call them
typedef struct {
unsigned short ZZ;
unsigned short length;
} anim_header;
Cyb <Jubulent>
-
All right I need to verify if I'm decoding the data correctly. Mirex you wouldn't happen to have a list of Clouds first animation frame in terms of rotation angles from the data you can extract using Leviathon or (whatever you might use) :)
ZZ1 = 0014
Len = 854
Xlate (0, -512, 46)
ZZ2 = 0
00 <0, 0, 0>
01 <270, 332, 0>
02 <180, 322, 180>
03 <248, 183, 270>
04 <338, 245, 22.5>
05 <0, 271, 112>
06 <90, 155, 67.5>
07 <0, 2.81, 0>
08 <338, 336, 338>
09 <338, 22.5, 135>
10 <45, 242, 315>
11 <0, 0, 0>
12 <90, 42.2, 90>
13 <225, 0, 45>
14 <338, 165, 22.5>
15 <0, 18.3, 22.5>
16 <67.5, 298, 338>
17 <22.5, 0, 135>
18 <0, 152, 90>
19 <45, 0, 0>
20 <248, 190, 90>
21 <135, 0, 0>
22 <112, 0, 22.5>
This is data from the first possible animation of cloud in the playstation version. If these are the same as what you get then I've gotten that far at least. I've noticed a few things
ZZ in the header of the animation has a number of variations. I think this contains information about the animation possibly the number of frames.
Cyb
-
Well you have to wait a moment for it, i have to get to my other CPU in a different city. Im gonna travel in the evening, but im not sure if i'll be able to post the info today. Btw im finishing all the stuff about Halflife & Milkshape, so im gonna start working on FF7 PSX soon.
-
So here goes the first animation rotation data of battle cloud:
bones = 23
AnimHdr:
rec_a = 24
rec_b = 90
block_len = 5656
block_a = 90
real_data_len = 5650
translat = < 0, 65024, 62 >
u1 = 0
<270, 333, 0>
<356, 353, 327>
<16, 17, 61>
<338, 334, 243>
<34, 89, 61>
<75, 44, 337>
<322, 0, 0>
<3, 8, 336>
<5, 16, 56>
<65, 0, 15>
<55, 241, 317>
<338, 0, 0>
<353, 359, 332>
<0, 229, 0>
<59, 321, 244>
<35, 0, 0>
<298, 3, 63>
<298, 0, 0>
<0, 77, 0>
<27, 270, 7>
<64, 0, 0>
<329, 349, 7>
<300, 0, 0>
looks little differeent from yours, but first line <270, 333, 0> looks the same ... are you decoding it correctly ? you have to carry half of the byte from the 1st rotation to the 2nd ...
btw you can check it out on the original file ... here is RTDA (http://bin.mypage.sk/FILES/RTDA), the cloud's battle animation file
-
ooks little differeent from yours, but first line <270, 333, 0> looks the same ... are you decoding it correctly ? you have to carry half of the byte from the 1st rotation to the 2nd ...
btw you can check it out on the original file ... here is RTDA, the cloud's battle animation file
Well I thought I was :D
This is grabed from the PSX data but I guess I need to work on it some more (hmmm).
The translate is almost identical though ( 65024 is actually FE00 which is -512 in signed int format). The integers are signed I believe for the offset (which makes more sense considering your offset :D ).
5pmish
EDITED MUCH
Ok I made an error I didn't boolean negate a boolean variable so it was always true and thus it was using the wrong sequence to decode. The new listing much more closely matches yours Mirex.
ZZ1 = 0014
Len = 854
Xlate (0, -512, 46)
ZZ2 = 0
00 <0, 0, 0>
01 <270, 333, 0>
02 <349, 358, 327>
03 <16.4, 17.6, 61.5>
04 <332, 338, 245>
05 <34.3, 90.1, 62>
06 <74.9, 42.5, 335>
07 <322, 0, 0>
08 <3.69, 8.53, 336>
09 <359, 21.1, 53.3>
10 <66.2, 0.527, 15.9>
11 <56.2, 242, 319>
12 <338, 0, 0>
13 <355, 359, 332>
14 <0, 229, 0>
15 <58.4, 314, 235>
16 <25, 0, 0>
17 <304, 359, 68.2>
18 <299, 358, 1.41>
19 <0, 77.2, 0>
20 <31.5, 270, 7.65>
21 <58.4, 0, 0>
22 <331, 349, 5.98>
-
Nice progress man ;)