Skip to content
PORTSNATIVE.
HomeCatalog
Web GamesEmulatorsToolsNews
PORTSNATIVE.

A catalog for discovering ports and related projects. We link to official sources and do not host original game files.

ExploreCatalogMy list
InformationAbout usSuggest a portSupportDonationsLegal notice
© 2026 PortsNative
Back to catalog
Fable: The Lost Chapters
PORTSNATIVE

Fable: The Lost Chapters

NATIVE PORTACTION / ADVENTUREWINDOWSALPHA

Fable: The Lost Chapters

TechnologyDecompilation and reconstruction in C/C++

Available forWindows

View official project

About the project

Fable: The Lost Chapters es un juego basado en el éxito de ventas de su antecesor Fable para Xbox, producido por la compañía Lionhead Studios. Fue lanzado para PC el 20 de septiembre de 2005, y para Xbox el 18 de octubre del mismo año.

Official project information

Author's original READMEOpen on GitHub ↗

Fable: The Lost Chapters — Decompilation & Native Modding

An evidence-gated reconstruction of the native 32-bit Windows Fable.exe, targeting readable, buildable C/C++ source and a durable native modding platform.

Actively developed — October 24, 2026. Native C/C++ reconstruction is continuing. Recent local tests render a retail title sprite through recovered drawing routines and validate connected texture-loading and lifetime paths. The existing interactive frontend is an authored integration checkpoint, not proof that the reconstructed native engine boots or that the game is playable. Latest native progress and remaining boundaries.

Run the checkpoint · See current progress · Read the roadmap · Browse the documentation · Project layout and workspace care

<a id="contents"></a>

Contents

  1. Project
  2. Current progress
  3. Run the checkpoint
  4. What works today
  5. Roadmap
  6. Verification pipeline
  7. Documentation
  8. Repository layout
  9. Project boundaries
  10. Why this is tractable

<a id="project"></a>

1. Project

The goal is a full decompilation of Fable: The Lost Chapters for PC: a complete source reconstruction that can be understood, built, tested, and extended.

This is not a source port or a static recompilation of another architecture. TLC already ships as a clean native x86-32 PE built with Microsoft Visual C++ 7.1. The project combines static analysis, donor-symbol recovery, live instrumentation, original-compiler reconstruction, and retail-byte comparison.

The work has three connected outputs:

  • Decompilation: faithful VC7.1-compatible source, one verified function at a time.
  • Runnable reconstruction: recovered startup, frontend, rendering, media, and eventually gameplay systems connected into executables.
  • Native tooling: reusable format, scripting, editor, viewer, and modding knowledge produced by the reverse engineering.

Where to look first: ROADMAP.md is the single task list (done / in flight / next), HANDOFF.md is the one-page resume point, ARCHITECTURE.md explains the source layers, BUILDING.md the toolchain, and CONTRIBUTING.md the landing rules. The full strategy is in FULL_DECOMP.md; every other document is listed in docs/INDEX.md.

On readability. Early landed code modelled this with throwaway local structs (struct T { char pad[0x1a8]; ... }). Since 2026-09-07 the class layouts recovered from the debug PDB are emitted as compilable, PDB-named headers in rebuild/include/engine/, and landed functions are retyped onto them only when the rewritten file still compiles to the identical retail bytes. The "Readability" rows in the metrics below track that conversion; the remaining generic declarations are a worklist, not the intended end state.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="current-progress"></a>

2. Current progress

Latest activity: October 10, 2026. See the native development update for recent recovery and real-GPU validation. This publication updates project status; the newer local source/test checkpoint is not yet merged into main. The generated whole-project figures below remain the September 7 snapshot, not current completion estimates. Native subsystem checkpoint counts must not be added to these totals without a reconciled dashboard refresh.

SnapshotCurrent result
Catalogued retail functions49,568
Verified functional or matching reconstruction18,579 · 37.48%
Byte-identical reconstruction8,082 · 16.30%
Accepted analysis naming quality99.211%
Runnable milestoneAuthored integration checkpoint: boot movies + interactive frontend, Saved Games, and Options screens

Snapshot functional-or-matching coverage is 37.48% of the 49,568-function catalog. Of that verified set, 16.30% is byte-identical C++. The first 5% byte-match milestone has been passed.

<details> <summary><strong>Full generated metrics</strong></summary>

The canonical refresh updates this table from the checked compile, behavior, parity, coverage, and naming reports:

TrackMetricStatus
Analysis DBFunctions catalogued49,568
Analysis DBMechanically named (no FUN_*)100.000%
Analysis DBAccepted naming quality99.211%
Analysis DBUsable reconstruction/navigation names99.913%
Analysis DBCalling convention known77.746%
Analysis DBComplete non-undefined prototype69.174%
ReconstructionCurated sources, VC7.1-compiled and behaviour-gated18,604
ReconstructionVerified functional or matching C++18,579 (37.48%)
Reconstruction— of which byte-identical C++8,082 (16.30%)
Reconstruction— of which hand-written asm bakes (grade asm_bake, not counted as reconstruction)292
ReadabilityLanded sources typed onto shared PDB-named engine headers651
ReadabilityThrowaway local struct T {...} declarations remaining4,417
ReconstructionCompiled sources still honestly DIFFER43
ReconstructionCompiled rows lacking a Ghidra function-start oracle0
Auto-RE intakeGenerated candidates / structural checker PASS1,066 / 1,053
Boot pathGFMain direct-call sites proven257 / 257 (100.00%)
Boot pathCallable authored GFMain phases10 / 10 (100.00%)
Boot pathCurrent Phase 10 direct calls proven21 / 21 (100.00%)
Modern C++23GFMain phases promoted into the modern startup lane0 / 10 (0.00%)

Counts above are from the 2026-09-07 canonical refresh: rebuild/manifest/status.json, rebuild/compile-gate/retail-parity.json, rebuild/COVERAGE.md, and the naming-quality reports.

Generated agent output is tracked separately and is never counted merely because a structural checker accepted it. The 37.48% figure is intentionally the strict, whole-executable denominator. Boot-path figures are a separate view of the 3,952-byte GFMain coordinator, not an estimate of total engineering time. The C++23 startup figure is deliberately separate too: exact x86 parity and readable integration work do not count as a modern port merely because their interfaces are becoming stable.

</details>

The public dashboard is refreshed only after the compile/parity pipeline has settled. Unreviewed background-agent output does not silently change these numbers.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="run-the-checkpoint"></a>

3. Run the checkpoint

This runs the authored frontend/integration checkpoint already published in main. It is not a playable native-engine reconstruction or the newer local retail-title raster test described in the October update.

From the repository root:

powershell -ExecutionPolicy Bypass -File rebuild/build_bootstrap.ps1

Then launch the retail-layout checkpoint with the optional BuffJesus text variant:

.\rebuild\build\bootstrap-Release\FableTLC-Reconstruction-VisualCheckpoint.exe --buff-jesus

Useful switches:

SwitchBehavior
--buff-jesusChanges main-menu strings while preserving retail geometry, actions, videos, and assets.
--skip-boot-videosFast developer launch directly into the frontend.
--retail-videoExercises the recovered retail movie path.
--retail-video-upscaledUses an explicitly generated local 2× video cache when available.

The normal BuffJesus path includes Lionhead, Microsoft, and intro_comp movies. Escape skips the current movie. Retail banks are read from the local game installation at build/runtime; they are not committed to this repository.

For smoke commands, prerequisites, individual movie modes, and the honest runtime boundary, see rebuild/RUNNABLE.md.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="what-works-today"></a>

4. What works today

AreaVerified stateMajor remaining boundary
Analysis databaseNearly complete navigation-quality names with recovered prototypes and calling conventionsResolve the remaining ambiguous types, function starts, and hard naming stragglers
Function reconstructionSee the generated metrics above (byte-identical genuine C++, functional-or-matching, asm bakes reported separately)Continue strict promotion; retype landed code onto the shared PDB-named headers; de-bake the asm_bake grade
StartupRetail-matched WinMain, all ten authored GFMain phases callable, connected exact GFInitialise, progress-display ownershipReplace the remaining GFMain dependency boundaries and pursue whole-coordinator retail parity
FrontendBoot movies, retail-data-driven interactive menus, CUIState-driven main-menu/Save/Options rows, keyboard/mouse/controller navigation, Credits routing, profile/delete/new-profile branches, Continue-to-Saved-Games routing, and retail list/transition soundsVisual sign-off is still open: compare identical retail/reconstruction captures; link native profile persistence and validated save action 0x11 only at their recovered manager/game boundaries
ControlsInteractive capture/cancel/apply, duplicate clearing, W/S/A/D movement expansion, arrow/WASD reset actions, and recovered wheel/arrow ingress for authored scrolling listsFull 31-action Redefine materialization/filtering/coexistence, profile persistence, and remaining controller/action ownership
VideoRetail movie order, end-of-stream advancement, Escape skip, and D3D9 texture publicationReplace the compatibility presentation seam with reconstructed CTexture/CMovie::Draw submission
Particles and lightingAsset reports, billboard/crossed-sprite contracts, blend state, shader assembly, environment/RSA lookup, sky inputsRecover constant semantics, signed/special passes, shadows, and golden viewer captures
Modding researchBroad readers/writers for definitions, levels, terrain, meshes, animation, audio, text, quests, and savesConsolidate them behind safe product workflows and runtime validation
Cut multiplayerPlayer slots, event/package codecs, local initialization, and a grounded revival plan are documentedReconstruct synchronization, seating, lifecycle, and transport before enabling anything

This table is a landing-page summary. Detailed addresses, byte counts, evidence, and caveats live in the subsystem documents (docs/engine/, docs/formats/, docs/pipeline/); the chronological record is docs/journal/.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="roadmap"></a>

5. Roadmap

The roadmap is a checklist, not prose: docs/ROADMAP.md. It has one "current focus" block and seven lanes (repo health, symbols and types, byte-parity reconstruction, runnable frontend, engine subsystem RE, quest-script recovery, modding toolchain), each with [x] done / [ ] open items that point at their owning document. Superseded plans are archived under docs/journal/.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="verification-pipeline"></a>

6. Verification pipeline

Every promoted function passes an evidence chain:

  1. Recover — Ghidra, donor PDB/BSim evidence, runtime traces, and retail bytes establish identity, boundaries, ABI, and behavior.
  2. Author — readable C++03/VC7.1-compatible source is placed in the address-sharded reconstruction tree.
  3. Test — the original VC7.1 compiler builds the function and a focused behavior fixture exercises its contract.
  4. Compare — object .text is compared with authoritative retail bytes, with only real COFF relocation fields normalized.
  5. Land — only reviewed MATCH, RELOCATION_MATCH, or explicitly behavior-only results enter their corresponding honest totals.

The result is intentionally conservative:

  • MATCH means byte-identical.
  • RELOCATION_MATCH means identical after expected relocation normalization.
  • DIFFER remains visible even when behavior passes.
  • ORACLE_MISSING is never guessed into parity.
  • Generated/structural PASS is intake, not reconstruction credit.

Implementation details:

  • decomp pipeline
  • source architecture
  • parity triage
  • methodology
  • toolchain setup
<p align="right"><a href="#contents">back to contents</a></p>

<a id="documentation"></a>

7. Documentation

Inspired by documentation-first projects, this README is the index; deep technical material lives in focused documents.

Start here

DocumentPurpose
NATIVE_STATUS.mdLatest native development update and publication boundaries
HANDOFF.mdCurrent public handoff and historical resume state
ACTIVE_TASK_LIST.mdRanked work with acceptance gates
rebuild/RUNNABLE.mdBuild, launch, smoke, and runtime-boundary instructions
TOOLCHAIN.mdGhidra, BSim, FSE, VC7.1, and local prerequisites
CAPABILITY_INDEX.mdIndex of recovered tooling and format capabilities

Reconstruction

DocumentPurpose
FULL_DECOMP.mdFull-decomp strategy and promotion model
TECHNICAL_BRIEF.mdCurrent architecture, evidence grades, boot status, and modernization boundaries
SOURCE_ARCHITECTURE.mdGenerated, parity, and modern-source boundaries
BSIM_PORT.mdDonor-symbol porting runbook
DECOMP_ACCELERATORS.mdAutomation and throughput options
UNICORN_EMULATION_PLAN.mdOptional bounded x86 behavior-oracle pilot

Runtime, UI, and rendering

DocumentPurpose
FRONTEND_FORMAT.mdRecovered frontend definitions, tables, actions, and transforms
VIDEO_SYSTEM_RE.mdCVideoSys/CMovie, DirectShow, and texture-presentation recovery
PARTICLE_LIGHTING_VIEWER_HANDOFF.mdParticles, billboards, RSA/environment lighting, shaders, sky, and shadows
UI_UPSCALE_PLAN.mdOptional high-resolution cache policy and validation
COOP_REVIVAL.mdEvidence and safe order for the cut multiplayer system

Content and modding

DocumentPurpose
COMPREHENSIVE_MODDING_ENVIRONMENT.mdOverall tool/editor environment
CONTENT_AUTHORING_PLAN.mdSafe content-creation workflow
SYSTEMS_ANALYSIS.mdPer-subsystem maps and moddability verdicts
FINDINGS.mdCross-checked technical findings
FABLE_TLC_REPORTED_BUGS.mdEvidence template for reported game defects

The docs/ directory contains focused references for definitions, BIG archives, textures, meshes, animation, audio, terrain, navigation, quests, scripts, saves, and editor integration.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="repository-layout"></a>

8. Repository layout

PathContents
rebuild/Buildable reconstruction, tests, manifests, oracles, integration, and parity reports
lift/Auto-RE candidate reports, configuration, and durable worker state
ghidra_out/Reproducible labels, APIs, decompilation exports, and naming audits
tools/Ghidra scripts, promotion pipeline, reports, asset/format tools, and smokes
docs/Technical references, plans, runbooks, and handoffs
refs/FSE and other compact reference manifests
work/, snapshots/, dist/Ignored local experiments, generated artifacts, and share packages

See WORKSPACE_LAYOUT.md for ownership and cleanup rules.

<p align="right"><a href="#contents">back to contents</a></p>

<a id="project-boundaries"></a>

9. Project boundaries

  • No retail executable, artwork, video, archive, PDB, or decoded asset is committed.
  • Retail-derived screenshots, texture decodes, model renders, Blender files, and byte-oracle extracts are local-only test outputs and are ignored by Git. Tests must generate them from a user-supplied installation outside the repository.
  • A local retail installation is used as read-only evidence and asset input.
  • Generated agent code is never treated as verified merely because it exists.
  • A visually similar checkpoint is not claimed as the complete retail renderer.
  • A behavior-equivalent function is not claimed as byte-identical.
  • Experimental dependencies such as Unicorn remain optional and isolated from canonical builds until their licensing and technical boundaries are proven.
  • Any tool capable of modifying game data must use explicit staging, validation, backup, and rollback paths.
<p align="right"><a href="#contents">back to contents</a></p>

<a id="why-this-is-tractable"></a>

10. Why this is tractable

  • Fable.exe is a clean MSVC PE32 image without a packer or DRM wrapper.
  • FableScriptExtender contributes a large native scripting/API map.
  • PDB-bearing Lionhead binaries provide rich donor names and type lineage.
  • BSim and reproducible overrides transfer that evidence into retail.
  • The original VC7.1 compiler is available for instruction-level comparison.
  • Two decades of community research cover many data formats while this project concentrates on engine internals and faithful reconstruction.
  • Every promotion is measurable, reviewable, and reversible.

The destination is ambitious, but the next step is always concrete: identify a boundary, recover a contract, compile it with the original toolchain, test it, compare it with retail, and only then count it.

<p align="right"><a href="#contents">back to contents</a></p>
Read official guide
CALIFICACIÓN
—
Loading votes…
Advertisement

PROJECT FILE

Project type
NATIVE PORT
Genre
Action / Adventure
Status
alpha
Original platform
—
Technology
Decompilation and reconstruction in C/C++
Version
—
Updated
—

Target platforms 1

Windows
View on GitHub
Advertisement