N64Recomp / N64Recomp

Tool to statically recompile N64 games into native executables

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proper way to deal star fox 64 style overlays?

lizardman0 opened this issue · comments

Hi, as mentioned on #66 sf64 has a bunch of overlays that map to the same vram address https://github.com/sonicdcer/sf64/blob/master/yamls/us/rev1/overlays.yaml

It seems that the main problem is not even the overlapping addresses but the fact that there's no way to tell N64Recomp to use dynamic LOOKUP_FUNCTION macros instead of fixed ones for targets inside overlays. I known that it's possible to specify relocatable symbols but that's not the same situation right?

As a workaround, I made a quick and dirty script to replace(directly on the generated .c files) all the wrongly resolved functions with dynamic LOOKUP_FUNCTION and it seemed to work (game booted, and I even tested two levels).

In summary, does it make sense to add a way to specify overlay sections and force N64Recomp to output LOOKUP macros when the jump target is in an overlay section AND the current position is not in the same section?

N64Recomp emitting fixed function calls instead of LOOKUP_FUNCTION happens because the recompiler doesn't know how to handle those overlapping segments yet. It will be fixed when we add overlapping segments support.

And more specifically, there's actually no need to call LOOKUP_FUNCTION for most cases with overlapping addresses. For example if a jal is in section 3 and the one of the target functions is also in section 3, then the recompiler just has to emit the function call to that function in section 3 since it's unambiguous. It's a very small change, I'm just in the middle of a refactor to clean up the instruction handling at the moment so it'll probably have to wait until after that's done.

Thanks for the quick answer! It makes sense

For example if a jal is in section 3 and the one of the target functions is also in section 3, then the recompiler just has to emit the function call to that function in section 3 since it's unambiguous.

Nice, that's exactly what I did. Only calls the "crossed" sections were replaced. The dump functionality hidden in the main really helped with this.