Where to track decompilation progress

A useful progress tracker tells you what changed, which version was measured and where the number came from. Start with a project’s own report, then use a directory to keep several projects in view.

Choose the right source

decomp.dev collects matching-decompilation reports. objdiff produces detailed reports used by that ecosystem. These are useful when the question is how closely reconstructed code matches a particular original build.

For compatibility projects, follow the repository’s documentation and compatibility lists. A count of implemented functions can answer a different question from a list of games tested successfully. Browse DecompHub to find the repository and the sources attached to each progress measurement.

Compare like with like

Before recording a change, keep four details together: the target version, metric label, denominator and source date. Matching bytes and matching functions can move at different rates. A library can fall from one percentage to another because newly discovered functions enlarged its denominator, even while more functions were implemented.

An observation date says when a directory read a report. It does not establish when the publisher last measured the code. Unknown progress means there is no supported number in the listing, not that work has stopped.

Put the report in a README

The DecompHub badge builder turns stored, sourced measurements into a README image. Each line stays separate and links back to dates and evidence. It also documents a small JSON format for projects that want to publish their own reports.

Generate that report using the project’s existing measurement script after changes reach the default branch. A CI notification can queue a fresh source check; ordinary collection remains the fallback. The notification itself cannot set a percentage.

For interpretation, read how progress reports work. To choose where to contribute, use finding active projects and verify the upstream contribution instructions.