To easily bypass the SEL screen or change settings without having to
recompile the code or keep code changes locally just for testing. I also
hope this will be expanded in the future to perform automated tests,
like simulating the input in a determined stage+player and catch
regressions.
As there are breaking changes on the command line, I decided to also
rename the executable name. Having arguments like `--disk <path>` or
`--test <name>` will also allow us to be independent from positional
arguments, which can be complicated to maintain as they will
consistently introduce breaking changes.
Demos:
```
./sotn --stage wrp --player ric --disk disks/sotn.track2.bin --scale 6
```
```
./sotn --test sndlib
```
Refactoring tt_000 for naming functions and variables.
May have to touch tt_001 for some bits as I come across similar
patterns.
This is about the half way point of refactoring tt_000. A lot of the
pseudo-shared logic and variables between this and tt_001 are done. Most
of what is left is bat entity specific behavior.
Fixed some uninitialised pointers / return types which affected a few
things at runtime - pressing down button on main menu and leaving
through door.
Fixed some build errors with WANT_LIBSND_LLE due to unnamed parameters
in implemented functions.
Fixed some externs for WANT_LIBSND_LLE support with MSVC - should be
compiling and running now.
This PR does:
* Do not fail the `extract-assets` job on forks
* Fix warnings and certain warnings as errors
* Build with a combination of gcc and clang with debug and release
Cleaning up variable names and function names.
Cleaning up ET_Ghost ext names.
A lot of changes in here, but it's all just renaming mostly inside
tt_001. I also changed out hard coded hex values for decimal values
where it made sense to do so (such as frame counts for some of the
animation).
Notes for `no0`:
* `unk_collision_func4.h` is not used here
* `unk_recursive_primfunc_1` and `unk_recursive_primfunc_2` and their
associated data are not used here
I've stage def'd these out of the shared `e_misc.h`... not sure if this
is going to lead to messy shared headers going forwards if we have to
keep doing this for other stages
This one is so dang weird.
It needs to access fields in g_Dialogue which do not match up at all
with the g_Dialogue struct. And it accesses some other elements
normally, but they show up at the wrong offsets. It's like this one
function uses a different g_Dialogue struct. I really don't know what to
make of it. Other files in ST0 use normal g_Dialogue, but this one is
bizarre.
I went ahead and created an ifdef variable to use to handle this, and
that's baked into g_Dialogue, but man. Very weird and yet another thing
I haven't seen before in SOTN. ST0 is such a weird beast. Feels like
it's from a beta build of the game.
I've stuck with EntityRelicOrb and D_us_801C141C, but all other
functions is factored out
#define HEART_DROP_CASTLE_FLAG 0 set to dummy value, I don't know how to
get right value yet
Reorganizing tt_000 to be in line with organization of tt_001
Files that start servant_ are shared data.
Files that start bat_ (or ghost_ in the case of tt_001) are specific to
that familiar.
Adding ghost to build list
In order to get the build to work, I needed to mark all of the shared
functions between tt_000 and tt_001 as static as it was causing linking
issues. Because of this, I needed to combine the two C files for tt_000.
Probably want to look at splitting those up into servant specific and
shared, but for now, I just wanted to get this working.
The issue was msvc didn't like that we were declaring a static function
that was not being implemented because part of the shared functions were
being implemented in another file. There may be something we can do with
function declarations to clean that up if/when we split it again, but I
don't know enough about C static functions to figure it out.
As named in Discord conversation.
Gives a name to this function, renames its variables, renames its files,
etc.
PR looks kind of big but most of it is pretty minor find and replace.
Bit of a tricky function, but as usual, PSP saves the day.
I noticed it setting a value to entity->unk68, which is an entity field
I don't usually see used. I did a tiny bit of research into what other
entities used it, and I quickly noticed that many of them relate to
parallax, so I added a comment there for someone to be able to give it a
proper name.
This comes with a few fake symbols fixed on a few functions, types being
corrected when needed and `LEN` being used where I could spot a pattern.
Data in `bossfight` is used in a mix between `bossfight.c`, `slogra.c`
and `gaibon.c`, which I believe they were originally one file.
`0x3CB8` is not extracted as an asset. It is an unused blob of data.
Using Tile Molester doesn't suggest it is a clear 4bpp image and the
decompression tool doesn't work on it. I left it as it is until we know
more.
I had to make a few file splits to get a match. I am yet to understand
the pattern on how files were originally organised. In some instances it
suggests files were split with a C file for every entity. But in other
instances it does not seem to be the case. I hope NZ0 will come with a
different function order so we will get more hints.
I will probably make a short tool to import the GFX part into a
`header.c` for the remaining overlays as it is quite tome consuming to
do it manually.
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.
