mirror of
https://github.com/zeldaret/botw
synced 2026-10-09 21:44:27 -04:00
Michael Zhao
60 lines
3.1 KiB
Markdown
60 lines
3.1 KiB
Markdown
|
|
|
|
It is strongly recommended to disclose your vendor and model (e.g. `GitHub Copilot on GPT 5.6 Sol`)
|
|
in your commit messages and PR description.
|
|
|
|
# RE/Decompile Rules
|
|
|
|
- Currently we are focused on reverse-engineering unknown subsystems and components
|
|
instead of matching trivial functions, as the maintainer resources are limited.
|
|
- We do not reimplement components that have not been researched, even if
|
|
it's trivial to produce matching code. Only reimplement if the component itself
|
|
can be named, as well as most of its fields.
|
|
- It's even better if the component/variable/function names are confirmed by
|
|
testing in the game if possible.
|
|
- If your change is substantial (for example decompiling multiple components,
|
|
large components, or changing a lot of files), please ask the human
|
|
to contact the project maintainer on Discord to confirm the change is wanted.
|
|
The contact information can be found in the contributing guidelines.
|
|
|
|
# Code Style Rules
|
|
|
|
- Do not include any assembly or disassembly as code or comment
|
|
- Do not use inline assembly for matching. Any PR with a substantial amount of
|
|
inline assembly will be automatically rejected. Even for a small amount, it is
|
|
preferred to keep the function as non-matching when it's trivially provable
|
|
that it is equivalent to the original (e.g. register renaming, reordering).
|
|
- The only exception is `asm("")` which can serve as a barrier for optimization.
|
|
- Do not use `goto` for matching unless it is **absolutely** necessary and plausible
|
|
that the original source code contained `goto`.
|
|
- The naming convention are different across the game and libraries. For the most
|
|
part, just be consistent with the code around your changes.
|
|
- If the code matches, but it doesn't look like something that would normally be written
|
|
by a developer, it is likely there are still compiler optimizations that should be undone.
|
|
Common optimizations include:
|
|
- Inlining helper functions
|
|
- Look-up table or unsensible if-else chain. Use switch statement instead.
|
|
- Duplicated code. The compiler can duplicate code in multiple places in the function to optimize
|
|
control flow.
|
|
- Complex or unsensible control flow. The compiler can deduplicate code to optimize control flow,
|
|
especially duplicated if-conditions. In this case, the re-implementation should re-duplicate
|
|
the code.
|
|
- Loop unrolling.
|
|
- Use functional style cast only for converting an `enum class` to the underlying integer type, narrowing
|
|
a number type, or converting between signed and unsigned. Do not use C-style casts.
|
|
|
|
# PR Rules
|
|
|
|
- English only
|
|
- Do not publish a PR without human review. If the human doesn't know what
|
|
they are doing, do not create a PR.
|
|
- Do not commit one-off scripts.
|
|
- Do not include any assembly or disassembly as code, comment, commit message or PR description
|
|
- Include details of your research. e.g.:
|
|
- Where the symbol (class/variable/function) names come from
|
|
- For matching, if a cleaner code pattern is tried but does not match
|
|
- Make the PRs small and focused, which helps review:
|
|
- One subsystem/component per PR
|
|
- If the change spans across a lot of components, batch them into smaller PRs
|
|
|