Git Product home page Git Product logo

isle's Introduction

LEGO Island Decompilation

Development Vlog | Contributing | Matrix | Forums | Patreon

This is a work-in-progress decompilation of LEGO Island (Version 1.1, English). It aims to be as accurate as possible, matching the recompiled instructions to the original machine code as much as possible. The goal is to provide a workable codebase that can be modified, improved, and ported to other platforms later on.

Status

Currently, ISLE.EXE is completely decompiled and behaves identically to the original. A handful of stubborn instructions are not yet matching; however, we anticipate they will as more of the overall codebase is implemented.

LEGO1.DLL is still incomplete and cannot be used for gameplay at this time. If you would like to use this, it is instead recommended to pair the recompiled ISLE.EXE with the LEGO1.DLL from the original game.

Building

This project uses the CMake build system, which allows for a high degree of versatility regarding compilers and development environments. For the most accurate results, it is recommended to use Microsoft Visual C++ 4.20 (the same compiler used to build the original game). Since we're trying to match the output of this code to the original executables as closely as possible, all contributions will be graded with the output of this compiler.

These instructions will outline how to compile this repository into accurate instruction-matching binaries with Visual C++ 4.2. If you wish, you can try using other compilers, but this is at your own risk and won't be covered in this guide.

Prerequisites

You will need the following software installed:

  • Microsoft Visual C++ 4.2. This can be found on many abandonware sites, but the installer can be a little iffy on modern versions of Windows. For convenience, a portable version is available that can be downloaded and used quickly instead.
  • CMake. A copy is often included with the "Desktop development with C++" workload in newer versions of Visual Studio; however, it can also be installed as a standalone app.

Compiling

  1. Open a Command Prompt (cmd).
  2. From Visual C++ 4.2, run BIN/VCVARS32.BAT x86 to populate the path and other environment variables for compiling with MSVC.
  3. Make a folder for compiled objects to go, such as a build folder inside the source repository (the folder you cloned/downloaded to).
  4. In your Command Prompt, cd to the build folder.
  5. Configure the project with CMake by running:
cmake <path-to-source> -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RelWithDebInfo
  • Visual C++ 4.2 has issues with paths containing spaces. If you get configure or build errors, make sure neither CMake, the repository, nor Visual C++ 4.2 is in a path that contains spaces.
  • Replace <path-to-source> with the source repository. This can be .. if your build folder is inside the source repository.
  • RelWithDebInfo is recommended because it will produce debug symbols useful for further decompilation work. However, you can change this to Release if you don't need them. Debug builds are not recommended because they are unlikely to be compatible with the retail LEGO1.DLL, which is currently the only way to use this decompilation for gameplay.
  • NMake Makefiles is most recommended because it will be immediately compatible with Visual C++ 4.2. For faster builds, you can use Ninja (if you have it installed), however due to limitations in Visual C++ 4.2, you can only build Release builds this way (debug symbols cannot be generated with Ninja).
  1. Build the project by running nmake or cmake --build <build-folder>
  2. When this is done, there should a recompiled ISLE.EXE and LEGO1.DLL in the build folder.

If you have a CMake-compatible IDE, it should be pretty straightforward to use this repository, as long as you can use VCVARS32.BAT and set the generator to NMake Makefiles.

Usage

Simply place the compiled ISLE.EXE into LEGO Island's install folder (usually C:\Program Files\LEGO Island or C:\Program Files (x86)\LEGO Island). Unless you're a developer, disregard the compiled LEGO1.DLL for now as it is too incomplete to be usable. Alternatively, LEGO Island can run from any directory as long as ISLE.EXE and LEGO1.DLL are in the same directory, and the registry keys (usually HKEY_LOCAL_MACHINE\Software\Mindscape\LEGO Island or HKEY_LOCAL_MACHINE\Software\Wow6432Node\Mindscape\LEGO Island) point to the correct location for the asset files.

Contributing

If you're interested in helping or contributing to this project, check out the CONTRIBUTING page.

Additional Information

Which version of LEGO Island do I have?

Right click on LEGO1.DLL, select Properties, and switch to the Details tab. Under Version you should either see 1.0.0.0 (1.0) or 1.1.0.0 (1.1). Additionally, you can look at the game disc files; 1.0's files will all say August 8, 1997, and 1.1's files will all say September 8, 1997. Version 1.1 is by far the most common, especially if you're not using the English or Japanese versions, so that's most likely the version you have. Please note that some localized versions of LEGO Island were recompiled with small changes despite maintaining a version number parallel with other versions; this decompilation is specifically targeting the English release of version 1.1 of LEGO Island. You can verify you have the correct version using the checksums below:

  • ISLE.EXE md5: f6da12249e03eed1c74810cd23beb9f5
  • LEGO1.DLL md5: 4e2f6d969ea2ef8655ba3fc221a0c8fe

isle's People

Contributors

andoryuuta avatar angeltomkins avatar brandougherty avatar coremaze avatar crtdll avatar cuckydev avatar cydra avatar danielhejduk avatar dimaleon2000 avatar disinvite avatar ecumber avatar foxtacles avatar itsmattkc avatar itzswirlz avatar jonschz avatar ktkaufman03 avatar madebr avatar mishaproductions avatar mosswg avatar paulkaefer avatar ramen2x avatar stoneddiscord avatar stravant avatar tahg avatar ther4k avatar tntexplosivesltd avatar vmidz avatar wamwoowam avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

isle's Issues

Feature: Run the Ghidra import script run in CI

  • Try to make the Ghidra script run in GitHub Actions
  • If that works:
    • Set up a user account for the CI
    • Automatically run the script on new merges to master

based on #909 (comment)

Notes:

Discussion: Should we specify a canonical location for the retail binaries within the repository?

Currently, there appear to be multiple conventions for the location of the retail files.

  • The CI downloads them to /legobin, which is not ignored by git.
  • The legacy files are ignored by git when placed directly under the repository root, suggesting that some people put them there.
  • At least one person prefers to keep them outside the directory entirely (see #909 ).

A common standard would be preferable so the Ghidra import script would not need a configuration file. It would also make scripscripts for common workflows more shareable.

What do you think?

Bug: The import script re-imports some functions that have not changed

Some functions are always incorrectly detected as having been changed. This is not a major issue, but it's still a little confusing: You see Changed functions: 130 when 0 would be correct.

Tasks:

  • Reuse and verify all kinds of types instead of re-recreating them every time (e.g. Enums)
  • Correct difference detection for functions whose return types is larger than 4 bytes
    • These are imported correctly, but Ghidra modifies them on creation, so the delta detection fails on the next run

Feature: Support stubs in Ghidra Import script

  • Make the Ghidra import script import names, addresses and call type for stubs instead of ignoring them
  • Don't import arguments, as we will lose Ghidra's automatic argument detection otherwise
  • Consider adding a note/comment in Ghidra that this function is a stub, and auto-remove / change that when the stub is changed to a function

based on #909 (comment)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.