thtk icon indicating copy to clipboard operation
thtk copied to clipboard

thstd: fix crashes with some pre-th10 stages

Open Nutzer opened this issue 3 years ago • 4 comments

This should fix all the crashes that appear in pre-th10 std scripts. There are some quads in there that have a size of 36 instead of 28, which messed up the calculation.

Nutzer avatar Jul 23 '20 21:07 Nutzer

What's holding this PR back?

ExpHP avatar Sep 01 '20 17:09 ExpHP

Also, just a random note, EoSD instructions are different from games after it (but that could be fixed later).

EoSD signatures: (_ means unused, could just put S):

0 fff
1 Cff
2 fff
3 S__
4 S__
5 ___

(there's only 6 instructions)

This is in contrast to PCB where the first 6 instructions are:

0 fff
1 Cff
2 S__
3 ___
4 ot_  (not exactly same as 'o' normally works, it counts instrs and not bytes)
5 fff

This is mostly a problem for instruction 2.


P.S. my take on the rest of instructions up to PoFV:

PCB-PoFV STD signatures
 0 fff
 1 Cff
 2 S__
 3 ___
 4 ot_  (not exactly same as 'o' normally works, it counts instrs and not bytes)
 5 fff
 6 SS_
 7 fff
 8 SS_
 9 fff
10 SS_
11 f__
12 SS_
13 C__
14 fff
15 fff
16 fff
17 fff
18 S__
19 fff
20 fff
21 fff
22 fff
23 S__
24 fff
25 fff
26 fff
27 fff
28 S__
29 S__
30 S__
31 S__ (not in jumptable, it's an interrupt label)
32 fff  (added in IN)
33 S__  (added in IN)
34 S__  (added in IN)

ExpHP avatar Sep 01 '20 17:09 ExpHP

So I tried this commit. (had to rebase it onto thanm-new-spec-format to fix WSL compilation issues) Seems to decompile and recompile IN fine. The output is not bit-for-bit identical to the original but the game seems to play fine. PCB and PoFV also decompile.


Tried decompiling StB but got lots of segfaults.

Edit: StB fix is simple

diff --git a/thstd/thstd.c b/thstd/thstd.c
index 64d6083..33f5cde 100644
--- a/thstd/thstd.c
+++ b/thstd/thstd.c
@@ -94,6 +94,7 @@ static const id_format_pair_t formats_v1[] = {
     { 8, "Cff" },
     { 9, "SSCff" },
     { 10, "SSfffffffff" },
+    { 11, "SSfffffffff" },
     { 12, "S" },
     { 13, "S" },
     { 14, "SS" },
@@ -865,9 +866,9 @@ main(
     case 7:
     case 8:
     case 9:
-    case 95:
         option_version = 0;
         break;
+    case 95:
     case 10:
     case 103:
     case 11:

ExpHP avatar Sep 04 '20 04:09 ExpHP

I merged the branch from @Nutzer's fork into this branch instead of master to fix things that @ExpHP mentioned. I also investigated the reason why recompiled files are not bit-for-bit identical, and it's actually pretty silly. It occurs in 2 cases:

  • the 1st case is when "weird" floats are used, and by that I mean ugly values such as -81.6021957397461. Since the %g format is used to print the float into the decompiled file, it turns into a -81.6022. But then when recompiling, it becomes -81.6022033691406, which is... very slightly different.
  • the 2nd case is related to how std_object_instances (FACE in dumps) are stored in the compiled .std file. For example, in th08 stage4b.std they don't have any specific order in which they appear in the file; however, the dump format requires the instances to be placed next to objects (ENTRY in dumps) they reference, so the order gets lost. Then, when recompiling, instances end up being sorted by object_id instead of having the original order.

Both of these issues don't affect how the actual stage background looks ingame (okay, the 1st one theoretically could change it VERY slightly), so I don't see the need to fix it, unless we want bit-for-bit perfect output that much?

Priw8 avatar Oct 12 '20 17:10 Priw8