Most important note on this one is that it uses the 0xA0 entity offset.
We already had `shield.unkA0` being used in a different shield. However,
on this shield it's accessed as a half-word, while the other one
accesses as a word.
I looked into it a bit, and realized that the other shield uses it as a
change in Y velocity, and ET_Weapon already uses 0xA0 as an
accelerationY. Therefore, I changed that shield to use ext.weapon for
that entry, and this allows us to change Shields to use 0xA0 as a
halfword.
In general, it looks like shields use a mix of the normal ET_Weapon and
the specific ET_Shield. Maybe we can work out what's what at some point
in the future, especially once all the weapons are done and we can start
truly digging into the purpose of every unkXX value in there.
This PR is big, but it's because these functions are almost perfect
duplicates of each other. I figured it would make more sense to process
them all at once than to have 9 more PRs for essentially the same
function.
This basically handles the animation of holding up/putting down a
shield, so it makes sense that the shields are all mostly the same.
The differences are with shields that have an effect when something hits
them - this includes the Iron Shield, Dark Shield, and Herald Shield.
Aside from these ones, this function is a perfect copy-paste, only
requiring variables to be renamed. And with those three, it's still the
same function, just with a few lines added to create their special
effect. Search for "hitFlags" to see the effects on Iron and Herald, and
for ext.darkShield to see the madness going on with the Dark Shield.
Please let me know if you'd like this PR handled differently; hopefully
despite the size here, the level of shared code makes it reasonable to
have such a big PR.
Finishing the Alucart Shield.
Noticed we are doing stuff with offset 0xAC which sounds a lot like the
one in the Player entity, so I called it anim for now especially since
it seems connected with animations.
This finishes this shield. I'm going to try to go through all the
shields in the weapon overlays and get them done, they seem like some of
the most complicated since a lot of the shield spells do some kind of
crazy stuff with graphics.
Mostly identical to MAD and PSP. There are four very different functions
from US that needs to be decompiled to be 100% complete:
* [x] `e_misc.c` `EntityMessageBox`
* [x] `e_misc.c` `EntityRelicOrb`
* [x] ~`e_stage_name.c` `StageNamePopupHelper`~ it does not exist
* [x] `e_stage_name.c` `EntityStageNamePopup`
These four very different functions are the only ones that use the JP
text instead of the US one. This overlay also lacks of `BlitChar`.
`EntityStageNamePopup` is very similar to the PSP counterpart. I used
@joshlory scratch to match the HD part.
`EntityRelicOrb` had some #ifdef between US and BETA (aka the MAD
overlay). I found some code that crossed between BETA and HD, so I just
put an `#else` after `VERSION_US`. We are starting to reconstruct how
the source code originally evolved across different game builds.
This brings us down to 3 DRA functions.
Some kind of weird stuff, like PSP using an extra function (I kept the
function forward-declaration in here for reference once we bring in PSP
DRA). It also uses a dedicated struct, so I'm defining that at the
location of the function, to keep it clean.
Changelog:
* Import all the PSP WRP data that belong to `e_collect.c`
* Remove the `ext.generic` use in favour of `ET_EquipItemDrop`
* Document some fields from `ET_EquipItemDrop`
* Discover the extra field `mariaSubWeapon` on PSP
* `g_api.AddToInventory` signature changed to allow a better match on
[EntityEquipItemDrop](https://decomp.me/scratch/PULKm)
* Remove the fake array `D_8003BF9C` in favour of `g_CastleFlags`
* The `O_TAG` struct is also valid on PSP
* Decompile `EntityPrizeDrop` on PSP
* Align `func_8018CAB0` to PSP
* Align `EntityPrizeDrop` to PSP with a bunch of `#ifdef`
* Align `EntityEquipItemDrop` to PSP using the WIP scratch
[EntityEquipItemDrop](https://decomp.me/scratch/PULKm)
* `DestroyCurrentEntity` is just an dummy item collector from
`EntityPrizeDrop`
* Duplicate functions in other overlays are not yet aligned as I am
waiting to migrate them to use `e_collect`
I noticed splat is not able to successfully recognise pointers if the
data is too scattered. I had to merge the `data` in the YAML and allow
it to be exported into a single file before starting to import it.
The only missing function from `e_collect.c` is
[EntityEquipItemDrop](https://decomp.me/scratch/PULKm).
Data on PSX are slightly shuffled within the same C file. I believe the
PSP build retains the original data order.
Thanks to @sozud for the majority of the work on `EntityPrizeDrop` and
`EntityEquipItemDrop` on PSP. And thanks to @bismurphy for solving the
last piece of the puzzle to match `EntityPrizeDrop`.
This was decompiled by @joshlory , but due to some annoying rodata, I
ended up taking over the PR on their behalf and submitting. The file
split here was a bit tricky to get right, but now we're matching.
I did not do any reviewing of this code, it is presented here as it was
made by josh's scratch.
This was EntityMPReplenished, but then I looked into how it is used and
found that it is used for many other things besides replenishing MP, so
I named it more generically.
I think I hunted down every situation where it is used and documented
them fairly well. In general, I think this is a relatively good-looking
function and is easy to read.
Looking forward to seeing any feedback!
Another one of these PRs that takes an old function that was decompiled
a while ago, and updates it to today's standards.
We move out of using ext.generic, and we use LOW() and LOH() macros
where relevant.
We also cleanup the logic by using PSP as a guide.
This looks nicer, and is also a great example of lots of LOW and LOH on
primitive members, which may be useful in studying what Primitive might
really be, and whether any of its members (such as the RGBP sets) might
actually be structs.
This is the largest function remaining in the decomp, and now it's dealt
with.
It's a giant beast and I can't claim to be anywhere near understanding a
single thing that it does. Researching this and documenting it will be a
second giant PR. Maybe I'll do that someday, but for now I'll leave it
to anyone else who wants to give it a try. None of the variables have
useful names. We could have "give the variables in this function useful
names relating to how they are used" be a "good first PR" issue, since
we set up several of those a while ago.
Data types on some of the externs it uses have been changed to match how
the function uses them.
This also uses g_PlOvlSpritesheet, which we have found seems to need to
be accessed as a numerical pointer, so I added a #define for that. It
seems to be working, so big thank you to everyone who was involved in
the process of setting that up. I believe this is the first function to
actually make use of that.
Besides that, I'll leave it to others to make their comments. There is
really too much in this function for me to talk about it, but hopefully
this is a reasonable start and we can make whatever tweaks are needed to
get this merged.
This is a big messy function, but it's decompiled!
Did what I could to rename variables in a useful way, but I could only
get so far. Hopefully one day we can work out exactly what all the
different angles, XY variables, etc are. But this is one of the biggest
remaining functions and it's great to have matching.
Decided to target this one since it's the largest remaining function in
`weapon` and now it's done. Kind of surprising that such a simple weapon
has such a huge function, but I guess it has a lot of graphics and
therefore a lot of primitive manipulation.
Finishes the heaven sword.
More weirdness with the ext - it appears that unk84 is used differently
in different functions within this value.
Overall, this file could use some improvements, but to start out, having
it decompiled is better than not. Hopefully someone can figure out how
this actually all works.
This one is kind of ugly in places.
It uses offset 0x84 as an s32, while Weapon uses it to hold an entity,
so this forced the creation of a new ext for the heaven sword.
There is only one more function left in this file (EntityWeaponAttack),
so once that one is done, I will move the whole file over to use the
Heaven Sword extension.
Not a very difficult one, but it's a little weird. Not sure what this
entity is, it's modifying the GPU buffers directly, and also setting a
castle flag. No other uses of that castle flag as far as I can tell, so
who knows. Once the overlay is complete we can have the full picture to
figure out where this entity even comes from.
This function is kind of crazy and huge.
I also made its helper static.
The name for the function comes from the fact that the duplicate finder
matched this up with a function in NO3, which had been given that name,
so I named this one to make them match up.
This is a huge one! Lots of file shuffling needed to happen, but now
that things are in place I feel relatively confident that we have our
file splits in the right places, which is great. It's really cool when
we can make file splits that are motivated by game structure, and not by
rodata limitations.
Anyway, here it is, let me know which flags and stuff I forgot about :)
Another big one! This required mangling the files a little bit; once the
other functions are decompiled the files should come back together
nicely. The function itself is in 4B018.c, and the function is currently
alone in that file.
Kind of a complicated process to get this one working, beyond the normal
function decompilation.
Files are split for now, because there are weird things with rodata. I
have already done the two remaining Gurkha functions, so my next PRs
will pull those in and will end up bringing the files back together.
Messy things here, tried to make it looks nice but as always, feedback
is appreciated.
3 NZ0 functions remaining? I think you mean 2 NZ0 functions remaining :)
I don't really understand this one, it's a bit of a mess. Lots of
tilemap stuff, so maybe this does something with the weird shifting
backgrounds in the Alchemy lab? Who knows.
I was able to start with the red door code and rely on that a fair bit.
I modified the code to recreate the parts that are needed for the blue
door.
Their entity extensions matched up (with the blue door needing a couple
extra members) so I changed ET_RedDoor to just be ET_Door, and both
doors use it. I'll be curious to see if the weird golden door to the
Olrox fight is similar to these ones.
NZ0 is really getting empty now!
This is a weird function, we don't really know what it does. But
matching is always the first step. Just glad it works.
The behavior on the `dataPtr` makes me sad. Pointers are treated in such
evil ways in this game.
Boy, this one was a beast!
It created yet another evil awful horrible variant of Primitive, where
it's referencing several s32 values in the struct, so we had to add
another to Primitive.h.
The splat was slightly off, it was missing the nop at the end of this
function.
It appears that this function manages 385 primitives to make the life
max up spawning animation, and puts them all through a bunch of GTE
functions, so I'm wondering if that's why the animation is so laggy.
I'm confused on why this function doesn't show up in duplicates.txt,
since I would have thought it would be universal across all overlays
which contain a boss (which is most of them). Although... now that I
think of it, Slogra and Gaibon are the only bosses in the overlays that
are currently in the decomp, so that's probably why. CEN, DRE, ST0, NP3,
etc don't have bosses so they don't need to have this entity. Hopefully
this ends up duplicating in the other overlays once those get pulled in.
An awful function, but at least it matches!
This one was fun! Lots of use of the coordinate transformation
functions, and lots of weirdly packed data.
Had to shift the splat a little bit. This is the last function in the
file (location-wise, not the last to be decompiled) and the end of the C
segment was slightly off.
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.
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.
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 :)
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 :)
This is an entity that is in every overlay, but appears to be unused, at
least so far.
It looks just like Gaibon's big fireball (in his second form), but that
is handled by a different entity. Presumably we will find its use in a
future overlay.
I also made some general improvements to the function, such as turning
the weird bit shifting into a simple division by 4, thus eliminating the
variables. I also created an entity extension for this entity.
Another victory for my automated deduplicator.
Well here we are, TestCollisions matching!
I'm going to start with this one, and once it's in, I will follow up by
de-duplicating it.
Please review this closely, especially the changes that are happening in
other files than the main C file.
I suspect we will learn a lot from studying this function; I've already
made some changes (including to the Entity struct) but there will surely
be more.
Nice that this was possible with only two `goto` statements.
I expect a fair bit of revision here, especially related to any
enums/defines I might not be aware of. Please be liberal with comments
:)
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!
