Pulls out `EntityExplosion` into a common file.
`cen` and `rwrp` appear to have not imported a declaration for
`AnimateEntity` and call it as an undeclared function with a int-sized
return value. Since `AnimateEntity` is declared in the same compilation
unit a workaround is done to fix how the return value is interpreted.
I had to cherry-pick some existing changes from another branch, but that
part is tested and working.
For the blueprint stuff, I changed the fields from the strings `"TRUE"`
and `"FALSE"` to native JSON boolean values `true` and `false`. That
made things much easier to parse.
The parsing mechanic is straightforward. I'd like to have @bismurphy
review on the blueprint parser and asset changes specifically.
In the interest of reducing uses of `generic`, and especially the
`entityPtr` member of it, I found this function which had several
duplicates already, all of which used `generic`. Rather than cleaning it
up in every instance, I decided instead to de-duplicate it, and then
clean it up in the .h file.
I needed to make a new entity extension for this, and noticed that we
had `ET_Entity16`, but then I realized that this was being used for
`g_Entities[16]`, so I renamed that to be `ET_EntitySlot16`, leaving
`ET_EntityXX` available, for XX being the ID of an unknown entity.
This took a few hours of research spread across a few days. A few
take-aways:
`.ext.weapon.anim` and `.ext.player.anim` are both on `0xAC` and they
NEED to stay aligned since they both call `PlayAnimation`, which
operates on `.anim`. I double-checked `EntityWeaponAttack` and the param
entity is definitively not `PLAYER`, despite `.anim` being in the same
offset. I did not encounter a single `.ext.generic.unkAC` that is not
related to animations, so this can be a pretty strong clue of a pattern.
I have this theory where not all the area of an entity from `0x7C` to
`0xBC` is reserved, but just from `0x7C` to _at least_ `0xAC`, with _at
least_ the last `0x10` bytes are part of a shared struct among all
entities.
```c
/* 0x7C */ Ext ext;
/* 0xAC*/ u8 anim;
[...]
};
```
I want to collect more proof before proceeding to mass-rename
everything.
I learnt what `g_Player.pl_vram_flag` is actually doing. It holds some
kind of state of the player towards the map collision. It holds a bunch
of flags that helps setting the animation. I still feel not confident
enough to create `#define`'s for it until we know more.
All the `condition = ((g_Player.pl_vram_flag & 0x20) != condition)` got
rewritten with the following:
```c
atLedge = 0;
if (g_Player.pl_vram_flag & 0x20) {
atLedge = 1;
}
```
the `atLedge` adds up to the `anim` function. The animation table
essentially have one ID after the other where the first holds the Anim
ID when the player is not at the ledge and the next one where it is. For
example: `[ANIM_STAND, ANIM_STAND_ATLEDGE, ANIM_ATTACK,
ANIM_ATTACK_ATLEDGE]`.
`D_800ACF4C` and `D_800ACF54` are some kind-of animation helpers when
Alucard either stands still, jumps or falls. I burnt the values in
`stubs.c` while we wait for importing the remaining DRA data.
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 :)
