Improved PR compared to #1704 .
We decided that unkB8 shouldn't be part of the Ext since it appears to
apply to all entities.
Also discovered some issues with the ET_GurkhaHammer struct, so resolved
those as well.
Now all accesses to the unkB8 offset go directly to `self->unkB8`.
Unrelated to all this unkB8 stuff, I found that there was an extra C
file in DRE which was not being used. Its code had been moved to
succubus.c, and it looks like the original file was accidentally left in
place. I deleted it here.
Accurate for PSX and PSP
PSP scratch: https://decomp.me/scratch/lZHti
Some of these global variables I've figured out, but I am planning on
doing a refactor of tt_001 next and will rename the vars there.
Adds the CEN overaly to the HD version of the game.
Resolves#1638.
This uses most, but not all, matching functions. Some were excluded
because due to symbols mapping that has not bee completed yet.
Not all data has been imported, and mapping symbols, and data should
make many of the remaining functions easy to import.
Ran my code for this function against the PSP assembly and fixed a bunch
of places where it didn't match.
It's pretty close now, but still missing a bit. I think it's mostly
around the number of parameters and the number of temp variables as it's
mostly all in the stack push/pop.
Also removing unnecessary casts.
Scratch
https://decomp.me/scratch/0Gm3x
Primary goal here was to eliminate `ext.generic.unkB0`. It turns out
that the only entity that reaches up into this unkB0 region is the
Subweapon entity.
I went through and changed these all to `ext.subweapon.subweaponId`, but
also did some analysis on all the uses to make sure this was an accurate
change to make.
Other highlights:
- Naming CheckSubwpnChainLimit and its RIC counterpart
- Moving the RIC version of that function to the next file, split makes
more sense this way.
- Made both versions of that function `static`
- renamed subweapondef's unk6 to be chainLimit
- Changed g_unkGraphicsStruct.unk0 to be called `pauseEnemies`. It's
true when the stopwatch subweapon is used, and in cutscenes. Found this
due to looking at the stopwatch subweapon setting this value. Also made
it a bool since it's only ever used as a bool.
- Added some playersteps enum uses where they were still using hex
values
- Studied RicEntityStopwatchCrashLightning in order to give it that name
I think that's about it. Overall just some modest cleanup, but continues
to make the game code more readable.
Decompilation of func_us_80171864
Adding ET_Ghost for the Entity.ext union.
Thanks to @sozud for setting up a PSP environment for me.
Thanks to @joshlory for figuring out the last bit.
This adds this overlay to the project.
Importantly, we use a new tool (tools/auto_dedupe_new_overlay) to
process the new overlay and automatically split its C files according to
known duplicate files. As of now, this does not do any decompiling (the
whole overlay is kept as INCLUDE_ASM), but it automatically does all the
file splits and code copying needed. Hopefully this reduces some amount
of duplicated work.
To be clear, this new script is not in any build chain, but is meant to
be used after `make-config` to take the overlay from being a single
giant lump of `us.c` to being individual files, for the sake of easier
deduplicating. It will likely need some revision for future overlays,
but at least it should be a good start toward reducing tedious work.
I'll leave this overlay in place like this for about a week in case
there are any newcomers who would like to try de-duplicating some of
these files and decompiling the new functions; after that week I'll get
into doing things myself.
Main motivation here was to eliminate `ext.generic.unkB2`, which no
longer exists and has been removed from the struct. While I was at it, I
modernized the holy water function.
The argument is "self" instead of "entity"
We use FIX() where relevant
Function is adjusted to match on PSP
Variables are renamed
Factory calls are commented
I think those are the main highlights. Mostly small stuff, but
everything comes step by step.
Minor follow-up to #1686 . I couldn't de-fake the g_Dialogue symbols in
ST0 like I did with `src/st/dre/bss.c` due some functions that are not
yet fully decompiled.
Various small cleanups on this function.
In the past it was EntityStrongWarg, but I found that this is actually
the Fire Warg.
It is unused in NO3, but is used in RNO3.
Also removed a Multi that was being used that applied across two
different entities.
Various comments, cleanups, renamings, etc
Thought this was going to be more work as duplicate report had it at 93%
and with a jump table, as it turns out I think they're the same besides
a single global memory address
More research on how cutscenes work.
I normalized all the various C files as `cutscene.c`, marked all the
isolated function as `static` and renamed the main entity as
`{STAGE}_CutsceneExec` (e.g. `CEN_CutsceneExec`). I am using the
`OVL_EXPORT` to automate the names.
TO-DO:
- [x] Rename entity as `{STAGE}_EntityCutscene` for consistency
- [x] CEN
- [x] DRE
- [x] NO3
- [x] NZ0
- [x] ST0
- [x] MAR
~~SEL~~
The offset of the portrait data seems to be hardcoded. I have no idea
how to resolve these offsets at compilation time. The entire cutscene
script thing is very sketchy and horribly designed by the original
developers. What a nightmare to integrate into our project.
This is how a cutscene script gets decompiled:
```
LOAD_PORTRAIT(0x80188D8C, 0),
SET_PORTRAIT(1, 0),
SCRIPT_UNKNOWN_11(),
PLAY_SOUND(0x37B),
WAIT_FOR_SOUND(),
SET_SPEED(4),
'T','h','a','t',' ','v','o','i','c','e','!',' ',
SET_WAIT(16),
SET_SPEED(3),
'A','l','u','c','a','r','d',',',
LINE_BREAK(),
SET_WAIT(16),
SET_FLAG(2),
'i','t','\'','s',' ','y','o','u','!',
SET_WAIT(48),
NEXT_DIALOG(),
```
Had an idea, not sure if this is useful or not but I figured it might
help give an indication for newer people or those not in the Discord
loop if code is already duplicated when looking at the function report.
Here's an example output from the current state (minus the scratches
which didn't seem to load for me locally so I skipped them)
[functions.md](https://github.com/user-attachments/files/17162454/functions.md)
@bismurphy guessing this would be your area of expertise 😄
![image](https://github.com/user-attachments/assets/49a89a56-0328-4428-8abb-c0cbc95135c9)
`CutsceneUnk2` uses 8 prims but only 7 are allocated. It looks like at
some point the game writes to the address `0x00000000` but I did not
confirm it with a PS1 debugger. This is a potential bug. `CutsceneUnk2`
signature was also wrong.
I had to get rid of `GfxBank` in `src/st/cen/header.c` and I probably
need to do the same for the other header files. The code reads chunks of
WORDS at the time and a structure would be too large to include
`GFX_TERMINATE` in it.
CEN is there but not linked because it conflicts with some WRP symbols.
I decided to take a much simpler approach compared to what I did with
WRP (which needs to be refactored later on).
There's a cutscene parser. The asset manager is exporting it to
`src/st/cen/cutscene_data.h` if you want to have a look. I know I am
still using `config/assets.us.weapon.yaml` and it probably needs to be
renamed as `config/assets.us.yaml` later on. I am still deciding.
* `ProcessEvent`
* `CreateEventEntity`
* `CalculateAngleToEntity` (the function formerly known as
func_80173F30)
* `GetTargetPositionWithDistanceBuffer` (the function formerly known as
func_80173F74)
There's 4 more duplicates which I'll start on separately so as to not
make this PR too big.
Decompiled libgpu SetDrawEnv
This function actually packs some of the short length fields from a
DRAWENV struct into DR_ENV struct code fields, which are longs.
IE dr_env->code[7] gets packed with env->clip.x in the hi 2 bytes and
env->clip.y in the low 2 bytes.
Perhaps DR_ENV should actually be PACKED_DRAWENV.
Co-authored-by: sozud <sozud@users.noreply.github.com> (main
decompilation)
Co-authored-by: dezgeg <dezgeg@users.noreply.github.com> (getting it
across the finish line)
Did my best to give contextual names where possible based on surrounding
code.
There's still some remaining ones where it wasn't clear what the entity
was referring to so have left some as is.