Matches w_000, effectively opening the doors to understand how hand
equippables work. That includes weapons, shields, consumable; all of
them internally named as Weapons). This overlay is used by:
* Tyrfing
* Namakura
* Gladius
* Scimitar
* Cutlass
* Saber
* Falchion
* Broadsword
* Bekatowa
* Damascus sword
* Hunter sword
* Bastard sword
* Talwar
* Sword of Hador
* Luminus
* Harper
* Gram
* Mormegil
* Terminus Est
* Dark Blade
* Mourneblade
* Badelaire
Due to the nature of splat, renaming the symbols is hella hard but
possible once we start importing the `.data` section in it. As far I
know this overlay does not contain any `.rodata`.
Checklist to convert it from Draft to Ready:
- [x] Decompile [func_4000_8017B1D8](https://decomp.me/scratch/HLPI0)
- [x] Confirm name of the functions
- [X] ~~Put shareable code in the appropriate folder (either as `.h` or
`.c`~~ not all overlays have identical functions (see w_029). Needs more
research
- [X] ~~Import `.data` in the C file~~ needs substancial re-work in the
spriteparts asset extractor
- [x] Move `AnimSoundEvent` to the appropriate header
- [X] ~~Rename `Entity::unk58` and `Entity::`unk6A`~~ more appropriate
as a separate PR
## What is this
Required for #465 . I re-wrote how the build process works for the
`BIN/WEAPON0.BIN` ~~overlay~~ file.
## A bit of a background
On the PSP build I found `WEAPON0.BIN` is just a blob with `f0_000.bin`,
`w0_000.bin`, `f0_001.bin` and so on concatenated as a single file. `f0`
contains the graphics (or CHR) and `w0` contains the actual overlay (or
PRG). The individual overlays share a great amount of functions I
documented in `config/symbols.us.weapon.txt`.
## The problem
Splat creates its own `weapon.ld` linker script, insisting to link all
the overlays as a single binary file. While this is not technically
correct, it creates a bigger problem: symbols cannot be shared. In 58
overlays there are 58 `DestroyEntity`. Other decomps are
circumnavigating the issue by adding a prefix. Following the same
pattern we could have `W000_DestroyEntity`, `W001_DestroyEntity` and so
on. But this is not maintainable and it does not reflect our long-term
vision of having shared code between overlays.
## The solution
I created the dedicated linker script `weapon0.ld` to output the
individual overlay `w0_000.bin` and similar. `f0_000.bin` is also
created from the correspondent PNG. Once all the overlays and graphics
are created I am simply concatenating them back to `WEAPON0.BIN`. This
is much more efficient in terms of separation of concerns,
maintainability, build speed and it also allows to use the same symbol
names across overlays. Also very important, the generated individual
overlays matches the structure of what is found in the PSP build.
## Side note
I thought it was wise to prepare the Makefile and the linker script to
also allow rebasing and compiling for WEAPON1.BIN. The generated file
does not currently match and it will probably need a bit more research.
I left the build infrastructure there. To compile the non-matching
WEAPON1 just modify `$(BUILD_DIR)/WEAPON0.BIN: $(WEAPON0_FILES)` to
`$(BUILD_DIR)/WEAPON0.BIN: $(WEAPON0_FILES) $(WEAPON1_FILES)`.
Splits `BIN/WEAPON0.BIN` in its own individual C files and assets. There
are 59 overlays 59 PNGs extracted as part of it. The `.data`, `.text`
and `.sbss` section are correctly split. I did not yet split the
`.rodata` but I assume it will be so small we can do it on-the-go.
This is fully integrated in the build process, it gives an 🆗 once
built back and it is fully integrated in the CI. We did not yet know how
weapons work in-game and we already have a few instances in the code
where we call `D_8017A000();` and similar. I think it is time to start
documenting them.
Thanks to @bismurphy <bismurphy@users.noreply.github.com> for addressing `analyze_calls.py` for this specific
PR.
# What
Adds a custom debug menu. It is written in C and it is meant to replace
the Bat familar `SERVANT/TT_000.BIN`. Once loaded you can long-press
SELECT+START to soft-reset the game and keep using the debug menu
everywhere, including when playing with Richter or during the credits.
One key requirement to run this is to have an emulator that emulates the
8MB of RAM. This is a key requirement to have the debug module surviving
soft-resets or accessing to the in-game menu. I personally used [PCSX
Redux](https://github.com/grumpycoders/pcsx-redux) to build this module.
I am not sure about the compatibility with other emulators. This does
**NOT** work on real hardware and it is a choice by design. The debug
module is intended to test different areas of the game and help
decompiling. It is not intended to be used in normal gameplay.
# Build
Simply invoke `make disk_debug` to create a disk image of the game in
`build/` with the debug module replacing the Bat familiar.
# Usage
On PCSX Redux go to Configuration, Emulation and tick the box `8MB`.
## Loading the module
You need to enable the Bat Card from the menu. This will load the debug
module from the disk. If you want to re-load the module you need to
select another Familar Card, un-pause, pause again and select the Bat
Card once more.
## The main screen
You will know you have loaded the debug module when you see the blue
rectangle on the top right. You can press R2 to cycle between the menus.
Some menus will temporarily freeze the game, some not. To quickly return
in-game you can either press TRIANGLE or START. To bring back the paused
debug menu just press R2 once again.
## Debug Mode
### Stage
Teleports the player to a different stage. It is not stable and it can
crash often.
### Player
Switches between Alucard and Richter. Currently switching from Richter
to Alucard consistently crashes the game.
### No Clip
Allows to freely move the player within the room and without the
collisions on. Once the flag is enabled from the debug menu, pressing L2
while in-game will temporarily freeze the player movement and make it
immune to collision checking. You can then press the directional buttons
to slowly move the player or you can hold CROSS to move it faster. You
can also use SQUARE or CIRCLE to cycle between the player frames. Press
L2 again to deactivate the NoClip mode.
### Frame by frame
Freezes the game outside the debug module. Press L1 to advance by 1
frame. Hold L2 to put the game in slow-motion.
### Show hitboxes
As shown in the image
### Show debug messages
When the debug menu is un-paused, prints on the top left all the debug
messages from the game itself.
### Show collision layer
This prints the internal collision value for every 16x16 tile on the
screen. Look the CheckCollision function for more information on how
each printed value is used.
### Show draw calls
Shows the maximum GPU resource usage since the game started. Currently
only the `max` option works. The `current` option will not show
anything.
### Show HBlank
Prints the current horizontal blank interrupt count.
## Entity Spawn
Allows to immediately spawn new entities in the current map
### Mode
There are three list of entities, each one with their own ID: DRA, Stage
and RIC. The option RIC is hidden if Richter is not the current playing
character. As the list of entities per stage is maintained manually,
stage entities might not be available for all stages. The `Alloc` shows
how many entities are reserved or actually used. Pressing the SQUARE
button here will destroy all the entities within that range.
### ID
Press Left or Right to cycle between the different IDs available. Some
of them might crash the game immediately once spawned. Press CROSS to
immediately spawn the entity.
### Params
Each entity might have its own parameters. Sometimes the flag 0x8000 is
used, which can be toggled with the SQUARE button. Press CROSS to
immediately spawn the entity.
### Entity preview
Shows the entity before spawning it. This is turned off by default as it
can immediately crash by cycling through the available entity IDs.
### Place entity
Pressing CROSS will allow to move the entity across the screen before
placing it. Press CROSS again to place the entity and return to the
previous screen. Press SQUARE to quickly place multiple entities of the
same type.
## Sound player
There are three macro categories the sound player is split into. For
what is currently known only the sounds within the Kind 3 changes based
on the loaded stage.
### Stop all sounds
This will also disable the SPU IRQ, effectively unlocking the frame
rate.
### Load Stage
Loads a different sound font than the current loaded stage. This can
help to quickly preview and test SFXs from other stages without
necessarily moving the player there.
### Load Servant
Loads the sound font of a specific servant without necessarily equipping
the Familiar Card.
## Castle flags
Preview all the flags used to modify the behaviour of different parts of
the two castles.
### Edit mode
You can move the cursor with the directional buttons and flip the flag
with CROSS. Press L1 or R1 to cycle between the pages. The cursor warps
when reaching the border of the flag grid, allowing a faster navigation.
### View mode
Allows to move between the flags more flexibly.
### Listen mode
Listens for the modified flags while playing. Every time a flag is
modified the offset and its value is registered on the top left up to 4
rows. When all the rows are occupied, new values will just remove the
oldest one. The last modified flag will always be displayed at the
bottom.
---------
Co-authored-by: Alejandro Asenjo Nitti <sonicdcer@users.noreply.github.com>
Co-authored-by: sozud <sozud@users.noreply.github.com>
I noticed that my lints are already pretty slow and hard to maintain so
I moved them to rust and optimized them. All the files are now linted in
parallel, and we can do as many transforms to a single line as we want.
I think this provides a good baseline where we can have a big suite of
lints if we want to.
I added more cases to the FIX linter as well. Rust always puts a newline
at the end of a file so we picked up some changes due to that. I think
git wants you to do that anyway so it seems like an improvement to me.
Fully splits `libsnd` into individual files following the original PSY-Q
SDK file names. The same is done with `libcd` and `libspu` just to
define the boundaries of `libsnd`. I also correctly names **all** the
function symbols from the sound library with their right offset. We
previously had some wrong symbol offsets, leading to the inability to
create their C counterparts with `INCLUDE_ASM`. This PR will start to
open the doors to decompiling `main` or understand better how `DRA`
communicates with `main`.
This took an incredible amount of time as I had to do it manually. I
would have written a script, but there are some variants I would prefer
to handle manually. To achieve this I used the [PSY-Q
signatures](e9e46e7e13/350/LIBSND.LIB.json).
I also discovered the game uses PSY-Q 3.5, which brings some piece of
mind to what they used to develop the game.
After this PR my plan is to:
* Finish to split the other PSY-Q libs
* Move `asm/main/*.s` into their own C files
* Include `main` progress in our reporting
Following the incredible work of @bismurphy in #396, this will integrate
the tool in the CI. The markdown file `gh-duplicates/functions.md` will
have clickable links to navigate right to the SVG call tree of the
correspondent functions.
---------
Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
Follow up to #412 . This also integrates the two new linters within the
formatter. By the way, are we happier with `RELIC_END` or `RELIC_COUNT`?
---------
Co-authored-by: sozud <122322823+sozud@users.noreply.github.com>
I wanted to make this tool for a long time. Given the fact HD recently
became more dense into DRA, people who are willing to contribute to that
overlay should not have the burden of manually cross-referencing symbols
as I have been doing for the past weeks. Instead of creating a tutorial
I created a tool that cross-reference symbols between functions. The two
functions can be either between two different revisions of the game or
between two overlays. The latter is especially important to finally
remove all the duplicate functions.
I also took the opportunity to add some unit tests (finally!) in
`tools/tests` instead of creating the dedicated folder `tools/symbols`
with tools and test in it. Let me know if `tools/tests` is a pattern we
want to keep following for any future tool that needs to be tested.
I also added an assembly parser written in Python. As for today it lives
in `tools/symbols.py`. It is barebone but it can parse the majority of
assembly lines. I also added tests around it in case we want to expand
it or extract the parser into its own utility. I've been thinking to
ideally use it for a V2 of `find_duplicates.py` if we find the current
tool to be limiting.
### Demo
```
sotn-decomp$ ./tools/symbols.py cross asm/us/dra/nonmatchings/71830/func_80112BB0.s asm/hd/dra/nonmatchings/71830/func_80112BB0.s
D_80139824 = 0x801393F0;
D_800ACF7C = 0x800AD040;
D_800ACF7E = 0x800AD042;
D_80138FC8 = 0x80138B94;
D_80138FCA = 0x80138B96;
```
these symbols can be automatically copy&pasted into `symbols.hd.dra.txt`
or the relevant symbol list.
This splits the saturn libs into individual files and adds one function
to test the workflow. The splitter can't split multiple files at the
moment so the linker file is made manually. I plan to fix this
eventually. I updated the splitter to not overwrite linker files that
already exist. I'm open to suggestions on the directory structure but
this seemed like the easiest way given the dosemu copying stuff.
A few tweaks to the Makefile:
* `PSXCC_FLAGS` now contains all the GCC flags that only work with the
old versions
* Add debug symbols in the PSX ELFs by adding `-g` and by removing `-s`
* Remove `--no-check-sections` as the reallocation would break the
executable if we add too much data
I did not remove `-s` from the Saturn version. We might want to do that
but we also need to add the `-g` flag in
`tools/saturn-splitter/scripts/compile_dosemu/compile_dosemu.sh` (cc.
@sozud)
I can only hope it will work at first try.
The trick lies in `extract: extract_$(VERSION)` and `build:
build_$(VERSION)` to customise different versions/ports to do different
things and keep the flow the same.
You can now do:
```
export VERSION=hd
make build
```
or:
```
VERSION=hd make build
```
or:
```
make build_hd
```
If we are happy with this pattern we might want to do the same with the
Saturn version too.
Like Equipment, this will take the accessories, extract to a json in the
assets directory, and then when building the game, read items from that
json. Full list of changes required for this capability, and their
reasons/purposes:
Addition of entry in the makefile for the accessory json. This is
literally just the equipment one copied and the name changed.
Adjustment of splat extraction. Accessory data runs all the way up until
a bunch of strings which are now in 8258.data.s. Previously, the file
8000.data.s was created, and was just a whole bunch of uninterpreted
.word values. The accessory table runs all the way up to 0x8258.
Happily, this means there is no longer any gap between understood and
non-understood data in this region of the ROM.
Accessory.py is extremely similar to the existing Equipment.py. As
stated in the large comment at the top of this script, it would be neat
if we could combine the two scripts to one script that would process all
equippables in the game. For now, this is functional. Tidying this up
could be a nice future task, especially for someone new to the project
who is more comfortable with Python than C.
Finally, the dictionary of punctuation in the utils.py has been
expanded. The question mark shows up in the description of the Alucart
Mail "Resists fire, lightning, ice?", while the plus signs show up in
many items which provide stat bonuses that have descriptions like
"DEF+15". These symbols were previously unknown.
Feels very nice to now have equipment and accessories both extracting to
human-editable forms!
This PR replaces the ASPATCH command with my custom script named MASPSX.
It's very new, and so is likely to have bugs and/or missing
functionality. That said it's producing an 🆗 build across all
overlays, and is matching a few functions that required psyq3.5/aspsx.
I have not attempted to match any of the functions that require rodata,
nor any of the functions that refused to compile / had diffs.
Note that I have added `-gcoff` to the `CC_FLAGS`, this will give you
line numbers in asm-differ.
----------------------
Thank you in advance for contributing to sotn-decomp.
Before submitting this PR, please make sure:
- [x] The PR is small and focuses to address a single task
- [x] `make all` reports all `OK`
- [x] `make format` reports no files changed
- [x] Have Actions enabled in your fork to run the auto-formatter
This adds a new tool that extracts the Saturn ADPCM music files to WAV.
@sonicdcer pointed me to an old winamp plugin that had support for this
format, so I reworked the relevant part into a standalone tool. This
doesn't try to re-encode, since I would want to examine the original
decompression code to make sure that it's 1:1 with this implementation
first. Not all the files seem to be in this format, so I explicitly list
the ones that are in the Makefile. I think the other PCM files are the
voice tracks, which would make sense to use a voice-oriented codec.
---------
Co-authored-by: sozud <sozud@users.noreply.github.com>
This was working on my fork but may require a little tweaking for this
repo since I can't test the dependency fetching. The CI build uses a
regular install of dosemu2 since you can't run it in a container on
GitHub actions. I rearranged the Makefile a bit to parallelize some
actions and reduce duplication for the two workflows.
---------
Co-authored-by: sozud <sozud@users.noreply.github.com>
This adds the Alchemy Lab overlay and decompiles func_060e1ff8 to check
that it's working. func_060e1ff8 seems similar to
31d04a46d3/src/st/nz0/36DE4.c (L101)
but it's not clear if it's the same function yet.
I think it probably makes sense to add one overlay of each type. Right
now there's no stage overlay extracted. I picked Alchemy Lab since it's
the furthest along on PSX.
This adds some new Makefile commands:
build_saturn_toolchain: Downloads GCCSH, and builds two docker
containers. One container is binutils for SuperH, and the other has
Dosemu.
build_saturn: Copies GCCSH, the source code, and asm into the build
directory and runs the GCCSH via Dosemu in the docker container.
Everything is kept in the same directory since it's hard to use Dosemu
otherwise.
check_saturn: Dumps the object files to binary using the binutils Docker
container, then checks the hashes.
diff_saturn: Compares the binaries and outputs a diff to
build/saturn/$FILENAME-diff.txt. Used like FILENAME=GAME.PRG make
diff_saturn.
I've added the source for game.c and t_bat.c. I've replaced one of the
asm functions in t_bat.c to show that it's possible to match simple
functions. I'm not able to generate linker scripts yet so functions that
rely on symbols from other overlays generally can't be matched yet.
This workflow is not all that clean so I'm open to ideas on improving
it. I tried using various versions of
https://github.com/decompals/old-gcc to try to get a native compiler but
couldn't get a matching build. I'm not 100% sure that this version of
GCCSH is correct but initial results seem promising.
As of right now, it's not possible to run this in CI since the dosemu
container changes the USER and Github won't let you write to disk if you
do that.
https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user
This PR does some initial integration work for splitting the Saturn
version. It adds T_BAT.PRG (Bat overlay) and GAME.PRG (similar to
DRA.BIN). These are extracted to asm/saturn/* and src/saturn/*. Right
now there's no attempt to compile. I haven't been able to figure out the
issues with sotn-disk so this requires pre-extracted files in
disks/saturn. Something like this is able to do it:
```
bchunk saturn.bin saturn.cue saturn.iso
7z x saturn.iso
```
The Saturn version has the code split up differently so I think putting
it in a separate folder to begin with makes sense. For example the
Random function is in GAME.PRG rather than in the stage overlays.
There's also an Alucard overlay rather than it being included in
GAME.PRG. See here for some comparisons:
https://github.com/Xeeynamo/sotn-decomp/wiki/Saturn-Matching
I didn't attempt to install Rust as part of the project setup like with
Go.
---------
Co-authored-by: sozud <sozud@users.noreply.github.com>
Solves the issue mentioned in discord - When you `cp` into expected, and
expected does not exist, the CONTENTS of build get copied into the
newly-created `expected` directory. This PR solves this by running
`mkdir -p expected` first (-p causes mkdir to not error if `expected`
already exists). Then, when `cp` runs, `expected` will always exist,
thus `build` properly gets copied into it.
Thanks to @MottZilla research I was able to extract the spritesheets of
Richter as PNGs in conjunction with the original palette from
`F_GAME2.BIN`. When the binaries are built, the PNGs are recompiled back
into binary.
In case of modding, it is possible to modify the sprite size to
accommodate bigger or smaller sprites. Although it is not possible to
modify the existing palette as currently we have no way to extract and
rebuild `F_GAME2.BIN`. You would have to modify the palette via hex
yourself. The file `config/splat.us.ric.yaml` shows in which offset the
palette is located. Just for reference, the colour format for the
palette is RGBA5551. It is important that edited PNGs has 16 colours
otherwise the build will fail.
The `padding` field is required to reconstruct some left-over / junk
data that is not part of the data sprite. For the sake of modding, the
`padding` field can be whatever.
I am not sure if `RIC.BIN` pointers can be relocated. If that is the
case you might get a black screen when playing with Richter. It should
be easily fixable though.
