There is already EntityHolyWater in DRA, but this one is quite different
(which makes sense, because Richter's is very different in behavior from
Alucard's). Still, there are some small overlaps here and there.
Due to the ongoing failure to match `func_80166784` (the previous
rodata-using function), this is being split out to a new file, even
though I'm pretty sure they're supposed to be in the same file. We will
reunify the files once `func_80166784` can be solved.
There is a function which is identical in the overlays, and is only used
by this function. I have gone ahead and named it identically in both
overlays.
This one was tricky and required some restructuring of an area of
memory, but it matches now, so that's cool!
No big comments from me but this one has a lot of random stuff so let me
know if I missed some enum or something!
Several things with this one.
1) In order to determine what this actually was, I needed to extract
Richter's subweapon definitions. I decided, at least for now, to add
that extraction for RIC, using the `assets.py` script.
2) In order to match this function, we need a new Primitive, which is
similar to the existing one (and FakePrim) but has a few totally
incompatible fields. Most importantly, we have s16's at offsets 0x0C and
0x0E, which don't match either of those. Therefore, I introduce a new
primitive that I am, at least for now, calling PrimLineG2, since this is
the first time we're using LineG2, and is also the first use of this
struct, so those may be connected. If a different primitive is found
using these fields, we can rename this.
3) Recognizing that we now have 3 different varieties of Primitive, I
have taken the definitions for all of them and moved them to a dedicated
`primitive.h`, which I think is a good home for them. We should rename
the variations eventually, but having them in one place makes sense, I
think.
Otherwise, this one is fairly straightforward. It's interesting that we
have the hardcoded values for the color of the hydro storm rain in there
- using this knowledge I have made a fun PR for the randomizer which
randomizes the colors of the rain. That PR is here:
https://github.com/3snowp7im/SotN-Randomizer/pull/121
I think that's about it!
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.
I've been wanting to match this for a long time. I matched it by pure
coincidence by moving things around. This is one of the few functions
were the permuter was completely useless.
The function renders a room tilemap, with its background and foreground
layers. This is also the first function that uses the PlayStation 1
scratchpad. It took me a few trials to understand how to use it. This
match gives me the confidence to match the much bigger functions
`RenderPrimitives` and `RenderEntities`. They will be my next targets.
I noticed there were a few wrongs in the rendering system. I used one of
the PSY-Q SDK samples to help me understanding how to implement
`PutDrawEnv` and how to render a `SPRT`. The stealth changes in this PR
aims to easily have the tilemap rendering working. The map currently
appears black. This is not a regression, but the lack of logic of
loading a room.
[EquipKind](https://discord.com/channels/1079389589950705684/1087866009983139870/1196073673392652388)
group decision
[drawMode](https://discord.com/channels/1079389589950705684/1087866009983139870/1197935480428302476)
group decision
I was thinking a more soft PR, but in the light of `BLEND_VISIBLE` to
`DRAW_HIDE`, a mass rename would have happened anyway. So I decided to
rename everything since the majority of the code stands on the same line
of `BLEND_VISIBLE`.
The only changes other than the mass rename are:
```c
#define blendMode drawMode // maintained to easily migrate existing scratches
```
this might or not be useful
.
```c
#define DRAW_DEFAULT 0x00
#define DRAW_TRANSP 0x01 // make it semi transparent
#define DRAW_COLORS 0x04 // use color blending
#define DRAW_HIDE 0x08 // do not render the primitive
#define DRAW_TPAGE 0x10 // use custom tpage
#define DRAW_NOMENU 0x80 // do not render if D_800973EC is set
#define DRAW_ABSPOS 0x2000 // use absolute coordinates with DRAW_NOMENU
```
This is based on the research from the
[RenderPrimitives](https://decomp.me/scratch/geI8L) function.
This was a community effort relying on the work of myself, @ser-pounce ,
@Xeeynamo , and others. Thanks all for helping to put this together and
it will be very exciting to have such a large and important function in
the repo!
Lots of room for improving this one in terms of code style, but having a
baseline functional version in is huge.
These functions both have very difficult functions before them in their
files, so need to split to new files to make the rodata work.
Originally decompiled RIC func_80166060, then once that was done I dug
through the blueprints and realized it matches EntityTeleport, which
made decompiling EntityTeleport an easy task, at which point I renamed
the RIC function to match.
I've also gone through a lot of the functions they call and labeled the
ones that match between overlays; I expect this to be helpful in the
task of identifying names for a bunch more functions.
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.
Progress on RIC has been hugely beneficial for solving some old DRA
functions. I'm going to start going through all the entities and try to
identify all of the ones that are in common between the two. I tried
this one in DRA a long time ago, but once I identified the
correspondence between these two functions, having the RIC version
available made things a HUGE amount easier.
One very important thing in the analysis of these functions: Take a look
at the RIC version, func_80160FC4:
https://github.com/Xeeynamo/sotn-decomp/blob/master/src/ric/24788.c#L260
The first thing the function does is it loads paramsLo and paramsHi.
Then there is an if-statement which takes paramsHi into account.
But in this new function, those variables aren't given values until the
switch statement. This means that in the if-statement, paramsHi is not
initialized and will be undefined. I believe this is a bug, but would
like to hear someone else's thoughts before giving it an official bug
label.
Working in parallel on these two overlays has been hugely beneficial, I
think I will continue to try to do things this way.
I don't think I have any major comments besides that. This code required
more fake stuff than usual in order to make registers agree.
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.
This is a pretty big one!
There are a lot of unknown SFX entries, I'll leave that as a future
thing to work out what all the hex codes for the sounds are.
Pulling in the rodata gave the usual mismatch with 00 bytes, so I moved
the following C file into this one.
Several other changes here and there, this is a fairly large commit so
please be sure to examine it carefully.
I need help on this pull request. While it matches as it is, I cannot
decode the Japanese strings from bytes to UTF-8 convertible into
Shift-JIS into a C file that is able to give me an `OK`. I think the
problem lies on how Python decodes Shift-JIS byte arrays.
I [wrote a
tool](https://gist.github.com/Xeeynamo/d75c73431eaf54b42f955ca8740bb754)
to automate the process:
```bash
python3 sotn_config.py > src/dra/config_jp.c && make
```
To extract some of the strings as Shift-JIS, uncomment the first line at
the function `get_sjis_str`. I am tempted to make a custom decoder. But
first I want to gather your insight in case I am missing something
obvious.
Imports the `D_800C1ECC` table straight into `953A0.c`, so
`ApplyQuadChannelSetting` can populate the fields correctly.
Also removes a fake symbol from `menu.c`, which allows to access the new
merged `g_ChButton` array correctly. This fixes the _"Button Settings"_
sub-menu in _"System"_
The function is not referenced anywhere other than by being exported in
`GameAPI`. I suspect only the LIB overlay uses it. I added a comment
speculating what the function might be about.
Came across this function today and found several improvements for it.
- Unkstruct_800FD5BC is a duplicate of DamageParam. Therefore, I have
changed all instances of Unkstruct_800FD5BC to DamageParam. The fields
make sense in context and everything.
- Because func_800FD5BC is in GameApi, which is defined in `game.h`, its
argument (now a DamageParam) needs to be accessible in `game.h`.
Therefore, DamageParam moves from dra.h to game.h.
- We had a fake division being done with using a `temp` and checking a
comparison to zero; this has been changed to be a normal division. This
is a common pattern I see in initial m2c output and I'm sure it exists
in other places in the repo, would be nice if we could find an automated
way to search for this type of structure to simplify the code.
- Changed a 0x14 to 20 since it makes way more sense that way
- Changed an `if(){dostuff; return} else{morestuff}` to just
`if(){dostuff; return} morestuff`, eliminating the `else`
I think this function should not be in `menu.c` since it has no close
connection to any kind of menu. It would also be nice if we could figure
out what damageKind actually is, and maybe make an enum for it.
Overall, no new decompiling here, but lots of improvement to the
readability of the code. This might actually be a good PR to keep in
mind as an example for people who are interested in the project but
aren't comfortable with assembly, since this is a lot of improvement and
change, without touching assembly at all.
Some deduping and renaming that might help later
- Dedupe DestroyEntity
- Dedupe ST EntityIsNearPlayer
- Dedupe DestroyEntitiesFromIndex
- Dedupe ST CollectHeart
- Dedupe ST UnkEntityFunc0
- Decompile + rename rwrp EntityExplosionSpawn
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.
I noticed that there was a mismatch in the rodata where a set of 4 `00`
bytes was being skipped, and those indicate that these should be the
same file.
This is one of the few remaining sound functions.
It calls `ApplyQuadChannelSetting` and `func_80135624` in extremely
similar ways, so I've adjusted the arguments to those functions so they
match. `func_80135624` should probably get its own name which is similar
to `ApplyQuadChannelSetting`, but I don't know enough about these
functions to actually tell what it's doing.
One of the few remaining DRA functions.
Some of the code here seems fake, but it matches so I'm going with it. I
tried to change all the pointers to use the loop indexing but it didn't
work. Might have been written by a coder who was more comfortable
working with pointers than with loops.
Simple PR that aims to re-use the same `config_us` file from #948 but
for SEL. The file is de-duplicated since it is identical.
The file `lba_stage` has to be split again since in DRA it comes before
`config_us` but in SEL it comes after. That indicates it could have been
a stand-alone file.
I also imported the exp table responsible for levelling up.
Creates the file `config_us.c` with all the configuration needed for the
game to know where to locate files in the disc (previously
`lba_stage.c`), equipments, accessories, menu strings (previously
`lang_us.c`, , spells, relics and enemy structures. There is also an exp
table for levelling up but I did not import it yet.
This is a major change in the codebase on how we handle assets.
Previously they were exported as JSON in `assets/dra`. The main problem
is that strings were not properly compiled, still relying on hardcoded
offsets expected to be found in the `.rodata` section.
I deducted all those information belong to a single C file because the
same strings in rodata were referenced from equipment to enemies. If
those strings are found in the same C file, the compiler will optimise
duplicated strings by de-duplicating them. This is how I reached the
conclusion of having all those definitions in a single file.
Obviously the major pain point of this is that a JSON was much more
declarative and easy to be consumed. Especially if tools were going to
use those files. Counting the commas with the struct definition on the
side is not the best thing for modding.
I had to comment out the HD `lba_stage` as it would require a major work
to support the Japanese text.
I had to merge `2C048.c`, `2D260.c` and `2EED8.c`. The hint was in a
string that had to be in `2C048.c` but it was also used in the other two
files. I couldn't still merge this with `33164.c` due to the same
problem I described in #946 .
EDIT: I kept importing more data. SEL also contains its own `lba_stage`,
but some offsets and OVL size are out of sync compared to DRA. I have
the suspect the table was manually maintained, unlike our _"top class
engineering"_
I spent some time trying to merge `2EED8` and `33164` as the rodata
seems to suggest it. But there is a weird 4-bytes padding that is added
when the file split does NOT happen. If you want to have a look before
merging this, please do.
This is a historical W.I.P. that held me back due to some dirty bytes in
the US version. It is now done.
I renamed the file to `lba_stage.c` as I plan to add another file called
`lba_bin.c` right after this PR.
To quickly build the HD LBA, which is very different, I wrote a quick
script to duplicate and patch the US one:
```python
def s16(f):
return int.from_bytes(f.read(2), byteorder='little', signed=False)
def s32(f):
return int.from_bytes(f.read(4), byteorder='little', signed=False)
with open("disks/pspeu/PSP_GAME/USRDIR/res/ps/hdbin/dra.bin", "rb") as f:
f.seek(0x3C50)
for i in range(0, 0x50):
print(f"0x{s32(f):04X}, 0x{s32(f):04X}, 0x{s32(f):05X}, 0x{s32(f):04X}, 0x{s32(f):04X}, 0x{s32(f):05X}, 0x{s32(f):04X},")
s32(f)
s32(f)
s32(f)
s32(f)
```
---------
Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
