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.
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
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.
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
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 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.
When decompiling MAD TestCollisions in my last PR, I noticed that the
call to BottomCornerText was going to func_80198BC8 in MAD, which was
not yet decompiled.
The duplicates report indicated that func_80198BC8 was a duplicate of
func_97000_8017AB54, a weapon function that I decompiled a few weeks
ago.
I copied the code for that function into here, and renamed it to
BottomCornerText to match the other overlays, even though it's not the
exact same code as is used in other overlays.
This should finish out the set :)
Can't say I understand the differences here (it's modifying
g_CastleFlags during the item drop randomization routine for crying out
loud) but hey, a match is a match.
Got this one done too! ST0 is slightly simpler than the others.
I tried to adapt the existing matching TestCollisions directly, but I
found that it was easier to work on PSP to get the logic right and then
move to PSX instead.
I think I did this right, but this is my first time de-duplicating a
function, so please point out any mistakes :)
ST0 not included because it has different logic internally - will work
on decompiling that one next.
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
:)
Same as #1181 but on PSX. The imported data falls right at the top of
each new file based on some old assumptions of mine, suggesting we're
probably on the right track.
A massive PR, I know. It's the smallest change I could do to make this
happen.
After comparing the function order from both ST/WRP PSX and ST/WRP PSP,
I was able to come up with a file split much different from the one
suggested from Splat. It still returns an 🆗 and it follows the same
group functions order from the two game builds.
As soon as we are on board with the C names, next PR will be to do the
same with the PSX overlay. Then in another PR we will be able to start
merging the C files between the two builds. Ideally the same approach
can be used for sharing C files across the different overlays instead of
relying to floating header files in `src/st`
Thanks to @sozud for the hint and @bismurphy for the refactoring idea.
The function `PreventEntityFromRespawning` on PSP hints that the struct
starts 8 bytes earlier. Also there's a missing `nop` at
`PreventEntityFromRespawning`, suggesting the function had to be moved
to the previous function.
I noticed that this struct had some overlap with other values in memory,
so I have pulled all those values into this struct.
The boundaries of this struct are uncertain and are a matter of ongoing
research.
I get
```
mipsel-linux-gnu-ld: build/pspeu/src/st/wrp_psp/BF50.c.o: in function `FallEntity':
(.text+0x0): undefined reference to `g_CurrentEntity'
mipsel-linux-gnu-ld: (.text+0x4): undefined reference to `g_CurrentEntity'
mipsel-linux-gnu-ld: (.text+0x1c): undefined reference to `g_CurrentEntity'
mipsel-linux-gnu-ld: (.text+0x20): undefined reference to `g_CurrentEntity'
```
Not sure what the issue is
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!
This organizes funcitons believed to be originally found in `entity.c`
into an equivalent `entity.h` based on the research of @Xeeynamo:
* `DestroyEntity`
* `DestroyEntitiesFromIndex`
* `AnimateEntity`
* `PreventEntityFromRespawning`
Includes `entity.h` in place of stage implementations or ASM.
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
Discovered in #1167, where when the player approaches the red door it
forces the input. The line `g_Player.padPressed = g_Player.padSim;`
makes it even more obvious.
This needs to be rebased upon the other PR, otherwise it will break the
build if merged.
Pulls out `CreateEntityFromLayout`, `CreateEntityWhenInVerticalRange`,
`CreateEntityWhenInHorizontalRange`, `FindFirstEntityToTheRight`,
`FindFirstEntityToTheLeft`, `CreateEntitiesToTheRight`,
`CreateEntitiesToTheLeft`, `FindFirstEntityAbove`,
`FindFirstEntityBelow`, `CreateEntitiesAbove`, `CreateEntitiesBelow`,
`InitRoomEntities`, `UpdateRoomPosition`,
`CreateEntityFromCurrentEntity`, `CreateEntityFromEntity`,
`EntityIsNearPlayer`, and `InitializeEntity` into headers to share the
implementation between stages.
`libstage.h` is a new header intended to bring in a sequential block of
functions shared by all stages.
`st_private.h` is a new header intended for declaring symbols used by
all stages that aren't otherwise accessible to code outside of a stage.
The only discrepency is `MAD` which has a unique implementation of
`CreateEntitiesToTheLeft`. Instead of being able to blanket include
`libstage.h` it needs to bring in individual headers before and after
its implementation.
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
