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.
The objective is to separate the data that is usually written into `asm/*/data` into separate files. Those will initially be binary files.
There is also an utility that allows to decompress compressed data. The decompressed data is currently not read as we are missing a compression algorithm that matches the original one. I tried writing one in the past: it worked, it re-created similar files but sadly not the same ones. The decompression algorithm is there to allow to do some data mining and understand what the data is and how it is used.
