Should have thought of this to begin with!
This makes the script fetch the VRAM while PCSX is running. That way you
don't have to deal with keeping files around on your hard drive if you
don't want to.
A tool I made that allows you to identify some entities based on the
primitives that they create. Usage is documented at top of the file.
Allows extraction of images, which has already been useful in a few
places.
Happy to provide any assistance with using this; it's come in handy for
me and hopefully will be beneficial for others too.
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`.
This was an ugly old function with lots of casts and `ext.generic`. I
found an identical function in NP3 and copied it out.
I left a comment in the other file about this, for the sake of future
potential de-duplication. For now, at least both functions are modern.
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.
This is my attempted decompilation of the leather shield, but the return
type mismatch makes it fail.
Scratch here (matching, by using s32 return type):
https://decomp.me/scratch/SN7d3
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.
Might try replacing the clut with actual 16 bit colors. Is this the
right macro to use?
```
#define COLOR16(r, g, b, a) (r) + ((g) << 5) + ((b) << 10) + ((a) << 15)
```
