# silent-hill-decomp: rebuilding Silent Hill's PlayStation binaries as matching C

> silent-hill-decomp is an in-progress decompilation of Silent Hill for the PlayStation 1, where the goal is C code that compiles to output identical to the original assembly. The project states plainly that it is not a port, and that matching every function is only the first phase.

**shdecompilations/silent-hill-decomp** — An in-progress decompilation of Silent Hill on the PlayStation 1.

- Repository: https://github.com/shdecompilations/silent-hill-decomp
- Stars: 965 · Forks: 53
- Language: C
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/shdecompilations-silent-hill-decomp

## Matching output, not shipping a port

silent-hill-decomp is an in-progress decompilation of Silent Hill on the PlayStation 1, written in C, and the distinction it insists on is the whole point of the project. A decompilation means writing C that compiles into a binary identical to the original, whereas a port means taking the game and running it somewhere else. The project states it is not a port to PC or any other platform, and it is not port ready, because documentation is missing and the code is under constant reorganisation. It also says the work is led by volunteers, so there is no schedule. That framing matters for anyone weighing whether to spend time here, because the deliverable is a faithful reconstruction of the original logic, useful for study, for tooling and as a base for later work, rather than a binary you can download and play.

## One game, many overlays, several progress trackers

The reason the project has multiple progress trackers is a property of the original game rather than of the decompilation effort. The PlayStation 1 had limited memory, so games spread their logic across separate binary overlays, and Silent Hill divides core engine code, screen related code and map stage logic across many distinct binaries. The main executable, SLUS_007.07 on the 1.1 NTSC release, serves primarily as a memory handler, so the bulk of the game lives elsewhere. The trackers are per category, with the main executable, BODYPROG.BIN holding the main game logic, the game screen overlays, and individual screens such as B_KONAMI.BIN for boot screen logic, STREAM.BIN for full motion video stream logic and SAVELOAD.BIN for save handling. Two of these are marked in the README as fully decompiled and matching overlays. The percentages are rendered as shields from decomp.dev, which tracks both matched code and matched data per category.

## Why 100 percent is not the finish line

The percentage in this project has a precise meaning: it tracks how much of the compiled code has been matched, meaning C has been written that compiles to an output identical to the original assembly. Reaching 100 percent means every function in the game is accounted for, and the documentation is clear that this is only the end of the first phase. Several large pieces of work remain. Deobfuscation and naming, since many functions and variables still carry generated names such as func_80241A30 that have to be worked out and given meaningful names. Data migration, where raw binary data must be parsed into proper C structs so it can be understood. Shiftability, which means removing the build's dependence on hardcoded memory addresses so that code and data can be modified without breaking everything. And documentation of how the game's systems fit together, which is what the project says will help mods and future projects. The project also states its own policy on tooling, noting that no AI-generated code has knowingly been added into the decompilation, with at most some throwaway helper scripts.

## The build runs in a Python 3.12 container with a MIPS toolchain

The repository ships a Dockerfile and a build_image.sh script, and the container is where the toolchain lives. The base is python:3.12-slim-bookworm, and the packages installed include make, gcc, the MIPS cross tools binutils-mips-linux-gnu and cpp-mips-linux-gnu, bchunk, p7zip-full, progress and sudo. A non-root user is created so the build does not run as root. The Python side is driven by a requirements file:

```python
python-Levenshtein
python-ranges
toml
splat64[mips]==0.39.1
spimdisasm==1.40.2
pycparser
pyelftools
construct
ninja
```

The interesting entries are splat64, the tool that splits the original game files into rebuildable chunks, and spimdisasm, the disassembler and analysis tooling that the matching work depends on. A Docker run script is present as well, and the build is driven by Ninja through a ninja_config.py helper. The container image and the requirements file are the two files to read first if you want to understand what the build actually needs.

## Makefile switches decide what is built and how strictly it is checked

The Makefile is where the project configuration lives, and it is deliberately explicit. The build items are toggles:

```bash
BUILD_EXE      ?= 1
BUILD_ENGINE   ?= 1
BUILD_SCREENS  ?= 1
BUILD_MAPS     ?= 1
BUILD_ITEMS    ?= 1
CHECKSUM       ?= 1
NON_MATCHING   ?= 0
SKIP_ASM       ?= 0
```

CHECKSUM and NON_MATCHING are the interesting pair, since they decide whether the build is expected to reproduce the original data exactly or is allowed to contain sections that do not match yet, which is how a work in progress stays buildable. SKIP_ASM controls whether original assembly is kept alongside the reimplemented code. The target release is chosen with GAME_VERSION, defaulting to USA, and the Makefile defines the American SLUS-00707, the European SLES-01514 and the Japanese SLPM-86192 with their file names, including the Japanese revision variants. The comment in the file notes that the item data is only available for the European release, so picking a version changes what the build can produce. USE_COMMON and OBJDIFF_FIX handle linker script and diff tooling details.

## Why a decompilation is more useful than a disassembly

The realistic alternative is not a port but a disassembly, and the difference in approach is the point of the whole project. A disassembler can turn the original binaries into assembly that a reader can study, and that is much faster to produce, but it stays assembly: you cannot compile it, you cannot change a branch without hand editing assembly, and you cannot run static analysis over it. The decompilation route writes C instead, which is the form a compiler can rebuild and the form a person can read, and the matching requirement means the result is verified against the original rather than merely similar to it. The price is effort, and the README is honest about the parts that are not finished: without shiftability the build still leans on hardcoded addresses, and without data migration the data is still raw. Forks of the project are free to add ports, fixes or features, and the README notes that some of them use AI for that work, while the decompilation itself stays human led, so a fork's output and its policy can differ from upstream.

## What the project does not do, and where it stands

The limits are stated by the project itself and deserve repeating, because they are the reasons this is a long term effort rather than a weekend one. There is no port, and the codebase is not port ready, which is attributed to missing documentation and constant reorganisation. There are no tagged GitHub releases at all, so there is no version to pin and no changelog to read for the library itself, and the repository is not archived, with the last push on 2026-10-20. The documentation lives in a docs/ directory, with the build assets in configs/, the source split across src/, include/ and lib/, tooling under tools/, and a rom/ directory that belongs to the build inputs rather than to the source tree. The licence field on the repository reports a custom licence that GitHub cannot classify, so the LICENSE file is the only authoritative text and it is worth reading before you reuse any of the code. Finally, the contributors describe the effort as volunteered with no rush, which is an honest signal about when milestones should be expected.

## Conclusion

Adopt silent-hill-decomp if you want the Silent Hill code as readable, compilable C for study, tooling or a future port, and if you accept that the work is unfinished and the build is version specific. Do not adopt it expecting a playable PC build, because the project states it will not produce a port and is not port ready. Verify first which retail version you are targeting, since the Makefile defaults to the USA release and the European release is the only one with the item data, and check the LICENSE file, because the licence field on the repository reports a custom licence that GitHub cannot classify. The last push was on 2026-10-20, the project has no tagged releases, and the README says the work is led by volunteers with no schedule.

## FAQ

### Is silent-hill-decomp a PC port of Silent Hill?

No. It is a decompilation of the original PlayStation 1 game code, which means C that compiles to a binary identical to the original. The project states it is not and will not produce a port, and that the codebase is not port ready because documentation is missing and the code is under constant reorganisation.

### What does the decompilation percentage actually measure?

It tracks how much of the game's compiled code has been matched, meaning C has been written that compiles to output identical to the original assembly. Reaching 100 percent means every function is accounted for, which the README is explicit is only the end of the first phase, since deobfuscation, data migration, shiftability and documentation still remain.

### Which Silent Hill release does the build target?

The Makefile sets GAME_VERSION to USA by default, with the American SLUS-00707, the European SLES-01514 and the Japanese SLPM-86192 defined along with their revisions. The item data is only available for the European release, so the chosen version changes what the build can produce.

### What tools does the silent-hill-decomp build need?

The Dockerfile uses python:3.12-slim-bookworm and installs make, gcc, the MIPS cross compilers, bchunk and p7zip. The Python requirements include splat64 for splitting the original files, spimdisasm for disassembly, plus pycparser, pyelftools, construct, ninja and the toml and Levenshtein libraries.

### How is the build kept honest while the decompilation is unfinished?

The Makefile exposes the knobs. CHECKSUM and NON_MATCHING control whether the build has to reproduce the original data exactly or may contain sections that do not match yet, and SKIP_ASM controls whether the original assembly is retained next to the reimplemented C. Progress is reported per category through decomp.dev shields, covering matched code and matched data.

## Sources

- [Issues](https://github.com/shdecompilations/silent-hill-decomp/issues)
- [README](https://github.com/shdecompilations/silent-hill-decomp/blob/master/README.md)
- [shdecompilations/silent-hill-decomp on GitHub](https://github.com/shdecompilations/silent-hill-decomp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shdecompilations-silent-hill-decomp