Unfortunately, this required an evil change of the return type, even
though it doesn't return. And since it's one of many weapons that share
the functions, they all had to change.
Otherwise, nice to have the food figured out (this is the last food
function), since food is a somewhat major part of this game.
`func_8010DBFC` now matches on PSP, so it's most likely to be real:
https://decomp.me/scratch/xuNg5
`func_8010DA70` has a reg-swap but it's matching better than the
original: https://decomp.me/scratch/mGIed
I am a bit concerned about this function as it seems to suggst
`AnimationFrame` is a structure that does not exist and it might just be
a `u16` array.
This was an old one with a decompme comment in the code that I decided
to tackle. Turned out to be able to make it relatively straightforward!
I think the naming is reasonable and is motivated by the behavior in the
code, but happy to adjust if needed.
Strangely, decompme informed me that the function was matched here:
https://decomp.me/scratch/aEXJO by "NicoVazCan", 3 months ago. Not sure
who that is, but they never submitted it, so I guess it's abandoned.
Either way, I think the code in this PR is more readable.
Kind of a crazy one with the way the vectors are dealt with, but
eventually got it to work. Hopefully this can be a nice reference for
some of those SDK functions.
https://decomp.me/scratch/lSGji
Credit to @Xeeynamo for 99% of the initial match, I just fixed up one of
the registers and did some light refactoring. The repetition of `temp_s0
= ptr->desc` makes me think it's actually an array reference but I
couldn't get anything else to fit.
A while ago, I created the s16_pair struct, and used it in various
functions. As the name implies, it is a pair of s16 variables.
I later found that there already exists a Point16 struct which has the
same data, and is a better description anyway, since its members are `x`
and `y`, and this structure is almost always used to represent x-y
values.
I've gone through the repo for every use of this structure, and changed
it over to be Point16. Therefore, s16_pair will no longer exist in this
project.
This is a collision function, similar to the ones that were completed
for Richter a little while ago.
I changed the collision offsets to use Point16, instead of the old
s16_pair struct.
The yaml changes were generated with a script.
https://gist.github.com/sozud/ae6837a24bc8bb4e8bcc89d3e14d83f4
The alignment of the yaml seems to be wrong so I had to check if the
address % 16 == 0 and only split at those spots. I put the data in
create_entity since it's the first file in the psp yaml.
Cherry-picking a few floating fixes from a testing branch as they're
good enough to be merged into `master`:
* With cmake 3.29.3 and GCC 14.1.1 I am personally having some
compilation issues. I disabled some error checks to make the executable
running locally on my machine. This might fix potential compilation
issues if we upgrade the CI agent.
* Fix the use of a fake symbol in WRP
* A few signature adjustments
* `HitDetection` with a simulated scratch-pad
I think those are a bunch of animation indices? I am not yet sure how to
represent them as structured data, so there you go having them imported
as C files.
Importing some data from `DBD4` with the goal of making the _Sound_ app
more accurate.
I do not know in which file to put this data into, so I created a file
ad-hoc.
EDIT: I kept importing more
Started working on this one and then I realized it's identical to the
one on the previous shield, so it was a direct copy-paste, aside from
the names of the D_C1000 variables.
Maybe we'll de-duplicate in the future but for now I think weapons
should just be written individually.
I'm pretty sure this has to be the laser beams for the Medusa Shield.
They get spawned by the EntityWeaponShieldSpell.
This function is a pretty big mess. It could probably benefit from a
cleanup pass, potentially using PSP to assist.
But for now, the goal is matching, so hey, this matches :)
This allows the fade-in / fade-out effect from `func_801027C4` and the
content from `DrawEntitiesHitbox` to be rendered on screen.
The fade-in is a bit weird, it fades out to white instead of black. I
doubt the rendering is accurate at the moment, but better than not
showing anything.
The Medusa Shield's laser-beams use this function for finding enemies to
target (I think).
I was reviewing this function and noticed the awkward line `if ((arg2 <<
0x10) != 0) {`, and realized that means `arg2` should be `s16`. It
matches, so I think this is right.
Named it facingLeft since that's what is used in the call that I have so
far. The function graphs indicate that there are 3 functions that use
this one (none decompiled yet), so we will see if this shifts as we
discover more. For now, I think this change makes the most sense.
Noticing a lot of similarity among the shield spells. Not enough to
de-duplicate them, but enough that decompiling them is a breeze.
Unless there is something else that takes my attention, I will probably
focus on decompiling all the shields next. I'm already done with 2 and
there aren't many in the game.
This finishes out the Skull Shield.
Nothing too terribly special. I added a new #define for the player
status flag at 0x10000, since that's used here. Hopefully we can find
the function that actually sets that flag; I couldn't find it.
Quite a big one. I merged `EntitySoulStealOrb` across all overlays by
normalising the symbol names. The symbol types was all over the place,
so I had to fix that as well.
I solved the s16/u16 ifdef between PSX and PSP. The only part I couldn't
match without a ifdef was `angle = (angle - 1) * 8;` and `angle = (angle
* 8) - 8;`.
I also decompiled the exclusive PSP functions `func_psp_0923AD68` and
`func_psp_0923B2F0` and merged the PSX and PSP `e_particles.c` code. The
exclusive functions required a file split.
Secondary function for the Skull Shield. Gets spawned by the ShieldSpell
that just got merged.
I also noticed too late that my previous PR reverted the update to
mwccgap since I hadn't updated that; this PR includes a fix to that
accidental revert.
This one was a beast, but nice to get it working.
This seemed to match the same entity extension as weapon 29. Weapons 28
and 29 are both shields, so I decided to rename the Weapon29 struct to
be Shield instead. We will see if it continues to match for the future
shields.
This had a ton of FIX(), enums, #defines, etc, so hopefully I got them
all :)
Straightforward PR. Interestingly importing the data doesn't seem to
result to a match ad there's some `0x10` aligned padding added. Either
we know too little about importing data with MWCC or the file split was
wrong and the data belonged together with other functions in another C
file.
For now I had to use a `#ifdef`. It will probably get forgotten until we
decide to import the data from WRP PSP.
I found the variable `distance` in `func_80132A04` can be negative. The
array index will underflow unless the two global variables
`g_CdVolumeTable` and `g_VolumeTable` gets merged
