Check your ROM before choosing the port
HarbourMasters Lighthouse requires a supported Banjo-Kazooie ROM; downloading the application does not supply the game. The README lists hashes for US v1.0, US v1.1, Japanese and PAL retail dumps and requires .z64 format. Its setup instructions cover Windows, Linux and macOS and describe generating bk.o2r from the selected ROM.
That is the useful starting point for this review: can you supply a supported dump, and do the documented features suit your intended play? Our sandbox record cannot answer whether the game runs correctly on your machine.
The README describes Anchor multiplayer, a built-in randomizer, controller mappings and an in-app controller mapper. It lists DirectX11 on Windows, OpenGL on all platforms and Metal on macOS. Changing the graphics backend requires a restart. These are documented capabilities, not features we exercised.
What our recorded run establishes
Our stored run took place on 10 October 2026 at commit c09a1f11041f50c2fd86d8aa60f8ee15a3ca13fd, whose recorded commit timestamp is 2026-10-07T17:12:40-04:00. The sandbox configuration recorded 3 CPUs, 8 GB of memory and image ghcr.io/astral-sh/uv:python3.12-bookworm. The install output identifies a Python 3.12.12 environment. Detection selected Python as primary and libultraship as the working subdirectory, while also detecting C++ and CMake.
| Recorded step | Observation | Limit |
|---|---|---|
| Install | Exit 0 after 26.848 seconds, summarized as 27 seconds; dependency summary of 39 packages and 72 MB | The stored tail identifies a Python environment. It does not document a completed native application installation or dependency-download breakdown. |
| Build-labelled step | Exit 0 after 7.2 seconds, summarized as 7 seconds | The stored output tail is empty. The record does not establish which native targets, if any, compiled. |
| Pytest | Exit 5 after 8.527 seconds, summarized as 9 seconds; no tests ran in 0.07s |
The parser recorded 0 passed, 0 failed and 0 total. This invocation supplies no gameplay test result. |
| Pip-audit | Recorded advisory total: 0 | Audit coverage is unknown. This does not establish that Lighthouse or its dependencies are secure. |
The checkout summary recorded 2,513 files, approximately 500,286 source lines, 21.9 MB, four CI workflows and a tests directory. These are recorded inventory summaries, not evidence of exhaustive test coverage. No new execution or complete-log reconciliation was performed for this correction.
The successful command exits do not establish a compiled Lighthouse executable, an installed-binary check, generated ROM assets, a renderer launch or a measured gameplay workload. The pytest result also cannot establish the absence of a native test suite or a product failure.
Release setup and source builds are different tasks
For players, the README's route is to download a release and select a compatible ROM. Linux users may need to mark the AppImage executable. The application then generates the game archive. Additional regional ROMs can supply language packs: PAL adds UK English, French and German; the Japanese ROM adds Japanese.
For contributors, the build guide requires native tooling. Windows instructions use Visual Studio 2022 and its C++ tools; Linux instructions include a compiler, CMake, Ninja, SDL2 and graphics, audio and archive libraries. macOS instructions require Xcode tools and additional libraries. The libultraship submodule must be initialized.
The guide separates ExtractAssets, which generates bk.o2r from a ROM, from GeneratePortO2R, which generates lighthouse.o2r, and the application compilation step. Our short build-labelled step is not evidence that this sequence completed.
The supplied 1.1.0 release page is labelled Hatteras Alfa. Its notes describe extraction, widescreen, audio and other changes. Those release notes report project changes; they are not our benchmark results, and the supplied evidence does not establish that 1.1.0 is the latest release.
Use current modding guidance, with compatibility checks
The current development README says many patched ROMs can be extracted as mods, while warning that most supported romhacks have not been fully tested. Custom .o2r and .otr packages go in the mods folder.
There is an important distinction between the measured commit and the current development documentation. The README at c09a1f1 says romhacks support only a US v1.0 base. The current README instead explains that romhacks originate from US v1.0 ROMs and contain their changes; unchanged content comes from the selected base. With a US v1.1, PAL or Japanese base, the hack's modified text retains its language while other text follows the base. Match the instructions to the revision you use rather than applying the old restriction to current development code.
The current README now lists guides for textures, animations, dialog, models, audio, language packs and level editing. It also describes fast64 as supporting BK64 models and animations. Issue 538, which originally reported missing model documentation, was closed as completed on 22 October 2026 through PR 626. That supports removing the old blanket claim that model guidance is absent; it does not establish that every modding workflow is complete or tested.
Likewise, issue 542 reported demo desynchronization after restarting in version 1.1.0, but was closed as completed on 30 September 2026 after being linked to PR 597. It is a historical report, not evidence of an unresolved defect in current development code. We did not reproduce or independently verify its resolution.
Choose by workflow, then verify on your machine
Banjo: Recompiled is the closest supplied alternative: its README describes another native Banjo-Kazooie port, built with N64: Recompiled and RT64, with mod support and a North American 1.0 ROM requirement. Mupen64Plus serves a different workflow: its repository supplies an emulator core library, and a complete setup also needs plugins and a front end. Neither alternative was tested in our run, so this review offers no performance or compatibility ranking.
Our ratings use a five-point editorial rubric: 1 means substantial documented obstacles, 2 means limited support with major gaps, 3 means a documented route with important verification limits, 4 requires stronger evidence of a complete supported workflow, and 5 requires broad, directly verified evidence. These are judgments about the supplied evidence, not benchmark scores. Unknown adoption and untested compatibility do not earn extra points.
For players, the next step is to verify the ROM hash and follow the release instructions. For contributors, follow the native build guide, generate the required archives and check the gameplay affected by your change. Our recorded harness run does not replace those checks.