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

STD ins_14 in UFO through TD is wrong (probably) #1

Open
ExpHP opened this issue Apr 12, 2021 · 0 comments
Open

STD ins_14 in UFO through TD is wrong (probably) #1

ExpHP opened this issue Apr 12, 2021 · 0 comments

Comments

@ExpHP
Copy link
Owner

ExpHP commented Apr 12, 2021

According to my website, ins_14 in STD gains a third argument in UFO, which holds the layer.

STD_BY_OPCODE.set('12', {
  ...STD_BY_OPCODE.get('11'),
  14: {ref: 'std:sprite-3arg'}, // signature change!
  18: {ref: 'std:up-time'},
});

Yet, trustd's core mapfiles have been decompiling this using a signature of SS without issue:

$ for x in ~/thcrap/decomp/bleh12/*.std; do TRUTH_MAP_PATH= target/release/trustd d --game 12 $x | grep ins_14; done
warning: /home/exp/thcrap/decomp/bleh12/stage02.std: object at index 2: object has non-sequential id (expected 2, got 1)

    ins_14(0, 4);
    ins_14(1, 5);
    ins_14(2, 6);
    ins_14(3, 7);
warning: /home/exp/thcrap/decomp/bleh12/stage07.std: object at index 2: object has non-sequential id (expected 2, got 1)

truth would warn if there were leftover bytes in the instruction, so clearly SS is correct. Where did SSS come from? Is this what it changes to in th14 maybe?

@ExpHP ExpHP changed the title Look into reasoning behind signature change in UFO STD ins_14 STD ins_14 in UFO through TD is wrong (probably) Apr 12, 2021
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

No branches or pull requests

1 participant