Another disappointing non-match, even closer than #1008 . There is only
one registry swap in one single line. I've been permuting for a day
without success. Putting this here if anyone wants to give it a try:
https://decomp.me/scratch/AuSvv
This one was pretty complicated but I'm glad I got it working. Not
completely certain what this does but good enough for now. The two
functions are even more similar than DRA and RIC functions usually are.
For any comments to be made, feel free to only comment on one of the two
instances and I will make the change on both.
Again, huge thanks to @ser-pounce for figuring out the final puzzle on
this function!
Getting this in and parsing all the rodata before and after meant I
discovered some different file splits, but now it's all set, with no
`const s32 rodata_padding` type of stuff, which is great.
I imagine having this working will be a great resource for learning more
about how Richter works.
Decompile and de-duplicate EntityStageNamePopup for all the overlays the
function is in.
I also detected a helper function I renamed as `PrimDecreaseBrightness`
that was originally accepting a completely wrong parameter type. This
helped me to get rid of `Unkstruct_80128BBC` too.
Originally decompiled this for RIC, then in the process of figuring out
what this entity was, I realized it was a duplicate of one in DRA which
was already named EntityHitByIce. Therefore, I have gone ahead and
decompiled it for DRA as well.
I think there are a whole lot more functions that are duplicated between
RIC and DRA, but there are enough subtle differences that the
duplicate-finder script misses them.
Because of the close relation between this and AlucardHandleDamage and a
previously-unnamed RIC function, I have named that function
RichterHandleDamage to match.
Comment describes what this function is for. I identified it by setting
a breakpoint in an emulator and waiting for it to trigger, then verified
by NOP-ing it out.
Here is a screenshot of the sparkle appearing:
This is the last function using rodata in 32324.c. However, once I
decompiled it and did the normal rodata steps, I had a mismatch of `00
00 00 00` bytes, which signalled that this should not be the end of the
file. Therefore, I pulled 345EC.c into this file, which now matches.
Function scratch is here: https://decomp.me/scratch/PSKCu
My main goal was to extract the .data for the table in RIC, but while I
was doing that, I also decided to clean things up a bit, so now:
- Both tables have proper names
- Both tables have all the entities forward-declared in the proper .h
file
- Attempted to remove all repeated forward-declarations in the .h file,
not sure if I got them all
Overall this should improve readability and should be pretty close to
how I would expect the original game to have done it.
Found this function in RIC, it's very similar to the one in DRA, which
is nice.
Patterns of zeros in the rodata indicated that this should be the start
of a new file, which also makes sense since CreateEntFactoryFromEntity
comes with it.
RIC has its own array of blueprints, I'll probably add that to the splat
later on but that seems like material for a separate PR. For now we
focus on the entity function.
The function that keeps track of if Richter has pressed down-up-cross to
do a High Jump move.
This is the first time we have a button combo being tracked outside of
DRA, so I moved the ButtonComboState struct from dra.h to game.h.
When the input succeeds, a function is called, so I've named that
function DoHighJump and also made general changes to that function to
bring it up to date with our current code standards (like FIX()).
I think those are the main highlights!
This is actually the last function in RIC (by which I mean "There are no
functions in RIC which are located later in the ROM than this one"), so
that's neat. There was a mistake with the splat, where the nop in the
delay slot for the return instruction of this function was being treated
as the first 4 bytes of SBSS, rather than as the final instruction of
this function, but luckily I worked that out and fixed it in the splat.
This is extremely similar to the one in DRA. However, it stores to 0xB0
in the entity. This is interesting, I've seen that being a significant
address in other RIC functions too. I added it to the extension that was
used for this entity in DRA.
Next entity function in the same file I've been chewing through. Only
one left in here!
There's a really weird block with a bunch of trig functions that I can't
make sense of. Might be doing some kind of weird 3D transformation? Not
sure, but it matches. Would have never gotten it without the permuter.
Scratch here if you want to play with anything, especially if you can
remove the temp_a1 being used in the block of trig.
https://decomp.me/scratch/xdNx7
temp_v0 is also a bit funny, not sure why it would use lhu to load a
variable which is explicitly an s16 and we're negating, but whatever.
Everything matches so submitting now.
After finding a copy of GetFreeDraEntity in RIC, I decided to rename the
function (in both DRA and RIC) to GetFreeEntity. Similarly, the function
right after it is GetFreeEntityReverse (since its logic runs in
reverse).
I also found CreateEntFactoryFromEntity in RIC, so I renamed that to
match the version in DRA. We will need to go through and use the FACTORY
macro for its uses, but I'm not going to tackle that quite yet.
Seems there is a lot of work to be done making RIC catch up to DRA,
we'll see if I keep working on that moving forward, it's neat to find
the ways the two match.
- Main focus is an update of func_8015D020. That had a TODO to remove a
variable, which I have now removed. I also used enums for player steps,
and changed the speeds to use FIX(). I also cleaned up the control flow
to remove the goto.
- While working on that function, I noticed that it calls an unnamed
function. The duplicates list at
https://raw.githubusercontent.com/Xeeynamo/sotn-decomp/gh-duplicates/duplicates.txt
indicates that SetSpeedX was missing from RIC. I added that in now and
adjusted all uses in RIC, including the ones in func_8015D020.
That's about it; these are two different changes but given that we're
just changing the format of them, I'm assuming this will not be an issue
to have them in one PR.
Had to add PlayerSteps into RIC since we're using enums for Player.step
and SetPlayerStep. I think maybe these should be moved out of dra.h and
into somewhere more generic, but for now copying it over works well
enough. If there are steps that are reused between Alucard and Richter
for mutually exclusive moves (ie, step N is an Alucard-specific move for
Alucard and a Richter-specific move for Richter) then we will need to
maintain separate lists. This works for now.
While going through dra/7E4BC.c sequentially, I was going to decompile
func_8011EDA8, but then noticed that it is a duplicate from RIC.
Therefore, this PR copies the code from RIC (with different
AnimationFrame constants) to match.
This function calls DestroyEntity, which is in many, many overlays, but
for some reason in RIC was still using a placeholder address name, so I
also went ahead and properly renamed that to be DestroyEntity.
Allows to not hard code the location in-memory of decompiled functions
and imported data if not required. This allows to relocate the
referenced symbols when editing the original code or game data. If you
were getting the offset of those symbols from the symbol list in
`config/` I suggest to use the built `build/us/*.map` file instead.
Not a very special function per se. I struggled at de-duplicating the
four variables at the top of the function as using just one would give
me some minor reg swaps. I thought adding an enum as a returning value
but I think it is a bit over killing for how small the function is. It
is only called by `EntityAlucard`.
Interestingly, the function in DRA is different between HD and US. But
the HD version is identical to the duplicate found in RIC US. What I
suspect it happened is one of the developers while scrolling the various
functions, found the `- 14407` in an odd spot relative to the rest of
the function and moved it to make it consistent. But as some code from
DRA was copy&pasted to RIC, the same developer did not think to apply
the same change there.
EDIT: Note the `FIX_TO_I`. It is a new macro I added for another
function I failed to decompile.
Matches the two orphan functions `DebugCaptureScreen` and
`DebugCaptureVideo`. I also fully imported the `.rodata` into `42398.c`
and I am proud to say the file is now fully decompiled! I also renamed
two other functions that are used by the two I decompiled. They are now
all fully documented. Note the unused `u8 bmp[0x100];` in
`DebugCaptureVideo`, probably a copy&pasta left-over. The function does
not match without it.
I am waiting for https://github.com/mkst/maspsx/pull/6 and
https://github.com/mkst/maspsx/pull/7 to be merged as currently maspsx
breaks the two functions.
Thanks to @MottZilla research I was able to extract the spritesheets of
Richter as PNGs in conjunction with the original palette from
`F_GAME2.BIN`. When the binaries are built, the PNGs are recompiled back
into binary.
In case of modding, it is possible to modify the sprite size to
accommodate bigger or smaller sprites. Although it is not possible to
modify the existing palette as currently we have no way to extract and
rebuild `F_GAME2.BIN`. You would have to modify the palette via hex
yourself. The file `config/splat.us.ric.yaml` shows in which offset the
palette is located. Just for reference, the colour format for the
palette is RGBA5551. It is important that edited PNGs has 16 colours
otherwise the build will fail.
The `padding` field is required to reconstruct some left-over / junk
data that is not part of the data sprite. For the sake of modding, the
`padding` field can be whatever.
I am not sure if `RIC.BIN` pointers can be relocated. If that is the
case you might get a black screen when playing with Richter. It should
be easily fixable though.
