# How to read decompilation progress reports

Author: DecompHub
Updated: 2026-10-10
Language: en
Canonical: https://decomphub.com/guides/understanding-decompilation-progress

A decompilation percentage only makes sense with its scope. Before comparing two projects, check what is counted, which build is measured, and when the measurement was made. A bar without that context can make unlike results look equivalent.

DecompHub keeps the publisher's metric label, scope and source link alongside the value. When a trustworthy measurement has not been collected, the track stays unknown. That is not the same as zero progress.

## Matching code and working software answer different questions

Matching decompilation aims to produce machine code identical to a target build. Compiler choice and build settings matter as well as the reconstructed source. The [decomp.me FAQ](https://www.decomp.me/faq) explains matching and its function-level scratch workflow. A scratch result describes that comparison; it is not automatically a percentage for a whole game.

A compatible replacement has another goal: reproducing useful behavior. For example, [ScummVM explains that it replaces game executables and uses the original game data](https://docs.scummvm.org/en/latest/help/faq.html). Its support for a game should not be read as a matching-code percentage. Ports, reimplementations and hardware research can be valuable without publishing a binary-matching report.

## Read the denominator

Reports can count functions, bytes, files, symbols or identified assets. These units are not interchangeable.

Consider a **hypothetical** project with 900 of 1,000 functions matched. That is 90% by function count. If the remaining functions contain half of the program's code bytes, it is not 90% by bytes. This example illustrates the arithmetic; it is not a DecompHub project measurement.

Use this checklist when reading a bar:

- **Metric:** Is this matching code, decompiled code, identified assets or another publisher-defined quantity?
- **Unit:** Is the report a percentage or a count? If it is a count, does the source actually supply a total?
- **Scope:** Does it cover a whole executable, one library, a region, a platform or a selected set of files?
- **Source:** Can you open the report that supplied the measurement?

The [objdiff project](https://github.com/encounter/objdiff) documents tooling for comparing objects and generating decompilation progress information. The existence of such a tool does not establish which configuration or denominator a particular repository uses; check that repository's report.

## Different versions need separate readings

A title may have regional releases, revisions and debug builds. A completed result for one version does not establish completion for another. The [Ocarina of Time repository](https://github.com/zeldaret/oot) lists supported versions and asks contributors to choose a version when preparing a build. Preserve that distinction when reading or sharing a progress figure.

Similarly, a code-matching bar and an asset-identification bar describe separate work. Finishing the first does not imply that every texture, sound or data structure has been understood. Avoid averaging them into a single completion score unless the publisher explicitly defines that aggregate.

## Check which date you are seeing

A **report date** is a date supplied by the publisher for the measurement. An **observation date** is when DecompHub read the source. A freshly observed page may contain an older measurement. Repository metadata fetches and listing edits have their own timestamps and do not establish that a progress report is new.

The machine-readable [data documentation](/data) describes how source dates and observation dates appear in exports. Keep the date kind with the value when quoting a result. For a useful citation, include the project, metric, scope, source URL and relevant date together.

## Treat missing or surprising values honestly

Unknown can mean the project has no compatible report, a source was unavailable, the parser could not establish the scope, or collection has not reached a usable source yet. It does not establish that upstream has done no work.

A suspicious percentage also deserves investigation. More than 100%, changing denominators or two conflicting badges can reflect a report error or different scopes. Do not silently clamp a number, turn an unknown value into zero or substitute GitHub stars for progress.

[Browse projects with recorded progress](https://app.decomphub.com/explore?progress=in-progress), open their source links, and compare like with like. If a listing has an incorrect measurement, its report action lets you point to the specific upstream evidence that needs checking.