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!
Given the fact that sharing compiled C objects is not exactly possible
(code heavily copy&pasted maybe? this initiative is now abandoned 👉53a566f075)
I decided to keep pressing forward with shared headers. Thanks a lot to
@hohle for making our life much easier by cross-referencing symbols.
The file split on WRP seems to be the closest file split we might have
compared to the original source code (still speculating here). I think
it would be a good idea to start splitting other overlays too with the
same approach.
My idea is to have a file split like the following:
```
st/
cen/
e_particles.c
e_misc.c
st_common.c
nz0/
e_particles.c
e_misc.c
st_common.c
wrp/
e_particles.c
e_misc.c
st_common.c
e_particles.h
e_misc.h
st_common.h
```
each of those C files will just be a one-line `#include
"../the_shared_code.h"` as usual. Right now we create individual headers
for single functions, sometimes for more than one function when we think
grouping makes sense. But I think we can start merging some of those
headers and consolidate the code. This can be done gradually. For
example `src/st/e_particles.h` is still importing function headers under
the hood. That is okay for now, but later on I wish to import those
headers functions into their respective parent headers.
Another important aspect to consider that will validate a correct file
split is to start importing the data inside these new C files. Right now
we have floating data such as `src/st/wrp_psp/wrp_data_EA00.c` or
monstrosities such as `src/st/wrp/6FD0.c`. An example of a (possibly)
correct migrated data is what this PR does with WRP PSP and NZ0 PSX,
with data pointing in `src/st/*/e_particles.c`.
The `check` recipe now has dependencies on all of the files it checks
allowing them to be rebuilt if necessary.
Consistent use of `dd` and suppressing `dd`'s output which noise for the
replacement and padding it's doing.
Run 7z in non-interactive mode to avoid confirming overwrite of files
during extraction (equivalent behavior to `VERSION=us` `extract_disk`).
`patch` is a phony target.
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
A few changes here.
First, Slogra needs to be split out to his own file, as mentioned in my
previous PR.
I decompiled EntityCloseBossRoom, but I decided it needed a better name,
since, while it does close the door to the boss room, it actually does a
lot more and in general manages the fight (most importantly, it starts
the fight, spawns Slogra and Gaibon, and when they die, spawns the life
max up). Therefore I named it BossFightManager. Since this function, and
the door blocks it spawns, are the only ones in this file, I decided to
call it bossfight. I think we should try to be liberal with naming
files, once we know all the functions contained in them.
Otherwise I think that should do it! Very cool to have the first boss
fight in the game all figured out.
This was great to get working!
There was a Decompme WIP, but I decided to ignore that and do it from
the beginning, and I think that worked out well. PSP was of course very
helpful.
This ended up being pretty readable with all the steps that were already
documented (I think that was Sonic's doing, so thanks!). Pretty happy to
have this working!
Slogra and Gaibon each have a separate `FntPrint("charal %x\n",
self->animCurFrame);` call in their debug step. Importantly, this string
is in rodata in two places. If Slogra and Gaibon are in the same file,
they share the same string address, and the rodata only gets the string
in one place. Splitting the files restores the duplicated string in
rodata, meaning that these files need to be split.
I have already decompiled EntityCloseBossRoom and found the same issue
there, so my next PR will end up pulling out Slogra into his own file as
well.
Lots of code here, review carefully!
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.
Thank you to @hohle for solving the last line swap mismatch!
This is the last of the dependencies for DRE Entity3DBackgroundHouse, so
hopefully that one will be doable now. I'll get started on it :)
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 :)
