mirror of
https://github.com/Xeeynamo/sotn-decomp.git
synced 2024-11-26 22:40:33 +00:00
3464bb705a
This has been one of the most weird functions I ever decompiled. I will share a few tricks I learnt. In short, I tried inlining as much as possible by removing all the temps. --- ```c switch (self->step) { ... case 2: isEntityAlive = 0; if (self->step != 2) { return; } ``` This was the output from M2C. As there is no way that `self->step` is different than `2`, deleting had no effect on the matching. --- ```c var_v0 = self->step; switch (var_v0) { case 1: ... if (statement) { self->step++; } ... D_SOME_VARIABLE = var_v0; } ``` This was another very weird one. I couldn't understand why `D_SOME_VARIABLE` was assigned that way much further down the `case 1`. The way I fixed it is that `var_v0` was always `1` due to `case 1:`. By doing `D_SOME_VARIABLE = 1` I got a match. --- ```c temp_a0_2 = D_80174C2C + 1; ... D_80174C2C = temp_a0_2 & -(temp_a0_2 < 0x10); ``` To understand this madness I used a random C compiler I found online and tested in a `for` loop what's the output for all the given `temp_a0_2`. It seemed the value never changed but over `16` the value was always 0. I logically re-written that statement into something that made logically more sense for me and it matched, even if it looks very different from the original: ```c D_80174C2C++; D_80174C2C = D_80174C2C >= 16 ? 0 : D_80174C2C; ``` |
||
---|---|---|
.. | ||
asm-differ@6d3e4c44d1 | ||
dups | ||
function_finder | ||
gfxsotn | ||
lints/sotn-lint | ||
m2c@0813874880 | ||
maspsx@ae43f009e3 | ||
n64splat@8acd2fad74 | ||
saturn-splitter@8d549a8042 | ||
sotn-debugmodule | ||
sotn-disk | ||
splat_ext | ||
split_jpt_yaml | ||
vab-ex | ||
analyze_calls.py | ||
bin2c.py | ||
decompile.py | ||
gfxstage.py | ||
m2ctx.py | ||
permuter_settings.toml | ||
png2bin.py | ||
progress.py | ||
requirements-debian.txt | ||
requirements-python.txt | ||
richter_symbols.py | ||
sotn-str.py | ||
spritesheet.py | ||
symbols_test.py | ||
symbols.py | ||
tools.mk | ||
update.h |