I completely rewrote the cutscene asset handler. Now instead of parsing
the data from the original overlay into a C-like header file, it instead
follows a two-stage process. This works by extracting it in `asset/`
with `make extract_assets`, to then allow modders to modify the file and
build it as a C-like header with `make build_assets`. This also aims to
fix#1701 as the build process takes account of the two-stage process.
I created a framework where each asset type should only make available
the two methods `Extract` and `Build`. The entire transformation process
should be isolated to not create cognitive overload like what we can
find in `build.go`. I would need to migrate all the existing asset types
to properly use this new framework. The old code served well enough to
understand how to build the entire infrastructure, but it needs to be
migrated using the new pattern.
Last, but not least, I renamed `config/assets.us.weapon.yaml` to
`config/assets.us.yaml` as it is now used by all the overlays
This extends upon my work in display_texture.py. I have used this for
identifying a few entities already. display_texture is suited for
viewing prims, while this one is better for entities that are rendered
by RenderEntities.
I think there's enough documentation at the top of the function for
others to use it. Hopefully it can be helpful, especially as it evolves
over time.
At some point this could be converted to an editor in addition to a
viewer, but for now the viewing capability is the core focus.
Also rewrote some of DRA's sprite data (this should probably be in
sotn-assets though) to fit the standard format so that this tool could
parse the data.
Mostly just some light renaming.
I used my new entity animation viewer to figure out what this function
was, it's a very subtle cloud effect that would have been hard to
identify otherwise.
The driving factor for this was removing ext.generic from this entity,
which is also complete.
This applies to both NO3 and NP3.
I was reviewing some of the animations pulled out by sotn-assets.
Speicfically, I found that in `src/st/no3/sprite_banks.h` (a file
created by sotn-assets locally, which does not exist directly in this
repo), we have:
```
extern s16* sprites_no3_0;
extern s16* sprites_no3_1;
extern s16* sprites_no3_2;
extern s16* sprites_no3_3;
extern s16* sprites_no3_4;
extern s16* sprites_no3_5;
extern s16* sprites_no3_6;
extern s16* sprites_no3_7;
extern s16* sprites_no3_8;
static s16* spriteBanks[] = {
0,
&sprites_no3_0,
&sprites_no3_3,
&sprites_no3_1,
&sprites_no3_2,
&sprites_no3_4,
&sprites_no3_5,
&sprites_no3_6,
&sprites_no3_7,
&sprites_no3_8,
```
However, those are not the right pointer types. `sprites_no3_#` should
have a type of `s16* []`, so I reworked the sotn-assets tool to use the
right pointers for each of these things. Now the sprite_banks.h file
looks like:
```
extern s16* sprites_no3_0[];
extern s16* sprites_no3_1[];
extern s16* sprites_no3_2[];
extern s16* sprites_no3_3[];
extern s16* sprites_no3_4[];
extern s16* sprites_no3_5[];
extern s16* sprites_no3_6[];
extern s16* sprites_no3_7[];
extern s16* sprites_no3_8[];
static s16** spriteBanks[] = {
0,
sprites_no3_0,
sprites_no3_3,
sprites_no3_1,
sprites_no3_2,
sprites_no3_4,
sprites_no3_5,
sprites_no3_6,
sprites_no3_7,
sprites_no3_8,
```
Which more accurately represents the data within.
Naturally, since this PR mostly just changes the tool, the real changes
are in the tool's output, so feel free to clone this branch and
investigate the sprite_banks.h file if you want to see anything further
about it.
DRA's equivalent of the SpriteBanks array is `D_800A3B70`, and is
currently in the repo as extracted data, without using `sotn-assets`;
this PR makes it so the types in the overlays (which do use
`sotn-assets`) will match the types in DRA.
I did a find and replace for "unsigned short" to "u16" in the
sotn-assets `build.go` file and the same for "signed short" to "s16".
Then I went through and added common.h imports to fix each of the build
errors until it worked.
Using the numerical types is preferred due to being shorter (reducing
line wrapping), and to be future-proof for any systems where the "short"
type might not be 16 bits.
Nice to get more progress in our "old" stages on those last few
difficult functions.
At the end of this function there is a little switch block which
switches around some SFX; this informed me that D_80097910 holds SFX, so
I went back through the repo for other uses of this variable and made it
use SFX enums. This variable appears to hold the SFX ID for the current
background music. Maybe it deserves a name, but I don't want to turn
this PR into too much of a mess of doing different things.
This is doing a few different things; I'm sort of finding issues and
fixing them one by one. I've found more, but don't want this PR to get
too bloated.
1) Removal of more uses of ET_Generic, and eliminating a few of its
members
2) Renaming EntityUnk15 to EntityGreyPuff
3) Reworking Animset data. It's s16, not u32, so the data in d_2F324.c
has been adjusted to match that.
Spriteparts data is the same between bat and ghost, so I moved them to a
shared header.
If they are different than other familiars, we'll have to rename the
shared header.
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.
Lots of cleanup here to make the code easier to read.
1. Adding CLUT index defines to avoid magic numbers
2. Adding InitializeMode enum and hooking that up
3. Updating function names for servant init
4. Cleaning up magic numbers used in tt_000 init function
I wanted to add a enum for the EntityId, but both servants share 0xD1.
Looking at the other EntityIDs definitions, there seems to be some
crossover, but it also looks like they may be partly unique across the
different binaries. Probably need more study to figure out how to unify
them (or if it's even possible to unify).
We also may want to look at splitting enum definitions and defining
flags/fixed values into some sort of enum file structure. Having them
all in game.h is making a large file. But we would obviously not want to
fracture the codebase more. Either way, that's way beyond the scope of
what I wanted to do here.
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.
