Matches 72% of the entire overlay in one go. Around 80% of the overlay
code is made of duplicate function.
A few observations:
* `func_us_8018AC0C` seems to be an older, buggy version of
`func_801B246C` and it seem to indicate `ObjInit2` was either a `u16`
array or there were macros involved.
* `e_breakable` is the same function, but the data changes in most
overlays; I had to pull the data out. The SFX ID is also different.
Data handled through the asset manager and BSS will come as part of a
separate PR.
Extract ST/WRP out of #1119 . All the function symbols should have been
cross-referenced. There as some PSX functions missing from PSP and some
new functions from PSP that are not present on PSX (e.g.
`st_init_wrp.c`).
The files `st_debug.c` and `e_breakable.c` are shared between WRP PSX
and WRP PSP. Everything else from PSP is isolated into its own folder. I
had to do some tricks on the YAML config to allow shared code.
`ST_WRP_MERGE = st_debug e_breakable` in the `Makefile` is a bit
annoying as MWCC complains about every single minute detail from the C
source that has been already decompiled for the PSX US build.
`EntityWarpSmallRocks` is matching on PSP but I couldn't extract the
rodata without having a bunch of linker errors. This might be a Splat
issue. I need to investigate further.
`func_psp_09244760` is soooo interesting. The values from `0x11` to
`0x17` matches the Entity IDs that are unique to the WRP overlay. This
aligns to what we have in `typedef enum EntityIDs`.
Overall I am very excited to the recent discoveries from the PSP build!
OK. Here goes. Version 0.0.1 alpha of the MWCC Global Assembly Processor
(mwccgap). It's currently very simple/limited, but it appears to work
for `src/servant/tt_000/10E8.c`.
There is lot more that can be done to improve mwccgap - i.e. supporting
.rodata migration would be a good addition, but let's see how far we can
get with it in it's current state.
Note that the Makefile could do with some improvements - we don't nede
to use mwccgap for any C file that *dont* have INCLUDE_ASM macros (it's
a waste of time) so these could be ignored, i.e. for SSSV I do something
like this to find the files that need fixing up:
```
GLOBAL_ASM_C_FILES := $(shell $(GREP) GLOBAL_ASM $(SRC_DIR) </dev/null 2>/dev/null)
```
.. although this is perhaps too simple given that SOTN has a mix of PSP
and PSX functions (and therefore there may be INCLUDE_ASM for a PSX
function but none for PSP functions...
Matches w_000, effectively opening the doors to understand how hand
equippables work. That includes weapons, shields, consumable; all of
them internally named as Weapons). This overlay is used by:
* Tyrfing
* Namakura
* Gladius
* Scimitar
* Cutlass
* Saber
* Falchion
* Broadsword
* Bekatowa
* Damascus sword
* Hunter sword
* Bastard sword
* Talwar
* Sword of Hador
* Luminus
* Harper
* Gram
* Mormegil
* Terminus Est
* Dark Blade
* Mourneblade
* Badelaire
Due to the nature of splat, renaming the symbols is hella hard but
possible once we start importing the `.data` section in it. As far I
know this overlay does not contain any `.rodata`.
Checklist to convert it from Draft to Ready:
- [x] Decompile [func_4000_8017B1D8](https://decomp.me/scratch/HLPI0)
- [x] Confirm name of the functions
- [X] ~~Put shareable code in the appropriate folder (either as `.h` or
`.c`~~ not all overlays have identical functions (see w_029). Needs more
research
- [X] ~~Import `.data` in the C file~~ needs substancial re-work in the
spriteparts asset extractor
- [x] Move `AnimSoundEvent` to the appropriate header
- [X] ~~Rename `Entity::unk58` and `Entity::`unk6A`~~ more appropriate
as a separate PR
This worked fine for me locally like this, example is for this PR
https://github.com/Xeeynamo/sotn-decomp/pull/269
`make build_saturn_docker && make check_saturn_docker`
`python3 ./tools/asm-differ/diff.py --overlay game --version saturn
AddHearts`
Co-authored-by: sozud <sozud@users.noreply.github.com>
