Adding Faerie to CMakeLists
Seems like SFX not working, but Faerie at least loads.
~~Possibly also an issue with with the g_Entities array as the wings
should occupy g_Entities[5] (set up in line 550 of Faerie.c), but they
don't seem to either load or update (unsure which).~~
Seems this was either a graphical bug or something transient as the
wings seem to work now...
I'm not particularly interested in debugging this issue at this time, so
if you'd rather I abandon the PR, I can do that too. There wasn't a lot
of change.
Had to tweak some file splits, but ultimately I managed to decompile all
of the functions in a PSP file, and then line up the two DRA codebases
so that PSP could pull from the existing one. Of course, some of the
functions also needed tweaking to end up matching on PSP.
Glad to be able to prove this is possible in DRA!
I had this on a local branch. I do not remember why I did not submit it.
Main changes:
* `EntityRedDoor` ➡️ `OVL_EXPORT(EntityRedDoor)`: while the entity is
the same across all stages, their `OVL_EXPORT(RedDoorTiles)` is
different
* `g_EInitBreakable` ➡️ `OVL_EXPORT(EInitBreakable)`: each stage has
variations of the breakable
NZ0 is now good to go 👌
I discovered that `g_HeartDropArray` was always very weirdly used in
overlays such as WRP, CEN and DRE where there are no prizes dropped from
breakable objects. This lead me to discover that every overlay has a
prize array that describes what items to drop. But for WRP CEN and DRE
since the array has length zero, the symbol overlaps with what comes
right after.
The array is also different for every overlay. The array will be renamed
as `OVL_EXPORT(PrizeDrops)`. This PR aims to adjust such array in all
overlays:
* [x] CEN
* [x] DRE
* [X] ~MAD~ cannot be moved
* [x] NO0
* [x] NO3
* [x] NP3
* [x] NZ0
* [X] ~ST0~ not existent
* [X] WRP
* [X] RWRP
* [x] MAR
Experimental piece of work I feel confident enough to submit. A few
things to take in consideration:
* The new `pfn_entity_updates.h` header aims to use the PSP variant of
`PfnEntityUpdates` and the two `g_pStObjLayout`, I just tweaked a bit
the code from `stage.h`
* Add overlay prefix to the PSX version of `PfnEntityUpdates` and the
two `g_pStObjLayout`
* Changed `wrp/create_entity` to `rwrp/create_entity` in RWRP because we
need the `RWRP_` prefix to be issued
* Remodernized the WRP header
* I am still not sure what's wrong with `g_HeartDropArray` in `warp.c`.
I am pretty sure it is a PSX bug. I opted for the PSP version
There's a `// PfnEntityUpdates = OVL_EXPORT(EntityUpdates);`. If you
uncomment and resolve the multiple definitions you will have the two
overlays linked. I still need to figure out how to handle the
`InitializeEntity` parameters in `e_init` without going mad with the
`#ifdef`.
Takeaways from the Xbox 360 build:
* `EntityBreakable` is different in every overlay, so we can use the
`OVL_EXPORT` in our decomp
* Every other function seem to be de-duplciated. For those functions
that are slightly different between overlays, the developers of the Xbox
port opted for `if (g_StageId == XYZ)`
Takeaways from the PSP build:
* god bless the psp
I recently discovered that using `PUBLIC` propagates settings such as
definitions, flags, includes and more. I also made the formatting a bit
more consistent.
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
```
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
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.
Primary goal here was to eliminate `ext.generic.unkB0`. It turns out
that the only entity that reaches up into this unkB0 region is the
Subweapon entity.
I went through and changed these all to `ext.subweapon.subweaponId`, but
also did some analysis on all the uses to make sure this was an accurate
change to make.
Other highlights:
- Naming CheckSubwpnChainLimit and its RIC counterpart
- Moving the RIC version of that function to the next file, split makes
more sense this way.
- Made both versions of that function `static`
- renamed subweapondef's unk6 to be chainLimit
- Changed g_unkGraphicsStruct.unk0 to be called `pauseEnemies`. It's
true when the stopwatch subweapon is used, and in cutscenes. Found this
due to looking at the stopwatch subweapon setting this value. Also made
it a bool since it's only ever used as a bool.
- Added some playersteps enum uses where they were still using hex
values
- Studied RicEntityStopwatchCrashLightning in order to give it that name
I think that's about it. Overall just some modest cleanup, but continues
to make the game code more readable.
More research on how cutscenes work.
I normalized all the various C files as `cutscene.c`, marked all the
isolated function as `static` and renamed the main entity as
`{STAGE}_CutsceneExec` (e.g. `CEN_CutsceneExec`). I am using the
`OVL_EXPORT` to automate the names.
TO-DO:
- [x] Rename entity as `{STAGE}_EntityCutscene` for consistency
- [x] CEN
- [x] DRE
- [x] NO3
- [x] NZ0
- [x] ST0
- [x] MAR
~~SEL~~
The offset of the portrait data seems to be hardcoded. I have no idea
how to resolve these offsets at compilation time. The entire cutscene
script thing is very sketchy and horribly designed by the original
developers. What a nightmare to integrate into our project.
This is how a cutscene script gets decompiled:
```
LOAD_PORTRAIT(0x80188D8C, 0),
SET_PORTRAIT(1, 0),
SCRIPT_UNKNOWN_11(),
PLAY_SOUND(0x37B),
WAIT_FOR_SOUND(),
SET_SPEED(4),
'T','h','a','t',' ','v','o','i','c','e','!',' ',
SET_WAIT(16),
SET_SPEED(3),
'A','l','u','c','a','r','d',',',
LINE_BREAK(),
SET_WAIT(16),
SET_FLAG(2),
'i','t','\'','s',' ','y','o','u','!',
SET_WAIT(48),
NEXT_DIALOG(),
```
`CutsceneUnk2` uses 8 prims but only 7 are allocated. It looks like at
some point the game writes to the address `0x00000000` but I did not
confirm it with a PS1 debugger. This is a potential bug. `CutsceneUnk2`
signature was also wrong.
I had to get rid of `GfxBank` in `src/st/cen/header.c` and I probably
need to do the same for the other header files. The code reads chunks of
WORDS at the time and a structure would be too large to include
`GFX_TERMINATE` in it.
CEN is there but not linked because it conflicts with some WRP symbols.
I decided to take a much simpler approach compared to what I did with
WRP (which needs to be refactored later on).
There's a cutscene parser. The asset manager is exporting it to
`src/st/cen/cutscene_data.h` if you want to have a look. I know I am
still using `config/assets.us.weapon.yaml` and it probably needs to be
renamed as `config/assets.us.yaml` later on. I am still deciding.
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.
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.
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.
Use the following input endpoints `FileOpenRead`, `FileReadToBuf`,
`FileAsString` and `FileUseContent`.
There was a lot of redundant and inconsistent code scattered across all
the functions responsible of opening and processing files. I also
realised the purpose of some File helpers was not entirely clear, so I
spent some effort to document them.
This is a small part of a bigger effort on refactoring `sim_pc.c`. I am
also planning on adding support for paths such as `disk://` to load from
`disks/us/`, `asset://` to load from `asset/`, `card://` to start adding
support for simulated memcards and so on. This is setting the very
basics to plan that out.
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.
This will decompile all the functions but the new `EntityRWarpRoom` from
the RWRP overlay.
Note that as `e_misc.c` has a function with a different castle flag, I
had to use a shared header. Everything else was identical.
---------
Co-authored-by: bismurphy <tjmurphy@mit.edu>
This adds some fixes to get tetra spirit mostly working. It copies part
of the framebuffer with MoveImage to warp it, so that's added. Right now
there's some bugs with DrawEnv or DispEnv stuff so that the copy is from
the wrong place every other frame and shows as black. There's a couple
of out of bound issues that have speculative fixes I'm not sure about.
The spells are hard for me to do so I added a macro/hotkey system to be
able to test them quickly. I tried calling the spell functions directly
but they didn't work right. I think there's probably code scattered
around to support them so doing the inputs is the only way to activate
it all correctly
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.
This takes the GPU from Mednafen and hooks it up by using parts of
libgpu and writing to the fifo. I avoid using DMA and just write
directly and it seems to work fine. This means that the OTAG part isn't
required since that's part of the DMA system and not the GPU apparently.
The main bug I'm aware of is the TILE that fades to white in the warp
room doesn't show up. The GL renderer is still available. I made the
software renderer the default since it's faster and more accurate on
average. The two renderers can be toggled with F8. I turned on linear
logs by default since it's significantly faster.
The biggest gap I'm aware of is PutDispEnv needs to be properly
decompiled and hooked up.
This function was previously the last function in its file.
Upon decompiling, the rodata (specifically the `00 00 00 00` pattern)
indicated that the file does not end here, and that in fact the entire
following file should be part of this file, so I had to change the
splits to accomplish this.
It's an ugly function, and was hard to get a match, but here it is. Did
what I could to document variables but it doesn't seem to make much
sense, if you ask me.
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.
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 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>
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.
This makes changes to allow libsnd/libspu to compile when
WANT_LIBSND_LLE is set. If turned on it will immediately crash due to
trying to write to the SPU. A build is added to make sure it's
compiling.
I think this is pretty much ready to be merged it. I do not see much of
a point of having the branch floating around.
I am using a `#ifndef HARD_LINK` to avoid compiling duplicate functions
with the same symbol name.
For data with the same symbol name but different content I am doing a
`#define OVL_EXPORT(x) WRP_##x`. So for example
`OVL_EXPORT(g_EntityGfx)` will be expanded as `WRP_g_EntityGfx`. It is
an unfortunate hack. On the other hand all the data migration allowed me
to mark most of the data and functions as `static`. If we use the same
approach on other overlays we could easily statically link them as well.
SEL is enabled by default. It will take you straight to the real WRP,
not the dummy one.
Most of the changes are loading assets from their respective JSON files.
Linking the stage was pretty straight forward.
I had to cherry-pick some existing changes from another branch, but that
part is tested and working.
For the blueprint stuff, I changed the fields from the strings `"TRUE"`
and `"FALSE"` to native JSON boolean values `true` and `false`. That
made things much easier to parse.
The parsing mechanic is straightforward. I'd like to have @bismurphy
review on the blueprint parser and asset changes specifically.
