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.
The vast majority of this comes from a 6-month-old scratch by
@ser-pounce , here: https://decomp.me/scratch/7Ram0
I finished it up, and made some changes to make it fit into the current
state of the repo.
That scratch puts the isrgb24 value into a StreamCtl struct. I'm
inclined to agree with that, but want to minimize the impact of this PR
on the larger repo for the moment. I expect StreamCtl to be used more
heavily in the final function for SEL, but we'll see how that goes.
The StreamEnv struct is in exactly the same location as
Unkstruct_801B9B7C (which was actually unused), so I eliminated that
one.
That's just about all I have to say for now.
The next function of SEL, func_801B99E4, makes it clear that D_8003C908
is not a struct member. I do not know why it was placed in this struct.
I have that function now matching, but since we're changing around
variables that are used elsewhere, I decided to split the PR so that we
can handle one type of change at a time.
The D_8003C908 variable has not yet been used in any C code, so this
change does not affect anything.
Further, since both struct members were s32, I decided to make it a
2-member array for the sake of conciseness in the code.
This adds some fixes to get tetra spirit mostly working. It copies part
of the framebuffer with MoveImage to warp it, so that's added. Right now
there's some bugs with DrawEnv or DispEnv stuff so that the copy is from
the wrong place every other frame and shows as black. There's a couple
of out of bound issues that have speculative fixes I'm not sure about.
The spells are hard for me to do so I added a macro/hotkey system to be
able to test them quickly. I tried calling the spell functions directly
but they didn't work right. I think there's probably code scattered
around to support them so doing the inputs is the only way to activate
it all correctly
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`.
Wow! With this one, Richter is now down to a single non-matching
function (it's a duplicate of a DRA function which is missing - the one
with the funny pointer math which is connected with
EntityPlayerDissolves).
Anyway, we're matching. This is different from DRA's
EntityPlayerBlinkWhite, but in weird ways that made it a huge pain to
get matching. Definitely was not a matter of replacing a few lines like
some duplicated functions are.
Anyway, looking forward to see if there's anything to fix!
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.
RIC had 3 functions remaining, one of which was this one. Given its
similarity to the one in DRA, I decided to revisit it, and thankfully it
now matches.
I also did some cleanup on the DRA one, including renaming variables,
using macros, etc.
We now have two functions remaining in RIC. They are both duplicates of
remaining DRA functions, which have the same issues as the DRA ones do.
This means that once DRA is solved, RIC will be too, which is amazing!
This takes the GPU from Mednafen and hooks it up by using parts of
libgpu and writing to the fifo. I avoid using DMA and just write
directly and it seems to work fine. This means that the OTAG part isn't
required since that's part of the DMA system and not the GPU apparently.
The main bug I'm aware of is the TILE that fades to white in the warp
room doesn't show up. The GL renderer is still available. I made the
software renderer the default since it's faster and more accurate on
average. The two renderers can be toggled with F8. I turned on linear
logs by default since it's significantly faster.
The biggest gap I'm aware of is PutDispEnv needs to be properly
decompiled and hooked up.
This function was previously the last function in its file.
Upon decompiling, the rodata (specifically the `00 00 00 00` pattern)
indicated that the file does not end here, and that in fact the entire
following file should be part of this file, so I had to change the
splits to accomplish this.
It's an ugly function, and was hard to get a match, but here it is. Did
what I could to document variables but it doesn't seem to make much
sense, if you ask me.
The way this one uses scratchpad is super weird, but hey, it matches.
It's always fun to come across super-unique functions and I'm pretty
confident to say this qualifies.
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!
Now with the maspsx changes, this can also match by using
SPRITESHEET_PTR.
Tried to document all the variables, use flags when possible, etc, so
hopefully this is mostly complete. Should be exciting to have
RenderEntities and RenderPrimitives both working now!
Open to suggestions for how to break this change up to make it easier to
review. The data extraction necessary for naming values in `D_800ACF60`
and `D_800ACF84` could be a separate commit... but I'm not sure it's
worth it.
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 links w_000 and allows the texture to be loaded to vram, as well as
the functions executed.
g_Cluts was renamed since the stages also have g_Cluts. A macro and
preprocessor defines are used to allow unique weapon function names.
This doesn't load the animsets since it seems like that stuff is getting
redone with the asset manager.
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.
