7.2 KiB
Castlevania: Symphony of the Night disassembly
Recompilable code that creates 1:1 binaries for the commercial videogame Castlevania: Symphony of the Night for the PlayStation 1. This repository aims to create a full decompilation in C.
Game revision
All the files refers to the SLUS-00067
version of the game.
Technical details
The game is divided in three modules:
SLUS_000.67
is the game engine of the game. It contains all the necessary logic to interact with the gamepad, CD, memory card, the SPU and to render the sprites on-screen. It appears to not contain any game logic by itself.DRA
is the game itself. It contains the gameloop and the necessary API to draw maps, entities, load levels, handle entities, animations and collisions. It also contains some common data such as Alucard's sprites, candle's sprites and the common rooms' (save, loading, teleport) layout.ST/
are the overlays for each area. An area (eg. Castle's entrance, Alchemy Laboratory, etc.) contains all the unique logic to handle map's specific events, cutscenes, enemies' AI, collisions and more. It also contains the rooms and entities layout.
Build
- You need
gcc-mipsel-linux-gnu
that you can easily install on any Debian-based Linux distribution. On Windows it is highly recommended to just use Ubuntu with WSL - Copy the game's data from your SOTN game copy into a new folder in the root directory of the repository called
iso
- Run
make extract
to generate the assembly files - Run
make all
to compile the binaries into thebuild/
directory
Restore MAD (debug room)
The debug room overlay ST/MAD.BIN
was compiled earlier than the first retail release of the game. All the offsets that refers to DRA.BIN
points to invalid portions of data or to the wrong API calls, effectively breaking the majority of its original functionalities. That is why the debug room does not contain any object. By compiling the debug room with make mad_fix
you can restore it by redirecting the old pointers to the retail version of the game.
Be aware that not all the offsets have been yet redirected, so it will still be not entirely functional until further update.
Non-matching build
Some non-matching functions are present in the source code by disabled by the macro NON_MATCHING
. You can still compile the game binaries by running CPP_FLAGS=-DNON_MATCHING make
. In theory they might be logically equivalent in-game, but I cannot promise that. Few of them could match by tuning or changing the compiler.
Check function matching
With asm-differ you can check if a funtion written in C matches its assembly counterpart.
- Be sure to resolve the submodule with
git submodule update --init
- Ensure to create a matching binary with
make clean && make extract && make all && mkdir expected && cp -r build expected/
- Choose a function to match (eg.
func_8018E964
), an overlay (eg.st/mad
) and then invokepython3 ./tools/asm-differ/diff.py -mwo --overlay st/mad func_8018E964
Decompile and contribute
This guides you step-by-step to contribute to the decompilation project.
- Choose an overlay to work with (eg.
ST/WRP
) - Look for one of those function which hasn't successfully decompiled yet (eg.
INCLUDE_ASM("asm/st/wrp/nonmatchings/6FD0", func_801873A0);
) - Follow the guide to check the function matching
- Look for its assembly file (eg.
asm/st/wrp/nonmatchings/6FD0/func_801873A0.s
) - Run
ASSEMBLY=asm/st/wrp/nonmatchings/6FD0/func_801873A0.s make decompile
to dump the decompiled code intoctx.c.m2c
- Replace the
INCLUDE_ASM
you targeted, replace it with the content ofctx.c.m2c
and tweak the code withasm-differ
- You will probably have some differences from your compiled code to the original; keep refactoring the code and move variables around until you have a 100% match.
There are a few tricks to make the process more streamlined:
- Use decomp.me with GCC 2.7.2 for PS1. Be aware that the repo is using GCC 2.6.x, so decomp.me will sometimes give a slightly different output
- Use decomp-permuter to solve some mismatches
- Use this and this guide to understand how some compiler patterns work
- Use the
#ifndef NON_MATCHING
if your code is logically equivalent but you cannot yet fully match it
Notes
- I suspect that GCC 2.6.x / PSY-Q 3.4 have been used to originally compile
DRA.BIN
main.exe
uses PS-X libraries that might have been created with a different compiler and with-O1
rather than-O2
To do
The project is very barebone at the moment and there is a massive room of improvement, mostly in the infrastructure:
- Not all the zone overlays (
ST/{ZONE}/{ZONE}.BIN
) are disassembled - GNU AS might produce a slightly different register use compared to the original game. ASPSX might need to be used instead as a workaround but it is old, clunky and not yet integrated in the repo.
- Split binary data (eg. map layout, graphics, other assets) into individual files