Based on Sozud's scratch (https://decomp.me/scratch/zVBXP), I got the
function to match, and then confirmed that it also matches on PSX.
I also discovered a few improvements, especially in changing
`D_8016FCC0[entityId];` to instead be
`((PfnEntityUpdate*)FAMILIAR_PTR)[entity->entityId - 0xD0];`
While I was at it, I also updated the D_80170000 variable from a void*
to be g_ServantDesc, just like we have in the servant overlay. The
ServantDesc struct only exists in servant.h, so we update that as well.
Finally, we move g_Weapon to not be at 80170000, since it doesn't belong
there.
As noted in the comment, this is closely related to BottomCornerText,
which exists in the overlays. It shows the text boxes in the lower left
and lower right corners of the screen (an item you picked up, an enemy
you encountered, etc).
I'm not sure how this is triggered in relation to food (I'll see when I
decompile the caller), but there it is. The logic is weird since it
parses characters two at a time.
I tried to make a symbol definition for this function, but it didn't
work. Leaving my attempt in place to show what I did; I can remove it if
desired, or do whatever is needed to rename functions in the weapon
overlays. Anything works.
## What is this
Required for #465 . I re-wrote how the build process works for the
`BIN/WEAPON0.BIN` ~~overlay~~ file.
## A bit of a background
On the PSP build I found `WEAPON0.BIN` is just a blob with `f0_000.bin`,
`w0_000.bin`, `f0_001.bin` and so on concatenated as a single file. `f0`
contains the graphics (or CHR) and `w0` contains the actual overlay (or
PRG). The individual overlays share a great amount of functions I
documented in `config/symbols.us.weapon.txt`.
## The problem
Splat creates its own `weapon.ld` linker script, insisting to link all
the overlays as a single binary file. While this is not technically
correct, it creates a bigger problem: symbols cannot be shared. In 58
overlays there are 58 `DestroyEntity`. Other decomps are
circumnavigating the issue by adding a prefix. Following the same
pattern we could have `W000_DestroyEntity`, `W001_DestroyEntity` and so
on. But this is not maintainable and it does not reflect our long-term
vision of having shared code between overlays.
## The solution
I created the dedicated linker script `weapon0.ld` to output the
individual overlay `w0_000.bin` and similar. `f0_000.bin` is also
created from the correspondent PNG. Once all the overlays and graphics
are created I am simply concatenating them back to `WEAPON0.BIN`. This
is much more efficient in terms of separation of concerns,
maintainability, build speed and it also allows to use the same symbol
names across overlays. Also very important, the generated individual
overlays matches the structure of what is found in the PSP build.
## Side note
I thought it was wise to prepare the Makefile and the linker script to
also allow rebasing and compiling for WEAPON1.BIN. The generated file
does not currently match and it will probably need a bit more research.
I left the build infrastructure there. To compile the non-matching
WEAPON1 just modify `$(BUILD_DIR)/WEAPON0.BIN: $(WEAPON0_FILES)` to
`$(BUILD_DIR)/WEAPON0.BIN: $(WEAPON0_FILES) $(WEAPON1_FILES)`.
Splits `BIN/WEAPON0.BIN` in its own individual C files and assets. There
are 59 overlays 59 PNGs extracted as part of it. The `.data`, `.text`
and `.sbss` section are correctly split. I did not yet split the
`.rodata` but I assume it will be so small we can do it on-the-go.
This is fully integrated in the build process, it gives an 🆗 once
built back and it is fully integrated in the CI. We did not yet know how
weapons work in-game and we already have a few instances in the code
where we call `D_8017A000();` and similar. I think it is time to start
documenting them.
Thanks to @bismurphy <bismurphy@users.noreply.github.com> for addressing `analyze_calls.py` for this specific
PR.
