4cite Posted December 26, 2019 Posted December 26, 2019 On 12/14/2019 at 1:43 AM, vagonumero13 said: UPDATE REDELBE. Hey man, I'm brand new to DoA6 Modding and I've only been able to find Modder Base which has v0.82 last edited in June. Where do I go for further updates?
vagonumero13 Posted December 26, 2019 Author Posted December 26, 2019 5 hours ago, 4cite said: Hey man, I'm brand new to DoA6 Modding and I've only been able to find Modder Base which has v0.82 last edited in June. Where do I go for further updates? It is in this thread, in the first post.
4cite Posted December 26, 2019 Posted December 26, 2019 9 hours ago, vagonumero13 said: It is in this thread, in the first post. Thank you!
3566482543 Posted December 26, 2019 Posted December 26, 2019 11 minutes ago, Rebel o Conner said: where to find the input8.dll file? Input or dinput? dinput8.dll 1
Joschuka Posted December 30, 2019 Posted December 30, 2019 Hey @vagonumero13, just wanted to tell you that my partners have almost labelled everything in G1A/G2A, you can find the latest binary template here https://github.com/three-houses-research-team/010-binary-templates/blob/master/Model related formats/G1A.bt Basically section 1 is bit packed and contains some kind of "frame headers" with some info like the number of splines for this frame and the data offset. Other header info include the max bone index and other stuff. The unknown ushort in section 2 (the one who's mostly 0 and 1) is suspected to design the spline type (0 for rotation, 1 for translation, 2 for scale). What's left to do is to figure out how to read the section 3 data and we should be good to go. On an unrelated note, could you tell me what NUNO/NUNV versions do the DOA6 models use ? I suspect cloth fixing equations to rely on that since I have to use different formulas to fix old g1m like Hyrule Warriors and recent ones like FETH. But maybe they just rely on Cloth sections like 0301 and 0303, I need to dig a bit more.
vagonumero13 Posted December 30, 2019 Author Posted December 30, 2019 2 hours ago, Joschuka said: Hey @vagonumero13, just wanted to tell you that my partners have almost labelled everything in G1A/G2A, you can find the latest binary template here https://github.com/three-houses-research-team/010-binary-templates/blob/master/Model related formats/G1A.bt Basically section 1 is bit packed and contains some kind of "frame headers" with some info like the number of splines for this frame and the data offset. Other header info include the max bone index and other stuff. The unknown ushort in section 2 (the one who's mostly 0 and 1) is suspected to design the spline type (0 for rotation, 1 for translation, 2 for scale). What's left to do is to figure out how to read the section 3 data and we should be good to go. On an unrelated note, could you tell me what NUNO/NUNV versions do the DOA6 models use ? I suspect cloth fixing equations to rely on that since I have to use different formulas to fix old g1m like Hyrule Warriors and recent ones like FETH. But maybe they just rely on Cloth sections like 0301 and 0303, I need to dig a bit more. Precisely I was looking at this this morning, I could figure out that the value at offset 0x10 in the header is the number of frames (including non-keyframes, e.g. you can virtually extend any animation by increasing this value, although that just will cause the character to be in the last position for longer, since the number of keyframes will remain the same). If you divide this by fps, you get the length in seconds of the animation. I think this part doesn't match your data (that would be, more or less, max_bone_index in your code, I think). So basically those 4 bytes are number of real frames & number of keyframes, it would make sense that they go together. Also had figured out that one of the two 16 bit values that go in pairs was the offset of the keyframe divided by 4, but I will check later with your data, as I had no idea of what the other value was (I hadn't thougt that these things would be bitpacked). As for the data of matrices, I can tell you about the translation. In DOA6 animations, the first matrix is always an all 0 matrix, and the opcode value in the frame (the 0, 1, 2) is 0, and the second matrix has opcode 1. I did tests with the later and the translation is stored at the last 4 float values (well, only first 3 of those 4), so well, this coincides with where the translation data in a transformation matrix where columns are stored before rows. (I did test with an animation, and this caused moves to x, y, z). I think that was the order of DirectX matrices, but me and matrix orders don't get along very well, and I don't know if they would use same matrix order in all plattforms. (btw only difference between G2A 0300 and 0500, is that 0300 doesn't have the " unknown1_count " in header). --------- A random .g1m I had at hand (Mai standard costume): NUNO is 9200. NUNV is 1100. That said, I have never looked at these sections.
Joschuka Posted December 30, 2019 Posted December 30, 2019 Ah that info about the value at 0x10 is interesting, wouldn't have thought about it being the total duration in frames. I need to double check with my friend though but apparently they found out that game reads these 4 bytes as // Actual disasm // frame_header_size = (packed_data >> 18) & 0x3FFC; // max_bone_index = packed_data & 0xFFF; // // frame_header_blob_size could be 12 bits, and max_bone_index could be 20-- // however this is not how the game parses the data. the "frame header size" seems to match almost everytime but what is called "max_bone_index" is probably the duration you're talking about. Unfortunately we can't check this ourselves as this game doesn't have any name for the anims so we can't modify some stuff and see what happens in game afterwards, we weren't able to isolate some stuff yet since there are so many... But if you tested it that should be the case, thanks for the info. Nice, thanks for the info about the translation stuff, this doesn't the idea that 01 would be an ID for a translation spline, that's good. I thought about these matrices being transform matrices but some values seemed wrong and if the int gives the spline type as we suppose it wouldn't be needed to have a whole transform matrix with all rotation, translation and scale, We'll look more into it. When you say floats you mean 16bits floats (or halffloats) not 32 bits floats right ? Yeah my partner noticed that about the " unknown1_count " , it's completely missing in the G1A and early G2A files apparently. Ok interesting, the NUNO version is the same as in Fire Emblem, there are no NUNV versions in FE but these NUNV are almost exactly the same as NUNO, just used for hair instead of cloth (although NUNO is used for hair in FE lol) There's a lot of info we don't know yet but basically it contains some physics bones which are probably used by the physics engine. Also the NUNO version seems to indicate which equations have to be used to fix the cloth meshes. To illustrate, here's Edelgard without the NUNO sections not parsed by my script: And here's one with the NUNO sections taken into account and cloth fixed: Don't mind the white planes, these are just mesh drivers created to facilitate cloth rigging in Blender (with some Data transfer stuff for example) I don't know much more about these though, only NUNO0301 and NUNO0303 sections seem to be used to get these bones from.
vagonumero13 Posted December 30, 2019 Author Posted December 30, 2019 17 hours ago, Joschuka said: I have soem doubts about the "next_header_offset". I think it may mean other thing. This is a dump of those three values in a DOA animation (spline_count, next_header_offset, data_offset): (btw, I had to change data type to unsigned int, or otherwise spline_count=2 would get the -2 value). Spoiler 2 0x4 0x0 2 0x8 0x160 1 0xc 0x300 1 0x10 0x530 1 0x14 0x810 1 0x18 0x9f0 1 0x1c 0xba0 1 0x20 0xef0 1 0x24 0x11d0 1 0x28 0x1340 1 0x2c 0x1530 1 0x30 0x1730 1 0x34 0x19d0 1 0x38 0x1bf0 1 0x3c 0x1e60 1 0x40 0x2320 1 0x44 0x2720 1 0x48 0x29b0 1 0x4c 0x2c50 1 0x50 0x31a0 2 0x54 0x3640 2 0x58 0x37e0 1 0x5c 0x3a30 1 0x60 0x3d40 1 0x64 0x3e00 1 0x78 0x3e30 1 0x7c 0x40f0 1 0x80 0x42f0 1 0x84 0x44f0 1 0x88 0x4710 1 0x8c 0x48b0 1 0x90 0x4ac0 1 0x94 0x4bf0 1 0x98 0x4cc0 1 0x9c 0x4db0 1 0xa0 0x4e50 1 0xa4 0x4f10 1 0xa8 0x5000 1 0xac 0x50e0 1 0xb0 0x51c0 1 0xb4 0x5280 1 0xb8 0x5390 1 0xbc 0x5460 1 0xc0 0x55d0 1 0xc4 0x5690 1 0xc8 0x57d0 1 0xcc 0x5900 1 0xd0 0x5a60 1 0xd4 0x5b70 1 0xd8 0x5cc0 1 0xdc 0x5e00 1 0xe0 0x5ee0 1 0xe4 0x6030 1 0xe8 0x6150 1 0xec 0x6280 1 0xf0 0x63a0 1 0xf4 0x64b0 The spline count is correct. The data offset is also correct (you have to divide that number by 4 to actually get the offset, though). But the next header offset doesn't seem to match. Notice that at some point it goes from 0x64 to 0x78. And offsets like 0xe8-0xf4 would be out of range. I think that number is actually that number / 4 (probably the bit field was incorrect), which causes the number to go in a sequence like: 1, 2, 3, 4, ... 61, where the range 25-29 was skipped for some reason.
acuna43 Posted December 31, 2019 Posted December 31, 2019 Vagunumero13 I have problem to launched doa6 please help i have lastest version redelbe
vagonumero13 Posted December 31, 2019 Author Posted December 31, 2019 8 hours ago, acuna43 said: Vagunumero13 I have problem to launched doa6 please help i have lastest version redelbe Latest REDELBE only supports 1.17 and 1.16. You have a very old game version (1.08, from what I can tell from those .rdb.bin in the screenshot).
Joschuka Posted December 31, 2019 Posted December 31, 2019 10 hours ago, vagonumero13 said: I have soem doubts about the "next_header_offset". I think it may mean other thing. This is a dump of those three values in a DOA animation (spline_count, next_header_offset, data_offset): (btw, I had to change data type to unsigned int, or otherwise spline_count=2 would get the -2 value). Reveal hidden contents 2 0x4 0x0 2 0x8 0x160 1 0xc 0x300 1 0x10 0x530 1 0x14 0x810 1 0x18 0x9f0 1 0x1c 0xba0 1 0x20 0xef0 1 0x24 0x11d0 1 0x28 0x1340 1 0x2c 0x1530 1 0x30 0x1730 1 0x34 0x19d0 1 0x38 0x1bf0 1 0x3c 0x1e60 1 0x40 0x2320 1 0x44 0x2720 1 0x48 0x29b0 1 0x4c 0x2c50 1 0x50 0x31a0 2 0x54 0x3640 2 0x58 0x37e0 1 0x5c 0x3a30 1 0x60 0x3d40 1 0x64 0x3e00 1 0x78 0x3e30 1 0x7c 0x40f0 1 0x80 0x42f0 1 0x84 0x44f0 1 0x88 0x4710 1 0x8c 0x48b0 1 0x90 0x4ac0 1 0x94 0x4bf0 1 0x98 0x4cc0 1 0x9c 0x4db0 1 0xa0 0x4e50 1 0xa4 0x4f10 1 0xa8 0x5000 1 0xac 0x50e0 1 0xb0 0x51c0 1 0xb4 0x5280 1 0xb8 0x5390 1 0xbc 0x5460 1 0xc0 0x55d0 1 0xc4 0x5690 1 0xc8 0x57d0 1 0xcc 0x5900 1 0xd0 0x5a60 1 0xd4 0x5b70 1 0xd8 0x5cc0 1 0xdc 0x5e00 1 0xe0 0x5ee0 1 0xe4 0x6030 1 0xe8 0x6150 1 0xec 0x6280 1 0xf0 0x63a0 1 0xf4 0x64b0 The spline count is correct. The data offset is also correct (you have to divide that number by 4 to actually get the offset, though). But the next header offset doesn't seem to match. Notice that at some point it goes from 0x64 to 0x78. And offsets like 0xe8-0xf4 would be out of range. I think that number is actually that number / 4 (probably the bit field was incorrect), which causes the number to go in a sequence like: 1, 2, 3, 4, ... 61, where the range 25-29 was skipped for some reason. Ah that's funny, on all the g2a files I checked it worked (I checked like 10). There were all G2A 0500 though, maybe your file was a g1a or a g2a 0300 and in these dividing by 4 is necessary ? We don't have those unfortunately in FETH so maybe our BT is innacurate for them, it was a bit of an over extension to assume it'd work for all animation versions. That jump is interesting indeed, I didn't have anything like that in any of the g2a 0500 files I checked, the next offset header always matched. I'll double check though.
vagonumero13 Posted December 31, 2019 Author Posted December 31, 2019 25 minutes ago, Joschuka said: Ah that's funny, on all the g2a files I checked it worked (I checked like 10). There were all G2A 0500 though, maybe your file was a g1a or a g2a 0300 and in these dividing by 4 is necessary ? We don't have those unfortunately in FETH so maybe our BT is innacurate for them, it was a bit of an over extension to assume it'd work for all animation versions. That jump is interesting indeed, I didn't have anything like that in any of the g2a 0500 files I checked, the next offset header always matched. I'll double check though. I confirmed by live debugging. The value is used as an index into this 16bit array: Spoiler As you see, after 0x19 (25), there are several -1 indexes, which is exactly the gap I noticed. So at beginning, indexes would match the value in the array, but index 30 would get the value 26. And so, until index 61 (0x3D) would get value 57 (0x39). After that there is another gap, but all of my animations samples only have until index 61. 61 is the total number of animation steps, 57 the number of keyframes, cannot be a coincidence. The array has actually 827 entries (the game compares the index to ensure it is lower than that), but I don't know from where the 827 was calculated or if it is fixed.
vagonumero13 Posted December 31, 2019 Author Posted December 31, 2019 Ok, I found out from where the gap is. The gap matches the gap in bones of characters. The list of basic body bones in a DOA6 character: Spoiler 0,root 1,SK_Skeleton 2,SK_Hips 3,SK_L_UpLeg 4,SK_R_UpLeg 5,SK_L_Leg 6,SK_R_Leg 7,SK_L_Foot 8,SK_R_Foot 9,SK_Spine01 10,SK_Spine02 11,SK_Neck 12,SK_Head 13,SK_L_Shoulder 14,SK_R_Shoulder 15,SK_L_Arm 16,SK_R_Arm 17,SK_L_ForeArm 18,SK_R_ForeArm 19,SK_L_Hand 20,SK_R_Hand 21,SK_L_Weapon 22,SK_R_Weapon 23,SK_L_Toes 24,SK_R_Toes 25,SK_Endangle 30,SK_L_Thumb01 31,SK_R_Thumb01 32,SK_L_Index01 33,SK_R_Index01 34,SK_L_Middle01 35,SK_R_Middle01 36,SK_L_PinkySide 37,SK_R_PinkySide 38,SK_L_Thumb02 39,SK_R_Thumb02 40,SK_L_Index02 41,SK_R_Index02 42,SK_L_Middle02 43,SK_R_Middle02 44,SK_L_Ring01 45,SK_R_Ring01 46,SK_L_Pinky01 47,SK_R_Pinky01 48,SK_L_Thumb03 49,SK_R_Thumb03 50,SK_L_Index03 51,SK_R_Index03 52,SK_L_Middle03 53,SK_R_Middle03 54,SK_L_Ring02 55,SK_R_Ring02 56,SK_L_Pinky02 57,SK_R_Pinky02 58,SK_L_Ring03 59,SK_R_Ring03 60,SK_L_Pinky03 61,SK_R_Pinky03 65,RF_L_Arm_00 66,RF_R_Arm_00 67,RF_L_Arm_01 68,RF_R_Arm_01 69,RF_L_Arm_02 70,RF_R_Arm_02 71,RF_L_Elbow_00 72,RF_R_Elbow_00 73,RF_L_ForeArm_00 74,RF_R_ForeArm_00 75,RF_L_ForeArm_01 76,RF_R_ForeArm_01 77,RF_L_UpLeg_00 78,RF_R_UpLeg_00 79,RF_L_UpLeg_01 80,RF_R_UpLeg_01 81,RF_L_UpLeg_02 82,RF_R_UpLeg_02 83,RF_L_Knee_00 84,RF_R_Knee_00 85,RF_L_Leg_00 86,RF_R_Leg_00 87,RF_L_HipBack 88,RF_R_HipBack 89,RF_L_HipOutSide 90,RF_R_HipOutSide 91,RF_L_HipInSide 92,RF_R_HipInSide 120,F_Face 121,F_C_01 122,F_C_02 123,F_C_03 124,F_C_04 125,F_C_05 126,F_C_06 127,F_C_11 128,F_C_12 129,F_C_14 130,F_C_15 131,F_C_16 132,F_C_17 133,F_C_18 134,F_C_19 135,F_C_20 136,F_C_21 137,F_C_22 138,F_C_23 139,F_C_24 140,F_C_25 141,F_C_26 142,F_C_27 143,F_C_30 144,F_C_31 145,F_C_32 146,F_L_22a 147,F_L_22b 148,F_L_22c 149,F_L_23a 150,F_L_23b 151,F_L_23c 152,F_L_24a 153,F_L_24b 154,F_L_24c 155,F_L_25a 156,F_L_25b 157,F_L_25c 158,F_L_26a 159,F_L_26b 160,F_L_26c 161,F_L_26d 162,F_L_26e 163,F_L_26f 164,F_L_26g 165,F_L_27a 166,F_L_27b 167,F_L_27c 168,F_L_27d 169,F_L_27e 170,F_L_27f 171,F_R_22a 172,F_R_22b 173,F_R_22c 174,F_R_23a 175,F_R_23b 176,F_R_23c 177,F_R_24a 178,F_R_24b 179,F_R_24c 180,F_R_25a 181,F_R_25b 182,F_R_25c 183,F_R_26a 184,F_R_26b 185,F_R_26c 186,F_R_26d 187,F_R_26e 188,F_R_26f 189,F_R_26g 190,F_R_27a 191,F_R_27b 192,F_R_27c 193,F_R_27d 194,F_R_27e 195,F_R_27f 196,F_C_28 197,F_L_01a 198,F_L_01b 199,F_L_01c 200,F_L_01d 201,F_L_01e 202,F_L_01f 203,F_L_01g 204,F_L_01h 205,F_L_02a 206,F_L_02b 207,F_L_02c 208,F_L_02d 209,F_L_02e 210,F_L_02f 211,F_L_02g 212,F_L_02h 213,F_L_03a 214,F_L_03b 215,F_L_03c 216,F_L_03d 217,F_L_03e 218,F_L_03f 219,F_L_03g 220,F_L_03h 221,F_L_04a 222,F_L_04b 223,F_L_04c 224,F_L_04d 225,F_L_04e 226,F_L_04f 227,F_L_04g 228,F_L_04h 229,F_L_05a 230,F_L_05b 231,F_L_05c 232,F_L_05d 233,F_L_05e 234,F_L_05f 235,F_L_05g 236,F_L_05h 237,F_L_06a 238,F_L_06b 239,F_L_06c 240,F_L_06d 241,F_L_06e 242,F_L_06f 243,F_L_06g 244,F_L_06h 245,F_L_06i 246,F_L_07a 247,F_L_07b 248,F_L_07c 249,F_L_07d 250,F_L_07e 251,F_L_07f 252,F_L_07g 253,F_L_08a 254,F_L_08b 255,F_L_08c 256,F_L_09a 257,F_L_09b 258,F_L_09c 259,F_L_09d 260,F_L_10a 261,F_L_10b 262,F_L_10c 263,F_L_10d 264,F_L_10e 265,F_L_11a 266,F_L_11b 267,F_L_11c 268,F_L_11d 269,F_L_11e 270,F_L_11f 271,F_L_11g 272,F_L_12a 273,F_L_12b 274,F_L_12c 275,F_L_12d 276,F_L_12e 277,F_L_12f 278,F_L_12g 279,F_L_12h 280,F_L_13a 281,F_L_13b 282,F_L_13c 283,F_L_13d 284,F_L_14a 285,F_L_14b 286,F_L_14c 287,F_L_14d 288,F_L_14e 289,F_L_14f 290,F_L_14g 291,F_L_14h 292,F_L_14i 293,F_L_14j 294,F_L_15a 295,F_L_15b 296,F_L_15c 297,F_L_15d 298,F_L_15e 299,F_L_15f 300,F_L_15g 301,F_L_16a 302,F_L_16b 303,F_L_16c 304,F_L_16d 305,F_L_16e 306,F_L_16f 307,F_L_17a 308,F_L_17b 309,F_L_17c 310,F_L_17d 311,F_L_18a 312,F_L_18b 313,F_L_18c 314,F_L_19a 315,F_L_19b 316,F_L_19c 317,F_L_20a 318,F_L_20b 319,F_L_20c 320,F_L_20d 321,F_L_20e 322,F_L_20f 323,F_L_20g 324,F_L_20h 325,F_L_20i 326,F_L_20j 327,F_L_20k 328,F_L_20l 329,F_L_20m 330,F_L_28a 331,F_R_01a 332,F_R_01b 333,F_R_01c 334,F_R_01d 335,F_R_01e 336,F_R_01f 337,F_R_01g 338,F_R_01h 339,F_R_02a 340,F_R_02b 341,F_R_02c 342,F_R_02d 343,F_R_02e 344,F_R_02f 345,F_R_02g 346,F_R_02h 347,F_R_03a 348,F_R_03b 349,F_R_03c 350,F_R_03d 351,F_R_03e 352,F_R_03f 353,F_R_03g 354,F_R_03h 355,F_R_04a 356,F_R_04b 357,F_R_04c 358,F_R_04d 359,F_R_04e 360,F_R_04f 361,F_R_04g 362,F_R_04h 363,F_R_05a 364,F_R_05b 365,F_R_05c 366,F_R_05d 367,F_R_05e 368,F_R_05f 369,F_R_05g 370,F_R_05h 371,F_R_06a 372,F_R_06b 373,F_R_06c 374,F_R_06d 375,F_R_06e 376,F_R_06f 377,F_R_06g 378,F_R_06h 379,F_R_06i 380,F_R_07a 381,F_R_07b 382,F_R_07c 383,F_R_07d 384,F_R_07e 385,F_R_07f 386,F_R_07g 387,F_R_08a 388,F_R_08b 389,F_R_08c 390,F_R_09a 391,F_R_09b 392,F_R_09c 393,F_R_09d 394,F_R_10a 395,F_R_10b 396,F_R_10c 397,F_R_10d 398,F_R_10e 399,F_R_11a 400,F_R_11b 401,F_R_11c 402,F_R_11d 403,F_R_11e 404,F_R_11f 405,F_R_11g 406,F_R_12a 407,F_R_12b 408,F_R_12c 409,F_R_12d 410,F_R_12e 411,F_R_12f 412,F_R_12g 413,F_R_12h 414,F_R_13a 415,F_R_13b 416,F_R_13c 417,F_R_13d 418,F_R_14a 419,F_R_14b 420,F_R_14c 421,F_R_14d 422,F_R_14e 423,F_R_14f 424,F_R_14g 425,F_R_14h 426,F_R_14i 427,F_R_14j 428,F_R_15a 429,F_R_15b 430,F_R_15c 431,F_R_15d 432,F_R_15e 433,F_R_15f 434,F_R_15g 435,F_R_16a 436,F_R_16b 437,F_R_16c 438,F_R_16d 439,F_R_16e 440,F_R_16f 441,F_R_17a 442,F_R_17b 443,F_R_17c 444,F_R_17d 445,F_R_18a 446,F_R_18b 447,F_R_18c 448,F_R_19a 449,F_R_19b 450,F_R_19c 451,F_R_20a 452,F_R_20b 453,F_R_20c 454,F_R_20d 455,F_R_20e 456,F_R_20f 457,F_R_20g 458,F_R_20h 459,F_R_20i 460,F_R_20j 461,F_R_20k 462,F_R_20l 463,F_R_20m 464,F_R_28a 500,RF_L_ForeArmNoTwist 501,RF_R_ForeArmNoTwist 502,RF_L_HandNoTwist 503,RF_R_HandNoTwist 504,RF_L_ElbowNoTwist 505,RF_R_ElbowNoTwist 506,RF_L_LegNoTwist 507,RF_R_LegNoTwist 508,RF_L_KneeNoTwist 509,RF_R_KneeNoTwist 510,RF_L_F_ShoulderSeam 511,RF_R_F_ShoulderSeam 512,RF_L_B_ShoulderSeam 513,RF_R_B_ShoulderSeam 514,RF_L_U_ShoulderSeam 515,RF_R_U_ShoulderSeam 516,RF_L_D_ShoulderSeam 517,RF_R_D_ShoulderSeam 518,RF_L_F_U_ShoulderSeam 519,RF_R_F_U_ShoulderSeam 520,RF_L_F_D_ShoulderSeam 521,RF_R_F_D_ShoulderSeam 522,RF_L_B_U_ShoulderSeam 523,RF_R_B_U_ShoulderSeam 524,RF_L_B_D_ShoulderSeam 525,RF_R_B_D_ShoulderSeam 526,SK_INI_FrontSkirt_01 527,RF_FrontSkirt_01 528,SK_INI_FrontSkirt_02 529,RF_FrontSkirt_02 530,RF_B_Collar 531,RF_L_Collar 532,RF_R_Collar 533,RF_L_F_Collar 534,RF_R_F_Collar 535,SK_INI_B_Collar 536,SK_INI_L_Collar 537,SK_INI_R_Collar 538,SK_INI_L_F_Collar 539,SK_INI_R_F_Collar 540,SK_INI_L_FootAdjust 541,SK_INI_R_FootAdjust 542,SK_INI_L_ToesAdjust 543,SK_INI_R_ToesAdjust 544,RF_L_FootAdjust 545,RF_R_FootAdjust 546,RF_L_ToesAdjust 547,RF_R_ToesAdjust 550,CN_L_Contact01 551,CN_L_Contact02 552,CN_R_Contact01 553,CN_R_Contact02 555,SOFT000_ROOT 556,SOFT001_ROOT 557,SOFT002_ROOT 558,SOFT003_ROOT 559,SOFT004_ROOT 560,SOFT005_ROOT 561,SOFT006_ROOT 562,SOFT007_ROOT 565,OPT_ywrk_00 566,OPT_ywrk_01 567,OPT_ywrk_02 568,OPT_ywrk_03 569,OPT_ywrk_04 571,SK_INI_L_ShoulderArmor 572,SK_INI_R_ShoulderArmor 573,RF_L_ShoulderArmor 574,RF_R_ShoulderArmor 575,RF_L_F_ShoulderArmor 576,RF_R_F_ShoulderArmor 577,RF_L_B_ShoulderArmor 578,RF_R_B_ShoulderArmor 799,before_ponytail2_dummy It has the same gaps, so that thing is a bone ID... So, we got wrong a lot of things. If the bone is specified there, then that means that the thigns we thought were bones in sectinon 2, may actually be time stamps. The time stamps for that bone. And that would explain a lot about some of my tests doing weird things, or why all animations looked like they had same number of keyframes regardless of their length, that was obviously bullshit. It also exaplains why you or your friend though that the number of real frames was max bone ID: if the things we thought were bones ID are timesteamps specified as frames, it totally explains it.
Joschuka Posted December 31, 2019 Posted December 31, 2019 14 minutes ago, vagonumero13 said: Ok, I found out from where the gap is. The gap matches the gap in bones of characters. The list of basic body bones in a DOA6 character: Reveal hidden contents 0,root 1,SK_Skeleton 2,SK_Hips 3,SK_L_UpLeg 4,SK_R_UpLeg 5,SK_L_Leg 6,SK_R_Leg 7,SK_L_Foot 8,SK_R_Foot 9,SK_Spine01 10,SK_Spine02 11,SK_Neck 12,SK_Head 13,SK_L_Shoulder 14,SK_R_Shoulder 15,SK_L_Arm 16,SK_R_Arm 17,SK_L_ForeArm 18,SK_R_ForeArm 19,SK_L_Hand 20,SK_R_Hand 21,SK_L_Weapon 22,SK_R_Weapon 23,SK_L_Toes 24,SK_R_Toes 25,SK_Endangle 30,SK_L_Thumb01 31,SK_R_Thumb01 32,SK_L_Index01 33,SK_R_Index01 34,SK_L_Middle01 35,SK_R_Middle01 36,SK_L_PinkySide 37,SK_R_PinkySide 38,SK_L_Thumb02 39,SK_R_Thumb02 40,SK_L_Index02 41,SK_R_Index02 42,SK_L_Middle02 43,SK_R_Middle02 44,SK_L_Ring01 45,SK_R_Ring01 46,SK_L_Pinky01 47,SK_R_Pinky01 48,SK_L_Thumb03 49,SK_R_Thumb03 50,SK_L_Index03 51,SK_R_Index03 52,SK_L_Middle03 53,SK_R_Middle03 54,SK_L_Ring02 55,SK_R_Ring02 56,SK_L_Pinky02 57,SK_R_Pinky02 58,SK_L_Ring03 59,SK_R_Ring03 60,SK_L_Pinky03 61,SK_R_Pinky03 65,RF_L_Arm_00 66,RF_R_Arm_00 67,RF_L_Arm_01 68,RF_R_Arm_01 69,RF_L_Arm_02 70,RF_R_Arm_02 71,RF_L_Elbow_00 72,RF_R_Elbow_00 73,RF_L_ForeArm_00 74,RF_R_ForeArm_00 75,RF_L_ForeArm_01 76,RF_R_ForeArm_01 77,RF_L_UpLeg_00 78,RF_R_UpLeg_00 79,RF_L_UpLeg_01 80,RF_R_UpLeg_01 81,RF_L_UpLeg_02 82,RF_R_UpLeg_02 83,RF_L_Knee_00 84,RF_R_Knee_00 85,RF_L_Leg_00 86,RF_R_Leg_00 87,RF_L_HipBack 88,RF_R_HipBack 89,RF_L_HipOutSide 90,RF_R_HipOutSide 91,RF_L_HipInSide 92,RF_R_HipInSide 120,F_Face 121,F_C_01 122,F_C_02 123,F_C_03 124,F_C_04 125,F_C_05 126,F_C_06 127,F_C_11 128,F_C_12 129,F_C_14 130,F_C_15 131,F_C_16 132,F_C_17 133,F_C_18 134,F_C_19 135,F_C_20 136,F_C_21 137,F_C_22 138,F_C_23 139,F_C_24 140,F_C_25 141,F_C_26 142,F_C_27 143,F_C_30 144,F_C_31 145,F_C_32 146,F_L_22a 147,F_L_22b 148,F_L_22c 149,F_L_23a 150,F_L_23b 151,F_L_23c 152,F_L_24a 153,F_L_24b 154,F_L_24c 155,F_L_25a 156,F_L_25b 157,F_L_25c 158,F_L_26a 159,F_L_26b 160,F_L_26c 161,F_L_26d 162,F_L_26e 163,F_L_26f 164,F_L_26g 165,F_L_27a 166,F_L_27b 167,F_L_27c 168,F_L_27d 169,F_L_27e 170,F_L_27f 171,F_R_22a 172,F_R_22b 173,F_R_22c 174,F_R_23a 175,F_R_23b 176,F_R_23c 177,F_R_24a 178,F_R_24b 179,F_R_24c 180,F_R_25a 181,F_R_25b 182,F_R_25c 183,F_R_26a 184,F_R_26b 185,F_R_26c 186,F_R_26d 187,F_R_26e 188,F_R_26f 189,F_R_26g 190,F_R_27a 191,F_R_27b 192,F_R_27c 193,F_R_27d 194,F_R_27e 195,F_R_27f 196,F_C_28 197,F_L_01a 198,F_L_01b 199,F_L_01c 200,F_L_01d 201,F_L_01e 202,F_L_01f 203,F_L_01g 204,F_L_01h 205,F_L_02a 206,F_L_02b 207,F_L_02c 208,F_L_02d 209,F_L_02e 210,F_L_02f 211,F_L_02g 212,F_L_02h 213,F_L_03a 214,F_L_03b 215,F_L_03c 216,F_L_03d 217,F_L_03e 218,F_L_03f 219,F_L_03g 220,F_L_03h 221,F_L_04a 222,F_L_04b 223,F_L_04c 224,F_L_04d 225,F_L_04e 226,F_L_04f 227,F_L_04g 228,F_L_04h 229,F_L_05a 230,F_L_05b 231,F_L_05c 232,F_L_05d 233,F_L_05e 234,F_L_05f 235,F_L_05g 236,F_L_05h 237,F_L_06a 238,F_L_06b 239,F_L_06c 240,F_L_06d 241,F_L_06e 242,F_L_06f 243,F_L_06g 244,F_L_06h 245,F_L_06i 246,F_L_07a 247,F_L_07b 248,F_L_07c 249,F_L_07d 250,F_L_07e 251,F_L_07f 252,F_L_07g 253,F_L_08a 254,F_L_08b 255,F_L_08c 256,F_L_09a 257,F_L_09b 258,F_L_09c 259,F_L_09d 260,F_L_10a 261,F_L_10b 262,F_L_10c 263,F_L_10d 264,F_L_10e 265,F_L_11a 266,F_L_11b 267,F_L_11c 268,F_L_11d 269,F_L_11e 270,F_L_11f 271,F_L_11g 272,F_L_12a 273,F_L_12b 274,F_L_12c 275,F_L_12d 276,F_L_12e 277,F_L_12f 278,F_L_12g 279,F_L_12h 280,F_L_13a 281,F_L_13b 282,F_L_13c 283,F_L_13d 284,F_L_14a 285,F_L_14b 286,F_L_14c 287,F_L_14d 288,F_L_14e 289,F_L_14f 290,F_L_14g 291,F_L_14h 292,F_L_14i 293,F_L_14j 294,F_L_15a 295,F_L_15b 296,F_L_15c 297,F_L_15d 298,F_L_15e 299,F_L_15f 300,F_L_15g 301,F_L_16a 302,F_L_16b 303,F_L_16c 304,F_L_16d 305,F_L_16e 306,F_L_16f 307,F_L_17a 308,F_L_17b 309,F_L_17c 310,F_L_17d 311,F_L_18a 312,F_L_18b 313,F_L_18c 314,F_L_19a 315,F_L_19b 316,F_L_19c 317,F_L_20a 318,F_L_20b 319,F_L_20c 320,F_L_20d 321,F_L_20e 322,F_L_20f 323,F_L_20g 324,F_L_20h 325,F_L_20i 326,F_L_20j 327,F_L_20k 328,F_L_20l 329,F_L_20m 330,F_L_28a 331,F_R_01a 332,F_R_01b 333,F_R_01c 334,F_R_01d 335,F_R_01e 336,F_R_01f 337,F_R_01g 338,F_R_01h 339,F_R_02a 340,F_R_02b 341,F_R_02c 342,F_R_02d 343,F_R_02e 344,F_R_02f 345,F_R_02g 346,F_R_02h 347,F_R_03a 348,F_R_03b 349,F_R_03c 350,F_R_03d 351,F_R_03e 352,F_R_03f 353,F_R_03g 354,F_R_03h 355,F_R_04a 356,F_R_04b 357,F_R_04c 358,F_R_04d 359,F_R_04e 360,F_R_04f 361,F_R_04g 362,F_R_04h 363,F_R_05a 364,F_R_05b 365,F_R_05c 366,F_R_05d 367,F_R_05e 368,F_R_05f 369,F_R_05g 370,F_R_05h 371,F_R_06a 372,F_R_06b 373,F_R_06c 374,F_R_06d 375,F_R_06e 376,F_R_06f 377,F_R_06g 378,F_R_06h 379,F_R_06i 380,F_R_07a 381,F_R_07b 382,F_R_07c 383,F_R_07d 384,F_R_07e 385,F_R_07f 386,F_R_07g 387,F_R_08a 388,F_R_08b 389,F_R_08c 390,F_R_09a 391,F_R_09b 392,F_R_09c 393,F_R_09d 394,F_R_10a 395,F_R_10b 396,F_R_10c 397,F_R_10d 398,F_R_10e 399,F_R_11a 400,F_R_11b 401,F_R_11c 402,F_R_11d 403,F_R_11e 404,F_R_11f 405,F_R_11g 406,F_R_12a 407,F_R_12b 408,F_R_12c 409,F_R_12d 410,F_R_12e 411,F_R_12f 412,F_R_12g 413,F_R_12h 414,F_R_13a 415,F_R_13b 416,F_R_13c 417,F_R_13d 418,F_R_14a 419,F_R_14b 420,F_R_14c 421,F_R_14d 422,F_R_14e 423,F_R_14f 424,F_R_14g 425,F_R_14h 426,F_R_14i 427,F_R_14j 428,F_R_15a 429,F_R_15b 430,F_R_15c 431,F_R_15d 432,F_R_15e 433,F_R_15f 434,F_R_15g 435,F_R_16a 436,F_R_16b 437,F_R_16c 438,F_R_16d 439,F_R_16e 440,F_R_16f 441,F_R_17a 442,F_R_17b 443,F_R_17c 444,F_R_17d 445,F_R_18a 446,F_R_18b 447,F_R_18c 448,F_R_19a 449,F_R_19b 450,F_R_19c 451,F_R_20a 452,F_R_20b 453,F_R_20c 454,F_R_20d 455,F_R_20e 456,F_R_20f 457,F_R_20g 458,F_R_20h 459,F_R_20i 460,F_R_20j 461,F_R_20k 462,F_R_20l 463,F_R_20m 464,F_R_28a 500,RF_L_ForeArmNoTwist 501,RF_R_ForeArmNoTwist 502,RF_L_HandNoTwist 503,RF_R_HandNoTwist 504,RF_L_ElbowNoTwist 505,RF_R_ElbowNoTwist 506,RF_L_LegNoTwist 507,RF_R_LegNoTwist 508,RF_L_KneeNoTwist 509,RF_R_KneeNoTwist 510,RF_L_F_ShoulderSeam 511,RF_R_F_ShoulderSeam 512,RF_L_B_ShoulderSeam 513,RF_R_B_ShoulderSeam 514,RF_L_U_ShoulderSeam 515,RF_R_U_ShoulderSeam 516,RF_L_D_ShoulderSeam 517,RF_R_D_ShoulderSeam 518,RF_L_F_U_ShoulderSeam 519,RF_R_F_U_ShoulderSeam 520,RF_L_F_D_ShoulderSeam 521,RF_R_F_D_ShoulderSeam 522,RF_L_B_U_ShoulderSeam 523,RF_R_B_U_ShoulderSeam 524,RF_L_B_D_ShoulderSeam 525,RF_R_B_D_ShoulderSeam 526,SK_INI_FrontSkirt_01 527,RF_FrontSkirt_01 528,SK_INI_FrontSkirt_02 529,RF_FrontSkirt_02 530,RF_B_Collar 531,RF_L_Collar 532,RF_R_Collar 533,RF_L_F_Collar 534,RF_R_F_Collar 535,SK_INI_B_Collar 536,SK_INI_L_Collar 537,SK_INI_R_Collar 538,SK_INI_L_F_Collar 539,SK_INI_R_F_Collar 540,SK_INI_L_FootAdjust 541,SK_INI_R_FootAdjust 542,SK_INI_L_ToesAdjust 543,SK_INI_R_ToesAdjust 544,RF_L_FootAdjust 545,RF_R_FootAdjust 546,RF_L_ToesAdjust 547,RF_R_ToesAdjust 550,CN_L_Contact01 551,CN_L_Contact02 552,CN_R_Contact01 553,CN_R_Contact02 555,SOFT000_ROOT 556,SOFT001_ROOT 557,SOFT002_ROOT 558,SOFT003_ROOT 559,SOFT004_ROOT 560,SOFT005_ROOT 561,SOFT006_ROOT 562,SOFT007_ROOT 565,OPT_ywrk_00 566,OPT_ywrk_01 567,OPT_ywrk_02 568,OPT_ywrk_03 569,OPT_ywrk_04 571,SK_INI_L_ShoulderArmor 572,SK_INI_R_ShoulderArmor 573,RF_L_ShoulderArmor 574,RF_R_ShoulderArmor 575,RF_L_F_ShoulderArmor 576,RF_R_F_ShoulderArmor 577,RF_L_B_ShoulderArmor 578,RF_R_B_ShoulderArmor 799,before_ponytail2_dummy It has the same gaps, so that thing is a bone ID... So, we got wrong a lot of things. If the bone is specified there, then that means that the thigns we thought were bones in sectinon 2, may actually be time stamps. The time stamps for that bone. And that would explain a lot about some of my tests doing weird things, or why all animations looked like they had same number of keyframes regardless of their length, that was obviously bullshit. Omg, back to the drawing board I guess. Wait you have some bone names in DOA6 ? Unless I missed something obvious they don't seem to be any in FE.
vagonumero13 Posted December 31, 2019 Author Posted December 31, 2019 5 minutes ago, Joschuka said: Omg, back to the drawing board I guess. Wait you have some bone names in DOA6 ? Unless I missed something obvious they don't seem to be any in FE. The bone names were present only until 1.06 update. They were stored in separate file with .oid extension. Theere are now hashes only in the .oid file, but since I know the hashing algorithm, I can translate them back with string cracking. Anyway, I still got the old files that had these (in fact, qrdbtool can recover almost all old DOA6 files due to how packaging works in this game). The bone names actually miss some specific bones, like bones >= 800, some of which are specific for soem characters or for some costumes. But it looks like all animations are just using bone 1-61, so the basic of basic bones.
Joschuka Posted December 31, 2019 Posted December 31, 2019 1 hour ago, vagonumero13 said: The bone names were present only until 1.06 update. They were stored in separate file with .oid extension. Theere are now hashes only in the .oid file, but since I know the hashing algorithm, I can translate them back with string cracking. Anyway, I still got the old files that had these (in fact, qrdbtool can recover almost all old DOA6 files due to how packaging works in this game). The bone names actually miss some specific bones, like bones >= 800, some of which are specific for soem characters or for some costumes. But it looks like all animations are just using bone 1-61, so the basic of basic bones. Ah ok I see. Back to g2a it's beginning to make some sense : -num_splines would actually be the number of channels for the bone (rotation, translation, scale etc) -next_header_offset divided by 4 would be the bone ID -data_offset is the offset of the timing info for the above bone, divided by 4 or not depending of the version it seems section 2, what we called splines before: -type : channel type -bone_count : it's actually the number of keyframes in the channel for the bone -first matrix is the one of the first keyframe, next ones being for the next keyframes -the bone_ID would be the keyframes' values, in frames probably section 3 would be the transform matrices according to your translation experiment. Overall it'd make some sense, I'll update the BT
vagonumero13 Posted December 31, 2019 Author Posted December 31, 2019 7 hours ago, Joschuka said: Ah ok I see. Back to g2a it's beginning to make some sense : -num_splines would actually be the number of channels for the bone (rotation, translation, scale etc) -next_header_offset divided by 4 would be the bone ID -data_offset is the offset of the timing info for the above bone, divided by 4 or not depending of the version it seems section 2, what we called splines before: -type : channel type -bone_count : it's actually the number of keyframes in the channel for the bone -first matrix is the one of the first keyframe, next ones being for the next keyframes -the bone_ID would be the keyframes' values, in frames probably section 3 would be the transform matrices according to your translation experiment. Overall it'd make some sense, I'll update the BT I have some doubts about the format of the matrix. There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, there is probably some hardcore optimization going on there, because the 32 bytes are loaded as 4 64 bits values), and it creates 3 float values from it. This function is called for the three opcodes 0, 1 and 2. But for opcode 0, those 3 values are then passed to a second function that transforms those 3 floats into 4 floats (maybe a quaternion).
Joschuka Posted January 1, 2020 Posted January 1, 2020 15 hours ago, vagonumero13 said: I have some doubts about the format of the matrix. There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, there is probably some hardcore optimization going on there, because the 32 bytes are loaded as 4 64 bits values), and it creates 3 float values from it. This function is called for the three opcodes 0, 1 and 2. But for opcode 0, those 3 values are then passed to a second function that transforms those 3 floats into 4 floats (maybe a quaternion). That'd make sense, as I said above that was weird to store transform matrices which are supposed to be the result of all transform when they have explicit info on which transform is happening thanks to the opcode. So we'd have a quaternion for the rotation and a scale/translation vector for opcodes 2 and 1 respectively. Ok that computation seems a bit weird indeed, Maybe they store some interpolation information info or something like that here too cause it doesn't to be anywhere else Btw the 20 bits "bone_timing_data_offset" doesn't seem to match for Dissidia NT's g2a files so it may be something else. Everything else seem correct on these. Could you share the code parts in PM please ? I'd like to take a look at them
vagonumero13 Posted January 1, 2020 Author Posted January 1, 2020 54 minutes ago, Joschuka said: That'd make sense, as I said above that was weird to store transform matrices which are supposed to be the result of all transform when they have explicit info on which transform is happening thanks to the opcode. So we'd have a quaternion for the rotation and a scale/translation vector for opcodes 2 and 1 respectively. Ok that computation seems a bit weird indeed, Maybe they store some interpolation information info or something like that here too cause it doesn't to be anywhere else Btw the 20 bits "bone_timing_data_offset" doesn't seem to match for Dissidia NT's g2a files so it may be something else. Everything else seem correct on these. Could you share the code parts in PM please ? I'd like to take a look at them I haven't really written new code yet, I still have the old parse code, I need to correct it. About the matrix, this is what I could gather after some look (some of it may be incorrect). It is not a 4x4 matrix. It is a 4x3 matrix, or just 4 vectors of 3 components each one. They aren't in standard float formats. Each vector is 64 bits, where each component has 20 bits. The remaining bits (bits 59-63) seem to be a shared exponent for all the components (or something like that). That number is shifted << 23 (which matches float32 exponent) and added number 0x32000000 (which is float32 exponent 100). The 3 components are shifted 12 bits to the left. Let's call each of these vectors X, Y, Z and W The returned value is something more or less like this (this is where I may have some incorrect part). returned X = X1 + Y1 + Z1 + W1 returned Y = X2 + Y2 + Z2 + W2 returned Z = X3 + Y3 + Z3 + W3 But well, there is more to this, the function that does these things is passed two additional parameters, both of which seem to be calculated from the frame timer (and maybe duration too, duration beign next frame timer - current frame timer), and number 65536.0 is used there, but I have to look better to that. The thing is that all returned values are actually multiplied with those values in different ways, so the above thing was just a simplification ignoring those parameters.
Joschuka Posted January 1, 2020 Posted January 1, 2020 1 hour ago, vagonumero13 said: I haven't really written new code yet, I still have the old parse code, I need to correct it. About the matrix, this is what I could gather after some look (some of it may be incorrect). It is not a 4x4 matrix. It is a 4x3 matrix, or just 4 vectors of 3 components each one. They aren't in standard float formats. Each vector is 64 bits, where each component has 20 bits. The remaining bits (bits 59-63) seem to be a shared exponent for all the components (or something like that). That number is shifted << 23 (which matches float32 exponent) and added number 0x32000000 (which is float32 exponent 100). The 3 components are shifted 12 bits to the left. Let's call each of these vectors X, Y, Z and W The returned value is something more or less like this (this is where I may have some incorrect part). returned X = X1 + Y1 + Z1 + W1 returned Y = X2 + Y2 + Z2 + W2 returned Z = X3 + Y3 + Z3 + W3 But well, there is more to this, the function that does these things is passed two additional parameters, both of which seem to be calculated from the frame timer (and maybe duration too, duration beign next frame timer - current frame timer), and number 65536.0 is used there, but I have to look better to that. The thing is that all returned values are actually multiplied with those values in different ways, so the above thing was just a simplification ignoring those parameters. Ah I was more talking aboout the code you referred to in that sentence " There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, ". I didn't start working on my G2A parser either, I will soon after cleaning my NUNO sections. Great progress ! I'll update the BT accordingly soon. About the 2nd function that would change 3 floats into 4 (for the rotation supposedly), my partner who worked on OW before saw something similar : https://github.com/overtools/OWLib/blob/develop/TankLib/teAnimation.cs#L234
Boliu Posted January 1, 2020 Posted January 1, 2020 @vagonumero13 Hello, can you tell me what tools did you use to make stage mods?
vagonumero13 Posted January 1, 2020 Author Posted January 1, 2020 3 hours ago, Boliu said: @vagonumero13 Hello, can you tell me what tools did you use to make stage mods? There are no tools to create stage mods. All current stage mods consist in replacing the motor kidsobjdb of the stage with the one of another. This usually causes the stage to get some characteristics of that other stage, such as snow, day time, etc. And then, there is the story mode stages mods, those just instruct REDELBE to make the game load those story mode stages.
vagonumero13 Posted January 1, 2020 Author Posted January 1, 2020 7 hours ago, Joschuka said: Ah I was more talking aboout the code you referred to in that sentence " There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, ". I didn't start working on my G2A parser either, I will soon after cleaning my NUNO sections. Great progress ! I'll update the BT accordingly soon. About the 2nd function that would change 3 floats into 4 (for the rotation supposedly), my partner who worked on OW before saw something similar : https://github.com/overtools/OWLib/blob/develop/TankLib/teAnimation.cs#L234 Well, the function I talked about was a function in the game. It is this function (horrible IDA decompiled code right ahead): Spoiler signed __int64 __fastcall sub_140A605D0(__int64 a1, __int64 a2, float a3, float a4) { __int64 v4; // r9@1 float v5; // xmm2_4@1 float v6; // xmm7_4@1 float v7; // xmm1_4@1 float v8; // xmm3_4@1 float v9; // xmm5_4@1 float v10; // xmm0_4@1 float v11; // xmm1_4@1 float v12; // xmm6_4@1 float v13; // xmm5_4@1 float v14; // xmm6_4@1 signed __int64 result; // rax@1 unsigned int v16; // ecx@1 float v17; // [sp+40h] [bp+18h]@1 float v18; // [sp+40h] [bp+18h]@1 v4 = a1; LODWORD(v17) = ((*(_QWORD *)a2 >> 37) & 0x7800000) + 0x32000000; v5 = a3 / a4; v6 = (float)(v5 * v5) * v5; LODWORD(v7) = ((*(_QWORD *)(a2 + ? >> 37) & 0x7800000) + 0x32000000; v8 = (float)((float)(signed int)((*(_QWORD *)a2 >> 28) & 0xFFFFF000) * v17) + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + ? >> 28) & 0xFFFFF000) * v7) * v5); v9 = (float)((float)(signed int)((*(_QWORD *)a2 >> ? & 0xFFFFF000) * v17) + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + ? >> ? & 0xFFFFF000) * v7) * v5); v10 = (float)(signed int)(((unsigned int)*(_QWORD *)(a2 + ? << 12) & 0xFFFFF000) * v7; LODWORD(v11) = ((*(_QWORD *)(a2 + 0x10) >> 37) & 0x7800000) + 0x32000000; v12 = (float)((float)(signed int)(((unsigned int)*(_QWORD *)a2 << 12) & 0xFFFFF000) * v17) + (float)(v10 * v5); v13 = v9 + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + 0x10) >> ? & 0xFFFFF000) * v11) * (float)(v5 * v5)); LODWORD(v18) = ((*(_QWORD *)(a2 + 0x18) >> 37) & 0x7800000) + 0x32000000; v14 = v12 + (float)((float)((float)(signed int)(((unsigned int)*(_QWORD *)(a2 + 0x10) << 12) & 0xFFFFF000) * v11) * (float)(v5 * v5)); result = (*(_QWORD *)(a2 + 0x18) >> ? & 0xFFFFF000i64; v16 = ((unsigned int)*(_QWORD *)(a2 + 0x18) << 12) & 0xFFFFF000; *(float *)v4 = (float)((float)((float)(signed int)((*(_QWORD *)(a2 + 0x18) >> 28) & 0xFFFFF000) * v18) * v6) + (float)(v8 + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + 0x10) >> 28) & 0xFFFFF000) * v11) * (float)(v5 * v5))); *(float *)(v4 + 4) = (float)((float)((float)(signed int)result * v18) * v6) + v13; *(float *)(v4 + ? = (float)((float)((float)(signed int)v16 * v18) * v6) + v14; return result; } Some tips to undersrand the code: - The function is actually a void - a1 is actually the "float *" where x, y and z are returned. - a2 is what we thought it was a matrix. (type should be uint64_t *, or QWORD *). - (x >> 37) & 0x7800000 -> is equivalent to getting bits 63-60 and shifting them << 23. - (x >> 28) & 0xFFFFF000 -> is equivalent to getting bits 40-59 and shifting them << 12. - (x >> 8 ) & 0xFFFFF000 -> is equivalent to getting bits 20-39 and shifting them << 12. - (x << 12) & 0xFFFFF000 -> is equivalent to getting bits 0-19 and shifting them << 12. I will do a proper manual decompilation of that functon to get more quality code. In a "matrix" with following binary data: Spoiler 01E1DF51582FFF3F993D200DFFFD4B00722BD0C800DBED0F77E6EF8AFF14F70F The results were as following. The function is actually called N times, where N is the duration of the frame (e.g. next time stamp - current time stamp.) Current time stamp was 0, next time stamp was 18. Spoiler (0) 0.000000 1179648.000000 - -0.051025 88.319580 -1.937256 (1) 65536.000000 1179648.000000 - -0.018494 88.313286 -1.909507 (2) 131072.000000 1179648.000000 - 0.013091 88.307541 -1.879869 (3) 196608.000000 1179648.000000 - 0.043657 88.302269 -1.848546 (4) 262144.000000 1179648.000000 - 0.073134 88.297447 -1.815743 (5) 327680.000000 1179648.000000 - 0.101448 88.292976 -1.781667 (6) 393216.000000 1179648.000000 - 0.128529 88.288826 -1.746521 (7) 458752.000000 1179648.000000 - 0.154304 88.284927 -1.710512 (8) 524288.000000 1179648.000000 - 0.178703 88.281227 -1.673844 (9) 589824.000000 1179648.000000 - 0.201653 88.277649 -1.636723 (10) 655360.000000 1179648.000000 - 0.223082 88.274155 -1.599354 (11) 720896.000000 1179648.000000 - 0.242919 88.270676 -1.561942 (12) 786432.000000 1179648.000000 - 0.261093 88.267151 -1.524692 (13) 851968.000000 1179648.000000 - 0.277530 88.263535 -1.487810 (14) 917504.000000 1179648.000000 - 0.292161 88.259750 -1.451502 (15) 983040.000000 1179648.000000 - 0.304913 88.255753 -1.415971 (16) 1048576.000000 1179648.000000 - 0.315714 88.251472 -1.381424 (17) 1114112.000000 1179648.000000 - 0.324492 88.246864 -1.348066 The two float numbers at left are the parameters a3 and a4 (input). The 3 number at the right (after the -) are the returned x, y, z values. It looks like the parameter a3 is just 65536.0*frame, and parameter a4 is the final time stamp (in this case 18*65536.0) Btw, the example was of a translation.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now