Use the following input endpoints `FileOpenRead`, `FileReadToBuf`,
`FileAsString` and `FileUseContent`.
There was a lot of redundant and inconsistent code scattered across all
the functions responsible of opening and processing files. I also
realised the purpose of some File helpers was not entirely clear, so I
spent some effort to document them.
This is a small part of a bigger effort on refactoring `sim_pc.c`. I am
also planning on adding support for paths such as `disk://` to load from
`disks/us/`, `asset://` to load from `asset/`, `card://` to start adding
support for simulated memcards and so on. This is setting the very
basics to plan that out.
Stopping at 0x633 (`SFX_UI_SELECT`) for now, but will continue to add
and update more sfx references soon.
So far we have 51 out of a potential 736 sfx IDs (`0x8E0` - `0x600`).
For what it's worth, the last valid sound ID I have listed in my
spreadsheet is `0x8D2` found in `DRA`, `RIC`, `BO4`, `BO6`, and `RBO5`
so the actual number might be 722 enum IDs, but we'll see what happens
since the last sfx group in the list belongs to vabid 3.
I decided to rename `SFX_SKULL_HIT` to `SFX_METAL_CLANG`, as well as
`SFX_SWORD_SWISH` to `SFX_WEAPON_SWISH`.
These are more generic names that better match up with the actual sound.
While `SFX_SWORD` is mainly used for sword weapon cues, it is used for
other weapon entities so I renamed it.
Same idea also applied to `METAL_CLANG`; it's mainly used for the CGI
spinning Stone Skull enemies but it also shows up in CEN as an elevator
sound cue.
I also used `SFX_RIC_RSTONE_TINK` as an abbreviation for the Rebound
Stone "tink" sfx, to help keep these names short.
Currently function_finder misses functions since we don't continue to
fetch if there's another page of results. However just increasing the
page size makes the script super slow.
This adds caches to the zip file and result fetching to try and get this
running at a reasonable speed for `weapon`. We also fetch until `next`
is null and increase the page size so all the results are fetched. This
runs about 12 minutes on my system now. Results look like this
https://gist.github.com/sozud/69aeafcc671d6354da474db952e8afef
Starting off with something simple. Per
[sozud](https://github.com/sozud)'s suggestion in #1441 , I put in a new
enum for sounds. There's only one reference to Richter's whip sound in
the codebase so far. According to my research, BO6 and RBO1 reference
this ID as well.
There's several other whip rattle sounds (0x603-0x606) immediately
following the commonly heard 0x602 cue. Unless BO6 or RBO1 uses random
sound calls (like Alucard's randomized grunts), I don't believe these
are referenced in the game and are unused.
Decompiles `EntityWeaponAttack` for `w_038` and `w_039`. These match
several other `EntityWeaponAttack` methods with the addition of a
conditional call to `CreateEntFactoryFromEntity` at the end.
Adds an a PSX implementation of `EntityRWarpRoom`. This is similar to
`EntityWarpRoom`, but needs to raise and lower the player stands on, and
obviously has to warp to other inverted rooms.
This also pulls in the remaining data and static storage, completing the
`rwrp` mapping.
---------
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
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.
The duplicates report has several false negatives when a function has
the same name as another function which has not been decompiled. This
affects overlays which share many of the same function names (e.g.
`EntityWeaponAttack`).
The duplicates tool now parses the `INCLUDE_ASM` macro to extract the
path and ASM file. It then uses that when determining whether or not
each ASM file is actually included or not. Previously, only the function
name was checked, so if any `INCLUDE_ASM` file had the target function
name, it would be marked as not decompiled.
Before:
% | Decomp? | Name | Asm Path
-----|-------|-------------------------------|--------------------------------
| 1.00 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_008/EntityWeaponAttack.s
| 1.00 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_009/EntityWeaponAttack.s
| 0.91 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_010/EntityWeaponAttack.s
| 1.00 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_011/EntityWeaponAttack.s
| 0.98 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_025/EntityWeaponAttack.s
| 1.00 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_026/EntityWeaponAttack.s
| 1.00 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_027/EntityWeaponAttack.s
| 1.00 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_028/EntityWeaponAttack.s
| 0.97 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_058/EntityWeaponAttack.s
After:
% | Decomp? | Name | Asm Path
-----|-------|-------------------------------|--------------------------------
1.00 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_008/EntityWeaponAttack.s
1.00 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_009/EntityWeaponAttack.s
0.91 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_010/EntityWeaponAttack.s
1.00 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_011/EntityWeaponAttack.s
0.98 | false | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_025/EntityWeaponAttack.s
1.00 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_026/EntityWeaponAttack.s
1.00 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_027/EntityWeaponAttack.s
1.00 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_028/EntityWeaponAttack.s
0.97 | true | EntityWeaponAttack |
../../asm/us/weapon/nonmatchings/w_058/EntityWeaponAttack.s
(note: `w_008`, `w_009`, and `w_011` are decompiled in my workspace, but
not in GH)
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
The most important thing here is that D_170000_8017CBD0 is an array of
f32 values. But since entry 0 is only accessed with `.i.hi`, the
auto-detected symbol was `CBD2`, offset by 2, so I had to manually make
the symbol for this one variable. I studied the symbols file to figure
out how to declare it, and this ended up working. Now that I know how to
make weapon symbols, I can start making useful names for these in the
future. Not for this one though, this doesn't make any sense.
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.
This modifies a variable at 0x80097420, I noticed that was in the
g_UnkGraphicsStruct, so I went through all the uses of that variable and
made them all use the struct.
Brings DRA up to one function remaining.
I think everything is in order, but looking forward to any suggestions.
The last missing function is a pretty irrelevant Kanji function, so it
will be nice to have all the material to really start understanding DRA
now.
Start to perform a series of code refactoring to align the various
overlays on how NZ0, WRP and RWRP are currently organised, aiming to
share as much code as possible. This is a good stop gap that does not
change too much. There are virtually no major changes other than the
removal of the fake symbol `D_8003BEEC`.
I found it is very hard to share every single line of code due to some
minor differences in the castle flags. I couldn't yet spot a reliable
pattern on how castle flags are manager across stages.
My vision is to share as much code as possible, possibly not as header
files but as C files in a similar fashion of #1425 . I am aiming to
model NP3 so we can merge it with NO3 given the fact they share a good
chunk of the code base.
I am waiting to split the rest of the entities into their own individual
files. My idea is to have a file per entity or per entity group with
their own set of data and helper functions, possibly all marked as
`static`. We agreed it is probably a good idea to wait exploring the PSP
build of NZ0, NO3 or NP3 before performing this step.
Now that @sozud has added function similarity, I wonder if it's worth
including prefix matches in the results of function_finder. This would
let us name a scratch ex: `EntityWeaponAttack_w_053` and have it still
show up in functions.md. Thoughts?
This changes the psx function finder to compare the local and remote asm
to find a match. Right now there's a lot of false positives due to name
collisions. The new output looks like this:
https://gist.github.com/sozud/4eaa80c2ebb475551986b4f55d42d036
This should be off by default for the other platforms but I can't check
saturn locally right now.
This imports the psycross gte code and hooks it up. I added a hotkey to
create a candle with a subweapon. As far as I can tell you can't give
yourself a subweapon directly without breaking stuff since
EntityBreakable and the entity it spawns set up various things. I used
this to test the gte. This also fixes a couple of function pointers like
CheckCollision to fix the cross animation. This removes a few gte
functions we previously implemented in favor of their versions, I'm not
sure about the tradeoffs there.
I moved *some* of the PSX-specific stuff out of the common `Makefile`
and into the `Makefile.psx.mk` -- there is still more that could be done
here, but this should be enough to have the correct rules for PSX and
PSP with the desired assembler.
Also threw in a bonus feature where I've removed the `move` macro from
`macro.inc` because `maspsx` does this automagically for you now.
Iterating on this problem in master.
Now that wrp/rwrp are sharing so much code, analyze_calls is having
trouble telling what functions call each other in which overlay.
I think this will resolve all the issues we have for now, but I'm sure
more will appear over time.
This will decompile all the functions but the new `EntityRWarpRoom` from
the RWRP overlay.
Note that as `e_misc.c` has a function with a different castle flag, I
had to use a shared header. Everything else was identical.
---------
Co-authored-by: bismurphy <tjmurphy@mit.edu>
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.
