isle-portable replaces the Windows libraries under LEGO Island with SDL3

A decompilation project with a porting goal on top

isle-portable is a portable version of LEGO Island, version 1.1 in English, based on the decompilation project. The README states the primary goal plainly: to transform the codebase to achieve platform independence, enhancing compatibility across various systems while preserving the original game's experience as faithfully as possible.

The distinction from the base decompilation project matters. This is not a reimplementation of the game, it is a port of recovered original source code. The base project lives at isledecomp/isle, and this repository takes that recovered code and replaces the parts that assume Windows.

The scope boundary is stated just as clearly, and it is a good example of a project resisting the usual creep. The README says the project is primarily dedicated to achieving platform independence without altering the core gameplay or rewriting code for improvement's sake, and that while those are worthwhile objectives they are not within the scope here. Light modding is supported through an extensions directory, so the door is open a crack rather than wide.

The pattern is the same: recover the original source from the shipped binaries, then build something runnable and analysable from it.

The licence is LGPL-3.0, which fits the way the work is done. An LGPL project can be used in a larger work under its own terms, and the port inherits that structure from the code it was derived from.

Fourteen platforms, and the CI badge on every row

The support table is the headline of the README, and it is a long one. The listed platforms are Windows on x86, x64 and arm64; macOS on arm64 and x64; Linux on x64 and arm64; FreeBSD on x64; DOS on x86; Web, with a link to isle.pizza; iOS; Android; Xbox One; PlayStation Vita; Nintendo Switch; and Nintendo 3DS.

Every row carries a CI badge pointing at the same workflow, which means the table is not a wish list but a list of platforms the build actually runs on. The coverage spans the full range: from a DOS build for the era the game came from, through desktop systems, to a web build, to mobile, and to four console platforms.

The README says the team is actively working to support more platforms and invites contributions from people with experience of a particular platform. There is a wiki page listing ongoing port efforts, so the state of each platform's work in progress is tracked in a way a reader can consult before offering help.

The project also has a development vlog on YouTube, a Matrix chat, a forum, a Patreon for the maintainer, and a CONTRIBUTING.md. The presence of a vlog rather than only commits is a signal about the nature of the work: porting a 1997 codebase to a console is a long project where the interesting decisions happen slowly, and a vlog is how that gets communicated.

The release situation is a single continuous build rather than numbered versions. The release tag is called continuous and is dated 2026-10-15.

SDL3 replaces the window, filesystem, threads, input and video

The library substitution table is the most technically informative part of the README, and it shows the shape of the porting effort.

SDL3 does most of the work. It replaces the window and event subsystem, the filesystem, the threads and mutexes used for synchronisation, the keyboard and mouse input that had been DirectInput, the joystick and gamepad support, the audio that had been WinMM and DirectSound, and the 2D video that had been DirectDraw. For 3D, SDL3 covers it through Vulkan, Metal and D3D12, and the table also lists D3D9, OpenGL 1.1, OpenGL ES 2.0, OpenGL ES 3.0 and a software path as the alternatives in the substitution column.

The pattern of a single library absorbing six or seven subsystems is the reason a port like this is possible at all. SDL is a portability layer, and a game that was written against Win32, DirectDraw, DirectInput and DirectSound has four separate platform couplings to remove. Replacing all of them with one library that already abstracts over the same ground is a coherent strategy.

The non-SDL substitutions follow the same logic. The Windows Registry, which held configuration, is replaced by libiniparser, an INI file parser. The Smacker video codec, which was a third party library, is replaced by libsmacker, a separate implementation. Audio additionally uses miniaudio alongside SDL3. The Direct3D retained mode layer is marked in the table as a custom re-implementation rather than a library substitution.

The README asks that any significant library change be discussed with the team on Matrix first, so that the substitutions stay consistent with the project's objectives rather than accumulating one-off dependencies.

An existing copy of the game is required

The usage section contains the one requirement that catches people out. An existing copy of LEGO Island is required to use this project.

That follows from what the repository contains. The top level has ISLE/, LEGO1/, 3rdparty/, assets/, CMake/, CONFIG/, util/, tools/, miniwin/, extensions/, installer/, packaging/, android-project/ and docker/ directories, and the code is arranged as recovered original source rather than as a self-contained distribution. The game data itself, the levels, the sounds and the video, is not in the repository, and the .lfsconfig and .gitattributes files show that Git LFS is in play for at least some assets.

Installation goes through a guided installer hosted on GitHub Pages at isledecomp.github.io/isle-portable, which walks through the installation on every supported platform step by step using the builds from the continuous release tag. The installer's own source lives in the installer/ directory and is deployed to Pages from master.

The README is candid about the tradeoff of continuous builds. They are builds of the latest master, so an occasional regression is possible, and if something does not work the request is to open an issue. There is no stable release to fall back on, which is the normal arrangement for a project where the platform coverage is still growing, and it means a user is effectively testing the current state of the port.

Developers can build from source instead, and the repository has a CMakeLists.txt at the top level, a CMake/ directory of modules, a .clang-format and a .clang-tidy for style, plus a settings.gradle for the Android project.

Where this project is deliberately not going

The first limit is the one the project sets for itself. The README rules out altering core gameplay and rewriting code for improvement's sake, and says so directly. If you want a remastered LEGO Island with better controls, new content or a modern engine, this is not it, and the extensions system is described as light modding rather than as a content platform.

The second is the asset dependency. Requiring an existing copy of the game means the project cannot be tried by downloading a single file, and it puts the burden of a legitimate copy on the user. For a preservation project built on decompiled code, that is a deliberate legal posture rather than an inconvenience, and it is the same posture that makes the decompilation itself defensible.

The third is the platform coverage in practice. A CI badge means the code compiles for a platform, not that the game is complete and polished there. Consoles in particular have their own requirements around input, saving, packaging and certification, and the wiki's list of work in progress is the honest place to look at how finished each port is. A DOS build also has to run on hardware the original was never written for.

The fourth is the C++ and CMake toolchain. There is a .clang-format, a .clang-tidy, a CMake build with modules, a Python-based pyproject.toml carrying only a flake8 configuration with a 120 character line limit, and Gradle for Android. That is a substantial toolchain for a codebase whose goal is to look like 1997 code, and it is the cost of keeping the recovered source buildable by modern tooling on a dozen platforms.

Editorial conclusion

isle-portable suits someone who owns a copy of LEGO Island and wants it running on a platform it was never shipped for, and it is the wrong tool if you are looking for a modern game, because the project's stated scope is platform independence with the original gameplay preserved and no rewriting for improvement. Before you start, note that an existing copy of the game is required, since the project ships the code and not the assets. Verify first that your platform is in the support table, and expect the continuous release builds to be the most likely source of a regression, since they track master.

Frequently asked questions

Official sources

1. isledecomp/isle-portable on GitHub
2. Issues
3. License: LGPL-3.0
4. README
5. Releases