jak-project
jak-project copied to clipboard
open-goal
[decompiler] investigate the stack casts added in #1847
https://github.com/open-goal/jak-project/pull/1847 adds quite a few stack casts. Some of these do seem impossible to guess, the majority seem like they could be guessed at a first glance.
We should understand why so many of these are required, and if these same causes will show up often in gameplay code. If so, it's probably worth putting a decent amount of time into automating these as it seems like one of the most time consuming parts of decompiling gameplay code - maybe @xTVaser can comment on this and let me know if there's something worse that's not covered by existing issues.
Also https://github.com/open-goal/jak-project/pull/1842 adds some casts and this is mostly gameplay code
I know that a good amount of them were added due to https://github.com/open-goal/jak-project/issues/1849 so I could actually work through the file properly. So that should mean less casts are required in the future for that reason.
Other than that, stack casts have felt ok in terms of quantity -- In that PR in particular the more annoying standout was all of the manual type-casts to editable or editable sub-types, especially after type? checks.
Imo it might be a bit too early to tell which are the low-hanging fruit -- we have all of the data in JSON so maybe we should graph the data overtime and when something being an outlier look into it?
I had to add a bunch of stack casts that I feel should have been guessable in loader.
Thanks, that's good to know.
the ones in airlock seem to mostly be https://github.com/open-goal/jak-project/issues/1821 so that seems promising.
The type? stuff is going to be hard to do (see https://github.com/open-goal/jak-project/issues/1818). I'm not against doing it eventually, but I think it's lower priority compared to the other open issues.
I had to add a bunch of stack casts that I feel should have been guessable in loader.
Which ones in loader? At first glance I only see 2 stack structures there
"(method 13 gui-control)": [[16, ["array", "sound-id", 4]]],
"ja-play-spooled-anim": [[96, "event-message-block"]],
and it seems like the first is hard to guess, and the second can be removed and it still decompiles.
Oh sorry, it was joint-mod and chain-physics. Look at joint-mod-ik-callback.
ah that makes a lot of sense. At first glance a lot of those seem to be either stack variable related, or vector where they just store values in it without every passing it to a function (or where the decompiler can't get far enough to see the function its used in). Both of those are probably worth looking into more.
Another one is s5 in traj3d-calc-initial-velocity-using-tilt - this is a case where I'd expect the type stuff to figure it out from the later function call, but apparently it doesn't.