introduce some friendly markdown docs

This commit is contained in:
shibbo 2024-08-11 21:32:38 -04:00
parent 2de688cdb4
commit 2cacaf5e42
3 changed files with 71 additions and 0 deletions

View File

@ -1,4 +1,17 @@
# 3dcomp
<img src="https://github.com/shibbo/3dcomp/blob/main/img/logo.png" width="300">
<img src="https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/shibbo/3dcomp/main/data/decompiled.json" />
<a href="https://discord.gg/QnZ4cKkZm3">
<img src="https://img.shields.io/discord/1133588984883318884?logo=discord"
alt="chat on our Discord"></a>
A decompilation effort for Super Mario 3D World + Bowser's Fury
## Build Instructions
1. Obtain a clean copy of a `main` from Super Mario 3D World + Bowser's Fury Kiosk Demo and rename it to `fury.nso`, and place it on the root.
2. Run `setup.py` to download and install all of the dependencies. These dependencies are `capstone`, `elftools`, `lz4`, `ninja`, and `colorama`. It will also download a zipped file that contains the compiler. It will also check to see if your NSO is the correct one.
3. Run `build.py`, then use `check.py` to verify matching status.
## Contributions
Want to contribute, or learn how to contribute? Try joining our Discord server (link is at the top), and looking into [on contribution guide](docs/CONTRIBUTING.md)! We will be glad to answer any questions for people who wish to contribute. All pull requests and issues are welcome.

6
docs/CHECKING.md Normal file
View File

@ -0,0 +1,6 @@
# Checker Script
The [checker script](https://github.com/shibbo/3dcomp/blob/main/check.py) is the script that is responsible for checking your functions to determine if they match or not. If the function matches, then it will automatically mark a function as "matching". If it does not match, it will not mark it matching. If it was previously marked as matching, it will unmark it. To check your function, be sure to build the project using `python build.py` after setting the project up and then running `check.py`. Whenever there are changes to an object file in the project, `check.py` will automatically check those object file and their functions for matching status. If there are no changes between compilations, then the object files did not change.
* If the function functionally matches and there are tiny differences (such as regswaps or different instruction scheduling), then the function can be marked as "minor" in the `main.map` file.
* If the function does not functionally match, and there are multiple flaws in the logic, then the function can be marked as "major" in the `main.map` file.
* If you are unable to figure out a function, try running `decompme.py <symbol>` on the root to create a scratch, and post it in the server for others to try!

52
docs/CONTRIBUTING.md Normal file
View File

@ -0,0 +1,52 @@
# Contributing
To contribute, you will need the following tools:
* A disassembler, IDA Pro or Ghidra work very well (you can also use a decompiler, it can make some things easier)
* Python 3.7 and higher
It is recommended that you have knowledge of the following:
* C / C++ (however, C++ is STRONGLY recommended)
* Aarch64 Assembly
* Reverse engineering instructions from PowerPC to C / C++
Decompilers such as Hex-Rays (included in IDA Pro) are useful as they can make the decompilation easier to write.
Be sure that all of your submitted code follows the guidelines that are listed below. After the code matches, be sure to run `check.py` to check the function that you want to mark. If it matches, it will automatically be marked as decompiled.
If you have any questions or concerns, please join [our Discord server](https://discord.gg/QnZ4cKkZm3)!
### Headers
* Use `#pragma once` at the top of each header file
* Use forward-declared types when possible
### Includes
* Use `#include<>` for system library includes
* Use `#include "..."` for including game headers, and they must be relative to `include`
### Names
* Names for known symbols should match exactly, even including typoes in the symbol
* Member variables must be prefixed with `m`
### Classes
* Functions for classes must be put in this order: constructor, destructor, operators, virtual functions, member functions
* If the virtual functions are not in the order that they are in the vtable, then the rule above can be ignored as these functions must be placed in order
* When referencing a class member, do not use `this->`, unless it is required for compilation
### Matching
To see how to use the checker scripts, see [the checking guide](CHECKING.md)!
### Pull Requests
Before you make your pull request, ensure the following:
* Your code compiles. We will not accept code that does not compile.
* Your code follows the standards written above.
* You have ran `clang-format` on your code.
* Your code is not copypasted or stolen from other sources (and if you do use code from another repository, please give credit)
* The locations of where you put the include / source files makes sense. If you are unsure, make a note or ask us in the Discord server.