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
Add colours to the various logs to make sense out of all the produced
noise. Also gets rid of the square brackets and use a nicer column
separator. Don't mind the error log being mis-labeled. My hunger for
copy&pasting code consistently betrays me.
but most importantly groups the logs to avoid spamming the same one for
every frame. The log count keeps getting updated on the left-hand side
of the log, replacing the beginning of the path (almost never relevant).
If the log is old, the logging function will go back, update the line
and go back down.
It is a tad bit slower than the original implementation, but logs are
never meant to be seen anyway, especially debug logs. I used a
relatively fast hashing function paired with a dictionary to avoid
unnecessary loops. There are two hashes. `logHash` simply works as an
index to the massive 65K entry dictionary to pick an index. If an entry
is found then check the other hash `altHash` to check if the dictionary
collided with an actually different log, effectively replacing it. Since
`entry->hash` is `0` at the beginning, that also works for new elements.
I believe the slowest part of the code are the two `while (nLinesBack--
> 0)`. I am thinking to maybe unroll the loop in a similar way `memcpy`
works internally to save `fputs` calls. But I have little clue on how to
measure improvements. If you know better on how to take advantage of
moving the cursor through the TTY, please let me know.
You can disable this entire functionality with `#define
FORCE_LINEAR_LOGS` and it gets disabled if `stderr` is not printing on a
terminal.
As discovered in [one of the recent PSP
functions](https://decomp.me/scratch/thtl9), the types for
`g_LayoutObjHorizontal` and `g_LayoutObjVertical` are not of
`LayoutObject*` but `u16*`. This saves some awkward casts that caused
Clang and modern GCC to fail to compile some recent code (specifically
`((u16*)g_LayoutObjVertical) = ` being not valid C).
This is a bit sad as it reverts part of the changes from #1166 that
aimed to improve code clarity.
This one had some small differences in MAD and ST0, so I worked them in
as ifdef.
Also, I cleaned up the function a bit, by removing the unneeded
pointers.
The GoldSizeIndex local variable is unneeded. It is possible to just use
the goldSize argument, and do `-=2`, but I think using the local
variable makes it more readable, so I left it in place.
Made a small tweak to mwccgap so that we don't compile a .c file twice
if we don't need to... compiling psp used to take 2.7s and now takes
2.0s on my laptop - so not super noticeable at this point, but makes
sense not to compile things twice!
Also added sha1sum for the wrp.bin to avoid people copying in the wrong
file and having a bad time (dont know why I didnt catch that pspeu means
psp eu.. not psp us!)
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.
Another de-duplication done using my automated script. Still finding
some bugs, but these results are promising. The process becomes an
absolute breeze.
Another nice de-duplication. Cool to dig into these functions and see
what they do.
Continuing working on my automated de-duplication script. This one was
definitely much easier because of it. I didn't have to track down a
single symbol. In fact, most of my time putting this together was just
commenting in the .h file.
This spawns several copies of EntityUnkId14, very similarly to the
existing EntityUnkId15Spawner.
Most of the work for this PR (renaming all the functions,
cross-referencing symbols across overlays) was done by an automated
script I made. I am still testing this script, but it is nice to see
that it appears to be starting to work. I will test it on a few more
de-duplication PRs, and then consider adding it to the `tools`
directory.
Fairly standard function de-duplication PR. Starting to get kind of good
at these! I might look into automating parts of this process to make it
go faster...
Next I'll be doing the unkId14 spawner, which is just like the existing
unkid15 spawner.
Found this function which is in every overlay, and is a dependency of
another function I'd like to de-duplicate.
See the comment on the .h file for a description of what this function
appears to do. I think the fact that it's taking the entity's position,
offsetting it based on the provided array, and running CheckCollision
makes CheckColliderOffsets a reasonable name without being too verbose.
Happy to use a different name if anyone has opinions.
This function had been decompiled in a few overlays, but was still
INCLUDE_ASM in others, so this will also unify them to all be
decompiled.
Noticed these in the duplicates list. These are different from the
existing EntityEquipItemDrop, but they match each other.
I took the function from `wrp/e_collect.c` and pasted it in, and then
made adjustments until it matched.
Probably not worth de-duplicating. I left comments at the top of these
functions though, as future reminders.
