How to read decompilation progress reports
By DecompHub · Updated · English
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 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. 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 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 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 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, 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.