Four retail ROMs unlock a native PC port
Lighthouse turns a user-supplied Banjo-Kazooie ROM into the data archive needed by a native Windows, Linux, or macOS application. The project publishes no Nintendo game assets. Its README lists SHA-1 hashes for four supported retail dumps: US v1.0, US v1.1, Japanese, and PAL. That is a firm ownership boundary and a useful compatibility check before downloading anything else. If the file is in .n64 rather than .z64 byte order, the guide points users to a conversion tool.
Once the ROM is accepted, Lighthouse creates bk.o2r and launches the game. The 21.8 MB checkout in our sandbox contained 2,565 files and roughly 497,235 source lines, so this is a substantial game port despite the quick front-door flow. Packaged releases avoid the compiler work. Source builders enter a C and CMake codebase tied to libultraship and generated assets, a much wider surface than the Python environment selected by our generic harness suggests.
Three graphics backends and common controllers cover the main desktop paths
The player-facing setup is sensibly direct. Windows defaults to DirectX 11, macOS defaults to Metal, and OpenGL is available across platforms. A restart is required after changing the renderer. The project includes common controller mappings plus an in-app mapper, while the keyboard uses WASD, arrow keys, and nearby action keys. Fullscreen, reset, menu visibility, and alternate assets all have documented shortcuts.
Regional ROMs can become language packs after the base archive exists. PAL supplies UK English, French, and German, while the Japanese release adds Japanese. Our installation added 39 packages and occupied 72 MB before any copyrighted game archive was generated. Players with several regions must provide each dump themselves, and the README does not blur that requirement. That makes the release convenient, though it never becomes a one-click download of a complete game.
What happened when we ran it
Our sandbox installed Lighthouse's detected Python-side requirements in 15 seconds and built the checkout in 5 seconds. Pip-audit reported 0 known vulnerabilities among the installed packages. Those results come from commit 33de6f0 in a fresh Debian container with 3 CPUs, 8 GB of RAM, no secrets, and no privileged access. The successful build says the checked-out code compiled under that harness. It does not say that we played through Banjo-Kazooie or exercised its graphics backends.
The test step failed with exit code 5 after 7 seconds. Pytest's entire useful result was no tests ran in 0.06s: 0 passed and 0 failed because it collected no cases. The repository has a tests directory and 3 CI workflow files, yet the command available to our harness supplied no automated evidence about gameplay, save handling, asset extraction, or rendering. We cannot infer why collection found nothing from that log alone.
Zero collected tests puts more weight on playtesting
A native game port has failure modes that compilation will miss: cutscene timing, animation state, culling, collectible state, and controller behavior all need the running game. Current issue reports make that concrete. Issue 542 says restarting from the Lighthouse menu can desynchronize demos. Issue 533 reports that the fast-transform option can leave Mumbo's idle animation running too quickly. Both reports concern visible game behavior rather than a compiler or packaging failure.
The August 17 release notes show active fixes in the same territory, including widescreen camera handling, SDL audio buzzing, cutscene screenshake, save-editor additions, and player-animation synchronization. Release 1.1.0 is available for Windows, Linux, and macOS, and the repository was pushed again on August 26, 2026. The 49 open items reported by GitHub combine issues and pull requests, so they should be read as ongoing work rather than 49 confirmed defects.
Romhacks work, while several mod formats lack written guidance
Lighthouse can extract many patched ROMs as mods and can launch a named hack from the command line. The README warns that most supported romhacks have not been fully tested. It also says romhack support inherits a US v1.0 base-ROM restriction from Banjo's Backpack. Issue 549 documents a broken final cutscene in one Nostalgia 64 segment, which is the kind of compatibility gap that the README's warning anticipates without proving that every hack has problems.
Custom .o2r and .otr packages go in the mods folder, but creating them is less settled. Six open documentation issues cover animations, dialog and quizzes, demo input, model work, music, and language packs. Issue 538 says model-modding documentation is absent and the referenced Blender plugin does not yet support BK64. Players consuming an existing package have a clear folder convention. Authors trying to build new asset types may need community help and source reading.
Source builds require native libraries and a recursive clone
The Linux build guide lists GCC or Clang, Git, CMake, Ninja, SDL2, SDL2_net, PNG, ZIP, TinyXML2, spdlog, Boost, OpenGL, Ogg, and Vorbis packages. Windows calls for Visual Studio 2022, its C++ tools and SDK, Python 3, Git, and CMake. macOS needs Xcode tools plus a similar set of libraries. A recursive clone matters because libultraship is a submodule. After configuration, separate targets extract ROM assets and create the port archive before the final executable is useful.
Our 5-second build did not validate a retail ROM, generate bk.o2r, package an AppImage, or launch a renderer. Most players should use release 1.1.0. Contributors need target-platform CI, the asset targets, and manual checks around the gameplay they change.
August 2026 activity supports trying it, not skipping verification
GitHub showed 392 stars, 49 combined issues and pull requests, an August 17 release, and an August 26, 2026 push. Lighthouse suits owners who want this game as a native desktop application and accept ROM extraction. Its renderer choices, controller mapping, language packs, and mod loading exceed plain emulation. Modification is the harder case: 497,235 lines of source, native libraries, generated archives, and 0 collected pytest cases leave contributors dependent on CI artifacts and careful playtesting.