* Fix 180-degree camera flip when exiting sub-worlds without cam anim When returning from sub-worlds (jukebox, hospital exterior, etc.) with 3rd person camera active, the camera/player flipped 180 degrees. This happened because SpawnPlayer calls Enter() → TurnAround() before PlaceActor(), and PlaceActor overwrites the ROI direction with the path's standard convention (z = forward). For spawn points with cam anims, OnCamAnimEnd corrected this, but spawn points with m_location=0 (like jukebox exterior) had no correction. Replace m_roiUnflipped with m_needsDirectionFlip flag that tracks world transitions. OnWorldEnabled sets the flag, and the first Tick after PlaceActor completes flips the ROI to backward-z and re-setups the camera. ReinitForCharacter now always flips the ROI direction, handling both Disable→Enable toggles and enabling 3rd person after a 1st-person spawn. https://claude.ai/code/session_01NQ9vy9Qr3aH6LNsRNLEEtY * Fix camera flip regressions for vehicle exit and world transitions The unconditional ROI flip in ReinitForCharacter caused a 180-degree flip when exiting vehicles (Enter's TurnAround follows and double-flips). Restore conditional flip using m_roiUnflipped, but now also set it in OnWorldEnabled (even when disabled) so cold-enabling 3rd person after a world transition correctly flips from PlaceActor's forward-z. Key changes: - Remove m_roiUnflipped clearing from OnActorEnter: Enter() is always followed by PlaceActor which overwrites the ROI, so clearing the flag prematurely caused the cold-enable case to miss the needed flip. - Add orbit camera override in OnActorEnter during world transitions (m_needsDirectionFlip && m_active) to suppress the 1st-person camera flash from Enter's TransformPointOfView. - Clear m_roiUnflipped in OnCamAnimEnd alongside m_needsDirectionFlip, since the cam anim's PlaceActor + flip handles the correction. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Defer orbit camera setup during world transition loading freeze Remove the premature SetupCamera call from OnActorEnter's world transition path. The stale orbit camera view (computed before PlaceActor runs) would freeze on screen during the ~500ms world load, appearing as a wrong-direction flash. The Tick correction after PlaceActor now handles the initial orbit camera setup at the correct position. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Skip orbit camera while cam anim is running to prevent actor glitch When a cam anim plays with 3rd-person camera active, ApplyOrbitCamera was fighting the cam anim each frame. If the cam anim was interrupted (space bar), its end handler read the ViewROI position — which was set by our orbit camera (elevated, behind player) — and placed the actor at that position, causing it to glitch into the air. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add documentation for ROI direction conventions and camera corrections Documents the forward-z vs backward-z conventions, all code paths that require direction correction, and the flags that coordinate them. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Refactor 3rd-person camera from backward-z to forward-z convention Switch the orbit camera to use forward-z (matching PlaceActor's native output), eliminating all FlipROIDirection/TurnAround corrections. The display clone flips to backward-z when syncing from the native ROI so character meshes face correctly. Use actor state (c_disabled) instead of m_animRunning to guard against cam anim conflicts, allowing the orbit camera to resume as soon as the player is released. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Reset orbit camera position on world re-entry Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Remove ShouldInvertMovement and update documentation * Remove header |
||
|---|---|---|
| .github/workflows | ||
| 3rdparty | ||
| android-project | ||
| assets | ||
| CMake | ||
| CONFIG | ||
| docker | ||
| docs | ||
| extensions | ||
| ISLE | ||
| LEGO1 | ||
| miniwin | ||
| packaging | ||
| tools | ||
| util | ||
| .clang-format | ||
| .clang-tidy | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .lfsconfig | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| pyproject.toml | ||
| README.md | ||
| settings.gradle | ||
LEGO Island, portable
Development Vlog | Contributing | Matrix | Forums | Patreon
This initiative is a portable version of LEGO Island (Version 1.1, English) based on the decompilation project. Our primary goal is to transform the codebase to achieve platform independence, thereby enhancing compatibility across various systems while preserving the original game's experience as faithfully as possible.
Please note: this project is primarily dedicated to achieving platform independence without altering the core gameplay or rewriting code for improvement's sake. While those are worthwhile objectives, they are not within the scope of this project. isle-portable offers support for light modding using extensions.
Status
| Platform | Status |
|---|---|
| Windows | |
| Linux | |
| macOS | |
| Web | |
| Nintendo 3DS | |
| Xbox One | |
| iOS | |
| Android | |
| Playstation Vita | |
| Nintendo Switch |
We are actively working to support more platforms. If you have experience with a particular platform, we encourage you to contribute to isle-portable. You can find a list of ongoing efforts in our Wiki.
Usage
An existing copy of LEGO Island is required to use this project.
As it stands, builds provided in the Releases tab are mainly for developers; as such, they may not work properly for all end-users. Work is currently ongoing to create workable release builds ready for gameplay and general use by end-users. If you are technically inclined, you may find it easiest to compile the project yourself to get it running at this current point in time.
Installation instructions for some ports can be found in our Wiki.
Library substitutions
To achieve our goal of platform independence, we need to replace any Windows-only libraries with platform-independent alternatives. This ensures that our codebase remains versatile and compatible across various systems. The following table serves as an overview of major libraries / subsystems and their chosen replacements. For any significant changes or additions, it's recommended to discuss them with the team on the Matrix chat first to ensure consistency and alignment with our project's objectives.
| Library/subsystem | Substitution | Status | |
|---|---|---|---|
| Window, Events | SDL3 | ✅ | Remarks |
| Windows Registry (Configuration) | libiniparser | ✅ | Remarks |
| Filesystem | SDL3 | ✅ | Remarks |
| Threads, Mutexes (Synchronization) | SDL3 | ✅ | Remarks |
| Keyboard/Mouse, DirectInput (Input) | SDL3 | ✅ | Remarks |
| Joystick/Gamepad, DirectInput (Input) | SDL3 | ✅ | Remarks |
| WinMM, DirectSound (Audio) | SDL3, miniaudio | ✅ | Remarks |
| DirectDraw (2D video) | SDL3 | ✅ | Remarks |
| Smacker | libsmacker | ✅ | Remarks |
| Direct3D (3D video) | SDL3 (Vulkan, Metal, D3D12), D3D9, OpenGL 1.1, OpenGL ES 2.0, OpenGL ES 3.0, Software | ✅ | Remarks |
| Direct3D Retained Mode | Custom re-implementation | ✅ | Remarks |
| SmartHeap | Default memory allocator | - | - |
Building
This project uses the CMake build system, which allows for a high degree of versatility regarding compilers and development environments. Please refer to the GitHub action for guidance.
Contributing
If you're interested in helping or contributing to this project, check out the CONTRIBUTING page.