1. Give a name to the variable `g_PauseAllowed` - this is a bool which
gets tested when we're also testing for pressing START or SELECT to open
the menu or map, so to me it seems like it's flagging whether or not you
are allowed to pause. It is normally 1, but gets set to 0 at the start
of cutscenes, and then restored to 1 at the end of them.
2. Name LAYOUT_RECT_PARAMS_HIDEONMAP, which is relevant for item 3 on
this list. I already used the HideOnMap name when setting up this flag
in the assets handler in my previous PR.
3. Name `g_canRevealMap` - this is a variable that is normally set to
true, but for some particular rooms in the game, it's set to 0. Those
rooms will not appear on your map. Good examples include the forest area
left of the castle gate (the first moment we see Alucard), and the DRE
stage. This variable gets set to 0 if the LayerDef has the
LAYOUT_RECT_PARAMS_HIDEONMAP flag set.
4. Deduplicate a common structure in the code where entities have a
debug routine that lets the Player 2 controller control the behavior of
the entity. By pulling this out, the code can be more concise. Most
importantly, when searching the codebase for g_Pads[1] (which is an
interesting thing to do, since we're looking at uses of the Player 2
controller in a single-player game), you can focus on the interesting,
unique examples, rather than having a ton of copies of the same exact
code.
5. Change all instances of `g_Pads->` to `g_Pads[0].` A minor change,
but good to use a formatting which makes it clear that g_Pads is the
array of both pads, and not a pointer to one.
6. A couple functions I noticed with obvious fake stuff (including a
do{}while(0)) have been adjusted so that they will match on PSP.
Naturally, this also meant removing those fake things, which is always
nice.
Overall, this is several small changes combined into one PR; honestly I
just scrolled through the codebase for a while, finding things that made
me think "I know a way this could be better". Others may disagree with
some of these though, happy to take input, especially on the new names!
updating global api function func_8011A3AC with a better name. It
fetches the current familiar stats from the global game variables and
will also fetch an attack descriptor if ID is provided.
Refactoring names for ET_Bat that I forgot to update in my last PR.
Remaining unkXX vars appear to be unused.
Adding enum for g_SpellDefs table. Some familiar attacks appear to be in
that table as well as Alucard's spells. Some do not such as the bat's
fireball.
A small refactor renaming a global variable for when the cutscene has
control of the engine.
In servant, it short cuts the main update function so that your familiar
isn't doing stuff while a cutscene is running.
Also some flag cleanup.
I've figured out quite a bit with the functions and how they are called.
It looks like most of the functions in ServantDesc are actually update
functions called by using the entityId as an offset. I want to update to
make that more clear, but I want to isolate that into it's own PR and I
already had this refactor in flight.
Not a big PR. The highlights are `g_Player.timers` and
`entity->hitParams`. The last one is a bit weird as it looks like a mix
between `attackElement` and `hitEffect`.
The `var_s4` on `RicMain` is uninitialised and it leads to an undefined
behaviour. Recompiling the code for PSX by moving things around, that
variable will not be `0` at the beginning but some random value. This
prevented Richter's run, blade dash and high jump to work. I added an
`#ifdef` in case people wants to mod the overlay.
This is probably the last batch of changes for RIC for a while.
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.
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.
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.
Kind of a complicated process to get this one working, beyond the normal
function decompilation.
Files are split for now, because there are weird things with rodata. I
have already done the two remaining Gurkha functions, so my next PRs
will pull those in and will end up bringing the files back together.
Messy things here, tried to make it looks nice but as always, feedback
is appreciated.
Still work in progress. I removed splat as a submodule and started using
it as a pip package instead. Everything is matching but the memory card
icons part in both DRA and SEL. I still have no idea what the issue is.
Once this PR is good to be merged, we can get rid of the splat fork too.
This adds some additional context for func_801B9744 and renames globals
to fit their assumed purpose.
Migrated various stream metadata to C definitions.
The makefile changes add a dependency on `sel.h` to all the objects that
get built from the `st/sel` directory.
Co-authored-by: Jonathan Hohle <jon@ttkb.co>
This took a few hours of research spread across a few days. A few
take-aways:
`.ext.weapon.anim` and `.ext.player.anim` are both on `0xAC` and they
NEED to stay aligned since they both call `PlayAnimation`, which
operates on `.anim`. I double-checked `EntityWeaponAttack` and the param
entity is definitively not `PLAYER`, despite `.anim` being in the same
offset. I did not encounter a single `.ext.generic.unkAC` that is not
related to animations, so this can be a pretty strong clue of a pattern.
I have this theory where not all the area of an entity from `0x7C` to
`0xBC` is reserved, but just from `0x7C` to _at least_ `0xAC`, with _at
least_ the last `0x10` bytes are part of a shared struct among all
entities.
```c
/* 0x7C */ Ext ext;
/* 0xAC*/ u8 anim;
[...]
};
```
I want to collect more proof before proceeding to mass-rename
everything.
I learnt what `g_Player.pl_vram_flag` is actually doing. It holds some
kind of state of the player towards the map collision. It holds a bunch
of flags that helps setting the animation. I still feel not confident
enough to create `#define`'s for it until we know more.
All the `condition = ((g_Player.pl_vram_flag & 0x20) != condition)` got
rewritten with the following:
```c
atLedge = 0;
if (g_Player.pl_vram_flag & 0x20) {
atLedge = 1;
}
```
the `atLedge` adds up to the `anim` function. The animation table
essentially have one ID after the other where the first holds the Anim
ID when the player is not at the ledge and the next one where it is. For
example: `[ANIM_STAND, ANIM_STAND_ATLEDGE, ANIM_ATTACK,
ANIM_ATTACK_ATLEDGE]`.
`D_800ACF4C` and `D_800ACF54` are some kind-of animation helpers when
Alucard either stands still, jumps or falls. I burnt the values in
`stubs.c` while we wait for importing the remaining DRA data.
Thanks to @sozud for the hint and @bismurphy for the refactoring idea.
The function `PreventEntityFromRespawning` on PSP hints that the struct
starts 8 bytes earlier. Also there's a missing `nop` at
`PreventEntityFromRespawning`, suggesting the function had to be moved
to the previous function.
I noticed that this struct had some overlap with other values in memory,
so I have pulled all those values into this struct.
The boundaries of this struct are uncertain and are a matter of ongoing
research.
Discovered in #1167, where when the player approaches the red door it
forces the input. The line `g_Player.padPressed = g_Player.padSim;`
makes it even more obvious.
This needs to be rebased upon the other PR, otherwise it will break the
build if merged.
Based on their use in the game loop and during stage updates, it appears
the renamed variables store the scroll position delta for the current
loop and store off the current position for future delta calculation.
These vars are then used by stage code to determine if any entities need
to be created or destroyed based on the new position.
This thing here. Special thanks to @sonicdcer who helped me on the final
reg swaps!
I renamed `D_8003C104` as `g_ClutIds`. I am not a fan of the name, but
it gets used by `poly->clut = g_ClutIds[xyz]`, the function that
populates the table is called `GetClut` and the [official
docs](file:///run/media/xeeynamo/wd_black/SDK/sony_ps1/psyq_sdk/DOCS/LIBREF46.PDF)
mentions _Calculates and returns the texture CLUT ID_ . So that seems to
be the most appropriate name.
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
There were some symbols overlapping with the `g_Entities` array. By
fixing them I also de-faked `func_801B519C`. I included the removal of
`g_api_AllocPrimitives` too as I did not see much point of doing it in a
separate PR.
I am still unsure of the size of `g_CastleFlags` and unfortunately I
doubt it will be clearer before start decompiling new stage overlays.
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.
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.
Loops in EntityAlucard and UpdateEntityRichter indicate that these 16
elements of g_Player are an array of 16 values. The known ones appear to
be player status effect timers.
While those functions have a long-standing issue preventing them from
matching, they provide enough evidence to suggest that we should make
this change. I have changed all existing uses, and changed the symbols
so that any remaining non-decompiled functions will use the proper form.
It would probably be beneficial to make an enum for the 16 elements of
this new array, but I'll hold off on that for now until we can identify
the purpose of more of them.
---------
Co-authored-by: Luciano Ciccariello <Xeeynamo@users.noreply.github.com>
Remove a bunch of fake symbols that were overlapping with `D_80097488`.
I created a new struct called `Pos`. Since it is very similar to
`Camera` I placed them close-by as in future we might want to merge
them.
I created some symbol hints like `D_8009748A_x_i_hi` as there are a few
functions that still use them.
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.
This appears to generate the menu that appears when you use a save room.
This is obvious by the strings present in the many calls to
`func_800F9D88`.
Appears to be closely related to some other functions which may make the
logic a bit more obvious. Cool to have this working though, might be
useful for some types of research into how saving works. I wonder if all
these messages have actually showed up before for real players.
Many of the strings feature Shift-JIS characters (specifically, the
periods, question marks, and the 0, 1, and 2 numerals). Big thank you to
Sozud for helping me understand those weird bytes in the strings!
Parsing rodata for strings is pretty fun!
Happy to change the name of this function, but wanted to at least
replace the numerical placeholder.
