Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thstd: fix crashes with some pre-th10 stages #80

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Nutzer
Copy link
Contributor

@Nutzer Nutzer commented Jul 23, 2020

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.

@ExpHP
Copy link
Contributor

ExpHP commented Sep 1, 2020

What's holding this PR back?

@ExpHP
Copy link
Contributor

ExpHP commented Sep 1, 2020

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
Copy link
Contributor

ExpHP commented Sep 4, 2020

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:

Priw8 added a commit that referenced this pull request Oct 12, 2020
Turns out they are different: #80 (comment)
Priw8 added a commit that referenced this pull request Oct 12, 2020
Simply added changes from here: #80 (comment)
@Priw8
Copy link
Member

Priw8 commented Oct 12, 2020

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?

@DankRank DankRank added this to the thtk-13 milestone Apr 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants