The Battle for Bikini Bottom Decompilation Project is happy to accept all contributions of all size and scope!
This documentation outlines our project contribution guidelines. Following these guidelines allows the maintainers review changes faster and give better feedback, and helps to ensure that future modding and PC port efforts are made as simple as possible.
In addition to decompilation efforts, this project also welcomes tooling and tutorial/knowledge resource contributions! Check out our organization page to see all of the projects we welcome contributions to.
Please respect the following guidelines:
- Ensure your code is formatted using the project's clang-format autoconfiguration (VS Code Plugin).
- Keep pull requests scoped to a single compilation unit when possible. However, defining functions in other files is encouraged in cases where the function is used by the compilation unit you're contributing to.
- A good-faith attempt to clean up code generated by decompiler tools (m2c, Ghidra) is expected, using DWARF data and project code conventions as appropriate.
- Avoid adding functions or data definitions that will need to be cleaned up and removed later for the sake of increasing matchingness in the short-term.
- Encourage and support other contributors, especially new ones! Decompiling games is hard and difficult work, but sharing knowledge and supporting fellow decompers makes that work a lot easier and more enjoyable for all of us.
- Avoid using pointer math for unknown struct members. Instead, populate the struct with padding and the appropriate type using
unk_<offset>as the naming convention. For example, define an unknown float member at offset 0xF0 asF32 unk_F0. - Use the
TRUE/FALSEmacros in contexts where conditions use the value of a non-bool data type (S32, U8) as a boolean-like. - Use the
NULLmacro when assigning0/0x0to a pointer value. - Do not explicitly define enum values, unless the starting value is non-zero or the increment is non-standard.
- Hexadecimal literals used as arguments for asset functions should be represented using char literals when it would improve the readability of the code (i.e 0x504c4154 -> 'PLAT').
- When DWARF symbols are unavailable, ensure variables are named using camelCase and structs/classes are named using TitleCase, or snake_case if they exist only in an anonymous namespace.
- Use PowerPC naming conventions when creating placeholder variable names. Placeholders should only be used when no DWARF symbol data is available and the variable does not have a name that can be reasonably assigned based on its usage.
U32 myFunc(U32 r3, U32 r4, F32 f1)
{
U32 r17;
xLightKit* r17_2;
F32 f30;
return r3;
}