Skip to content

Latest commit

 

History

History
103 lines (68 loc) · 3.32 KB

CONTRIBUTING.md

File metadata and controls

103 lines (68 loc) · 3.32 KB

Development guidelines

Workflow

Initial build:

  • Compile the project (described in the next section)
  • Copy build/Tomb1Main.dll and the cfg directory to your TombATI directory

Subsequent builds:

  • Compile the project
  • Copy build/Tomb1Main.dll to your TombATI directory (we recommend making a small batch or other script file to do this)

Compiling on Ubuntu

  • With Docker:

    Make sure to install Docker and make, then run make docker_build. The DLL should appear in the build/ directory.

  • Without docker:

    Install dependencies:

    • sudo apt-get install -y gcc-mingw-w64-i686
    • sudo apt-get install -y make
    • sudo apt-get install -y git
    • sudo apt-get install -y python3
    • sudo apt-get install -y python3-pip
    • python3 -m pip install --user pyjson5

    Then for a clean build, run:

    • make clean build

    For a debug build, run:

    • make clean debug

    For incremental builds remove clean from the above. The DLL should appear in the build/ directory.

Compiling on Windows

  • Using WSL:

    Install WSL (video guide: https://www.youtube.com/watch?v=5RTSlby-l9w)

    • Run Powershell as Administrator
    • Copy and paste the following command: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
    • Restart the computer
    • Go to Windows App Store
    • Install Ubuntu

    Run WSL and continue with the instructions from the Compiling on Ubuntu section.

  • Using Visual Studio:

    TBD

Decompilation guidelines

Each function should be ported in a separate commit. After porting each function, please update the progress map by editing the docs/progress.txt file and executing make docs.

Autogenerated parts

Parts of the code are autogenerated. To make sure they stay up to date, please run make autogenerated. If for some reason you can't run it, don't worry, our CI pipeline will show you what need to be changed in case of mistakes.

Code formatting

This project uses clang-format to take care of automatic code formatting. To ensure your code conforms to the standard, please run make lint after each commit. If for some reason you can't run it, don't worry, our CI pipeline will show you what need to be changed in case of mistakes.

Branching

We commit via pull requests and avoid committing directly to master, which is a protected branch. Each pull request should have at least one approval before merging. We never merge until all discussions are marked as resolved and generally try to test things before merging. When a remark on the code review is trivial and the PR author has pushed a fix for it, it should be resolved by the pull request author. Otherwise we don't mark the discussions as resolved and give a chance for the reviewer to reply. Once all change requests are addressed, we should re-request a review from the interested parties.

New version releases

New version releases happen automatically whenever a new tag is pushed to the master branch with the help of GitHub actions.

Supported compilers

Please be advised that any build systems that are not the one we use for automating releases (= mingw-w64) come at user's own risk. They might crash or even refuse to compile. Pull requests are welcome, but those other toolchains will be always considered supplementary.