I documented all the `PLAYER.step` for Richter and got the meaning of
most of the functions with their parameters. There are some additional
renaming and magic numbers documented that are not worth to mention
individually.
I plan to get rid of `EntityTypes` as it is not sustainable to document
256 combination of entities. Instead I am thinking it would be a better
approach to document the `g_Entities` indices as ranges. For example
from `32` to `47` we have particles, from `48` to `64` we have player
entities that can hit the stage entities and so on.
I re-organised and re-imported some of the data close to the function
that use them. This will allow me to later split entities into their own
units as separate C files.
In addition to decompiling the function, two big changes were needed:
- Decompiling this function uncovered a maspsx bug with generating `nop`
padding instructions; that is now fixed and this PR includes a maspsx
update.
- We also discovered (thanks @mkst !) that g_Tilemap.bg was not actually
a member of g_Tilemap. I renamed it to g_BgLayers, and did a
find-and-replace across the repo to change all references. This appears
to have no impact on any existing function, but leads to the correct
register loading on this function.
It's a weird one, and was tricky to get matching (actually, this was a
super old decomp.me browser tab I discovered was still open, which is
why I came back to it), but these tricky ones are great for discovering
where we have mistakes in our structure of the game's data.
This one was already pretty good, but mostly needed to have
`ext.generic` removed.
I noticed the structure of this file is identical to e_bone_scimitar, so
I decided to change the bone scimitar to use this Skeleton `ext` since
the skeleton is a more generalized enemy. Now that we see two enemies
both using this one, this almost looks something like object
inheritance, if that were a thing that existed.
So far NZ0 is the only overlay with the skeleton enemy, but I'm sure
once we pull in other overlays we'll find more skeletons all over. Then
this will be a .h file, but for now it's a normal .c file.
This file was all decompiled, but overall had a lot of "old-looking"
traits to it. I went through and updated it in many ways. All the
functions are now named with real names (no `func_whatever`), several
constants are used in different places, I've added names to the list of
entity ID numbers in the .h file, etc.
One thing of interest: I went through starting to document the `.ext`
members, and noticed that they seemed to "keep away" from each other,
even across unrelated entities. Therefore, at least for now, I decided
to create an experimental `ext` which covers all the entities that
needed defining in this file. Maybe down the line we can split them up
to their own individual entities, but I find it interesting that some
entities use the unk80, unk84 offsets, while others only use unk88. I
don't see why you would skip to unk88 unless unk80 and unk84 were taken,
and the only way they're taken is if they share ext members.
The big thing is that nothing uses generic anymore. It looks like this
file was from the era when we were trying to use generic for everything
so there is lots of ugly casting, but that's all gone now, which is
nice.
A minor PR that only aims to give a meaningful name to two of the
unknown variables in the `ET_ZombieSpawner` struct:
- `spawnDelay`: Number of frames until the next time the Zombie Spawner
will attempt to spawn another zombie
- `spawnSide`: Which side of the player the Zombie Spawner will attempt
to spawn the next zombie (zero for left, non-zero for right)
Renamed `PLAYER_ext_generic_unk7C` to `PLAYER_ext_player_anim` since we
know the player entity is being referenced.
Added a size comment to `WeaponAnimation` to help me find it next time
I'm looking for an `0x10` sized struct.
NO3 and NP3 had a weird mix of Bone Scimitar functions where each was
partially complete and missing different parts.
Now both are complete and modernized. Could use another pass to make it
PSP-matching, but for now I'll leave this one at this point where the
code seems nice.
Next one in my progress of removing `ext.generic.unk88`. This one is
duplicated two places; once we have NO3 and NP3 matching it will be cool
to de-duplicate them and see how many differences are actually left.
Main changes here involve renaming the Ext member from `et38` to
`wargpuff` which seems more descriptive.
Also added entity ID numbers across the overlays, to be used in the
function right before the warg puff function, which spawns the warg
puffs with a call to `CreateEntityFromEntity`.
Lots of little changes here. Getting away from using `ext.generic`,
using various enums/macros, using `prim` instead of `POLY_GT4`, making
variables have useful names, etc.
Also, these functions both match on PSP now.
One interesting thing is that these functions don't overlap in their use
of the `ext`, so I had them share one. Kind of interesting.
`#ifdef` ugliness, but there is not much we can do if some of the `ext`
structs use 64-bit pointers. With _Static_assert we can ensure, at
compile time, that structs are aligned for `g_api.PlayAnimation` to work
correctly.
I removed a bit more of `ext.generic` here and there too.
cc. @bismurphy our weapon blacksmith xD
- Rename func_801733D4 to BatFamiliarBlueTrail
- Add PSP symbols for several various variables used in `func_80172120`
- Attempt to get `func_80172120` closer to matching on PSP. Almost got
it but not quite working; this is at least an improvement. Scratch:
https://decomp.me/scratch/QBytP
- Create `Ext` for BatFamiliarBlueTrail; all it uses is the parent which
is the same as Factory, but still better to have its own until we know
the real situation for entities.
- General commenting to make flow of functions clearer.
Copied the `EnttityMerman` and `EntityMerman2` implementations from NP3
to NO3. These are identical, however, rely on too many things which
require renaming to share at this point.
NO3's `EntityMerman2` was previously `EntityMerman3`, but is identical
to NP3's Merman2, so it was renamed to match.
A small amount of cleanup was done to the implementations to bring them
closer to current standards.
Got away from using `generic`. Only two fields are used, but unk8C was
taken in the main Vibhuti crash, so can't reuse it.
Trying to start using the `s32 : 32` syntax to indicate unused fields
moving forward, may help with figuring out how to handle the problem of
`Ext` and its mysteries.
This is a proposal on how I would like the naming scheme going forward
for the player. The proposal includes the naming and layout once we
document Alucard and decompile Maria (PSP). Please let's agree on naming
and structure so it can be easy to hack and plug new custom characters
at any time.
* Animations to have `XXX_anim_yyy` where `XXX` is three letters for
`arc`, `ric` or `mar` (`arc` taken from `BIN/ARC_F.BIN`). To mark them
`static` whenever it is possible to do so.
* `PL_S_xxx` to mark a player step. Steps might be similar between the
three different players, but they must be isolated into the respective
headers `dra.h` for Alucard, `ric.h` for Richter, `mar.h` for Maria. I
am aware that Alcuard steps are used in weapons, which is why they are
currently found in `game.h`. This needs to be addressed at some point.
* PL_T_xxx` for the various timers from `g_Player.D_80072F00`. Those
_might_ be need to be shared between all players, we need more research.
* `XxxHandleYyy` for the step handlers. You will see `RicHandleJump` to
handle `PL_S_JUMP`.
* `XxxSetYyy` for the functions responsible of transitioning into a
specific step (see `RicSetJump`)
Prefer imperative verbs than paste tense or anything else. So `dead`
instead of `killed`, `run` instead of `running` and so on.
Functions and animations have `Ric` or `ric_` pre-pended since those
symbols are publicly exported and not marked as static. But `#define`s
and `enum`s that are isolated into the player's header should be
generic.
I cracked the animation system, so I created the macros `A_END`,
`A_LOOP_AT` and so on.
In a next pull request I will change `Entity::unk4C` into
`Entity::anim`. I did not want to include it here to not change too many
files in one go.
Just some symbol renaming; this is a big task and will probably take
lots of research to work out how all the different interwoven systems
work, but this is some starting steps.
I'm going through to find uses of Multi structs and remove them since
they are bloated.
ObjInit2 was using a Multi16 on its unk4 member. Surprisingly, there was
no ObjInit already, so I made the following changes:
1. ObjInit2 is renamed to ObjInit, and uses a u16 in its unk4 position.
Since this gets assigned to unk5A in an entity, it's called unk5A (we
should really figure out what Entity.unk5A is...)
2. We create a NEW ObjInit2 which instead splits up unk4 into the two
fields of facingLeft and unk5A. This version is very rarely used in the
repo.
3. We cleanup some init data which is used as the new ObjInit2 struct.
This is actually what I was initially going for in my previous PR.
g_zEntityCenter was almost always used as an s32, but some of the
duplicates of e_collect which were scattered across overlays had weird
misuses that acted like it was s16, which necessitated the use of the
Multi.
Now that e_collect is unified across overlays, we can make this data
field a proper s32. Nice!
The only change made in this PR is the type of this variable, and a
find-and-replace to change it to not need to access the .unk element of
the Multi struct anymore, since now it's just a bare s32 (but still
contained in the unkGraphicsStruct of course).
Maps `create_entity` and `e_collect` data, text, and bss for all stages.
Adds macros for defining padding for various sections by size.
Tables for section sizes have been added to common includes to make
calculating offsets easier when segments.
This change moves BSS variables into their most appropriate compile
unit, "decompiles" several data files, and splits out some existing data
into its logical unit.
BSS data has all been removed from `bss.c` and moved to a file where the
data is either first used or where it can be made static.
Several data files have been converted to appropriate types and added
to the most appropriate file. This converts the header related
references and some of the other early data.
Finally, some data like has been rearranged and moved into logical
compile units like data from `entity.c` into `holyglassescutscene.c`.
Logical boundaries were chosen based on where data could be made static.
A follow-up to #1473 where I imported the whole BSS section by
respecting the symbol offset but ignoring their actual type. The work
here consists into checking all the almost 500 symbols in DRA one by
one. Each type in `bss.c` will be changed to respect the one actually
defined in `dra.h` and document the file that actually holds reference
to the symbol. If the symbol is only used in one file it will be removed
from `dra.h`. Once the work is done I am planning to get rid of
`src/dra/bss.c` and have each file to hold the reference.
The reason why I created `dra_bss.h` is because when GCC does not order
BSS by how they are declared, but when it finds them first in the code.
So doing `extern s32 b; s32 a; s32 b;` will order them as `b` then `a`.
`dra_bss.h` needs to not be included in `src/dra/bss.c` but all the
structs and enums should.
Tons of fake symbols have been addressed as part of this PR.
* forward declaration for `struct Entity` prior to `PfnEntityUpdate`
* definition guard around `VERSION_PC` in `pc.h`
* various libc includes to avoid implicit signatures
* `const` string arguments to avoid dropping a const qualifier
This cleans up most of the warnings from the cmake build. There are
still a few from `libgte` and one more `const` to mutable assigment but
most have been resolved.
By looking at how the gold pickup sfx are handled using `#ifdef`, I
chose to do the same thing here with swapping the sfx references in
`e_red_door.h`.
`SFX_METAL_CLANG_E` is the only sound effect that seems to be the same
between MAD and the final collision handler.
We've hit the first beta sound ID `0x640`, which is the old door open
sound effect (final is `0x642`). How do we want to implement the beta
sfx IDs in the enum?
Most important note on this one is that it uses the 0xA0 entity offset.
We already had `shield.unkA0` being used in a different shield. However,
on this shield it's accessed as a half-word, while the other one
accesses as a word.
I looked into it a bit, and realized that the other shield uses it as a
change in Y velocity, and ET_Weapon already uses 0xA0 as an
accelerationY. Therefore, I changed that shield to use ext.weapon for
that entry, and this allows us to change Shields to use 0xA0 as a
halfword.
In general, it looks like shields use a mix of the normal ET_Weapon and
the specific ET_Shield. Maybe we can work out what's what at some point
in the future, especially once all the weapons are done and we can start
truly digging into the purpose of every unkXX value in there.
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.
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.
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.
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.
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.
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.
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 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 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`.
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.
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.
This is a big messy function, but it's decompiled!
Did what I could to rename variables in a useful way, but I could only
get so far. Hopefully one day we can work out exactly what all the
different angles, XY variables, etc are. But this is one of the biggest
remaining functions and it's great to have matching.
This is a relatively unimportant function, but it messes with some
variables that I am interested in learning more about, so I went ahead
and compared it to the PSP version.
This PR incorporates some lessons I learned from that PSP version. Most
importantly, the rotPivotX and rotPivotY in Entity are signed.
I also tracked down how this entity is created, it's a bit odd since it
doesn't call any entity creation function, and instead does a direct
write into g_Entities to create it.
On exit, this function calls `func_8012C600`, which I will be doing a
similar analysis for next.
There was a leftover rodata padding that doesn't do anything, so I
removed that too.
Decided to target this one since it's the largest remaining function in
`weapon` and now it's done. Kind of surprising that such a simple weapon
has such a huge function, but I guess it has a lot of graphics and
therefore a lot of primitive manipulation.
This aims to deprecate all the Splat tools in `tools/splat_ext` in
favour of a more centralised asset manager. This brings the following
advantages:
* Much faster extraction
* Faster build
* Automatically define `static` symbols or unique names whenever
`static` is not possible
* Allow to embed assets into the output binary
* Drastically simplify `Makefile` by removing all the asset build rules
* Avoid situations where it is not possible to extract and build assets
that is not 4-byte aligned
This is achieved by having the splat YAML targeting a normal C file as
data and have an external tool to take care of the following:
1. Extract asset files straight from the overlay binary file into human
readable file in `assets/st/STAGE_NAME`
2. Build assets as header files that go into `src/st/STAGE_NAME` to just
include them from any C file
This requires each stage header to have the following new format: please
see `src/st/nz0/header.c`
Built assets in `src/st` are ignored by Git.
As for now, for simplicity sake, the steps `make extract_assets` and
`make build_assets` are just executed within `make extract` exclusively
for the US version.
I plan to auto-generate files such as `src/st/nz0/tile_data.c`.
For a first iteration I am aiming to handle the following:
* [X] Extract rooms: `assets/st/*/rooms.json`
* [X] Extract room layers: `assets/st/*/entity_layouts.json`
* [X] Extract tilemap data: `assets/st/*/tilemap_*.bin`
* [X] Extract tilemap definitions: `assets/st/*/tiledef_*.json`
* [X] Extract sprites: `assets/st/*/sprites.json`
* [x] Extract entity layouts
* [X] Build rooms: `src/st/*/rooms.h`
* [X] Build room layers: `src/st/*/layers.h`
* [X] Build tilemap data: `src/st/*/tilemap_*.h`
* [X] Build tilemap definitions: `src/st/*/tiledef_*.h`
* [x] Build sprites (aka `g_SpriteBanks`)
* [x] Build entity layouts
* [x] Allow the tool to suggest how to adjust the Splat config for each
overlay
I want the tool to cover the following stages:
* [x] CEN
* [x] DRE
* ~MAD~ I do not think this can be done, it is way too different from
the other overlays
* [x] NO3
* [x] NP3
* [X] NZ0
* [x] ST0
* [X] WRP
* [x] RWRP
* ~WRP (PSP)~ Maybe in a follow-up PR
For a later iteration I plan on extracting and build:
* Entity GFX thingie
* The CLUT thingie in the header
* Uncompressed GFX data
* Cutscene data
* Blueprints
* The `src/config_us.h` thingie
---------
Co-authored-by: Josh Lory <josh.lory@outlook.com>
Got this working with the aid of PSP!
Scratches here:
PS1: https://decomp.me/scratch/FDWxW
PSP: https://decomp.me/scratch/SObUR
These are identical aside from the versions defined at the top of the
context, and everything else is done with `ifdef`.
Several of the `ifdef` differences are in structs that are defined in
`include/psxsdk/libgpu.h`, and since they're in the PSX SDK, I don't
want to add those PSP differences into that file. I imagine at some
point we'll have a PSP libgpu.h or something, but until then, this
function will not actually match on PSP. But since PSP is not the focus
of this decomp, I think that's okay.
This is 99% similar to Xeeynamo's scratch, the main difference is the
treatment of the lines that look like `setSemiTrans(&primbuf->g2,
var_s0->drawMode & DRAW_TRANSP);`.
Finishes the heaven sword.
More weirdness with the ext - it appears that unk84 is used differently
in different functions within this value.
Overall, this file could use some improvements, but to start out, having
it decompiled is better than not. Hopefully someone can figure out how
this actually all works.
This one is kind of ugly in places.
It uses offset 0x84 as an s32, while Weapon uses it to hold an entity,
so this forced the creation of a new ext for the heaven sword.
There is only one more function left in this file (EntityWeaponAttack),
so once that one is done, I will move the whole file over to use the
Heaven Sword extension.
Decompiles stage header data for all in progress stages.
Of note is that NO3 and NP3 (and likely other future stages) use an
`AbbreviatedHeader` because their `SpriteBanks` start immediately after
`UpdateStageEntities`. There are several areas which use
`sizeof(Overlay)` to copy this data over, in those cases sprite bank
data is copied into the tail fields of the overlay but are never used.
This reworks enough writes to libsnd/libspu to make it through the call
to SsInitHot. Instead of raw pointers we have read/write_16 functions.
The writes are saved to an array so we can test against output from
mednafen. See `src/pc/psxsdk/expected/_spu_init.txt`. The gold file is
generated by running a real psx psy-q program that calls the same
function. A modified mednafen prints the writes. There are reads to
spustat and other regs that require particular values to be returned, so
I've also imported and hooked up the SPU part of mednafen.
Not a very difficult one, but it's a little weird. Not sure what this
entity is, it's modifying the GPU buffers directly, and also setting a
castle flag. No other uses of that castle flag as far as I can tell, so
who knows. Once the overlay is complete we can have the full picture to
figure out where this entity even comes from.
