a typo on the progress graph site, thought you'd like to know.

We should fix up the code to remove as many compiler warnings as possible while still keeping OK.

Further, we should implement something like this PR for OOT until we are ready to elevate warnings to errors.
zeldaret/oot#768

• readme.md - High level overview, building, and getting started.
  • High level overview
  • Preparing baserom
  • How to set up the repo
  • How to build the repo
  • Day to day workflow (diff.py and maybe symbol rename)
• contributing.md - Contributor's guidelines
  • How to submit a PRs
  • How to respond to reviewer comments
  • Documentation rules
  • Style and naming schemes
  • Build warnings
  • Updating trello cards
• reviewing.md - What to do when reviewing code.
  • When reviewing other people's code please follow the checklist.
  • When someone addresses all of your comments you should approve the changes.
  • If someone does not address your comments and expresses that a different way is better than yours, look for feedback from other contributors. The project lead will have final say in these situations, but the decisions will generally be guided by a consensus of contributors.
  • Reviewer checklist. This is mostly the same as contributor submission checklist.
    • format.sh was run.
    • Files with NON_MATCHING functions are equivalent.
    • make builds a matching ROM (jenkins)
    • Any new compiler warnings that were added are required for matching (check the file that stores warnings)
    • Comments and variables have correct spelling.
    • code and boot segment files are documented. Overlays with documentation are complete.
      • Overlays with documentation are required to have macros to define access to parameters if the parameter uses bitwise access. The params should have an enum otherwise.
    • The following fields are declared in an Actor header file.
      • Main Actor struct
      • Extern'd initVar data.
      • Types used in the actor struct. Specific example would be actionFunc typedefs.
      • Param field macros and/or enums.
      • We have proof that enum/struct/define is needed in another file.
    • New variables & functions should follow standard naming conventions.
      • Constants converted to whichever looks best in context: hexadecimal, decimal, or float
        • Rotation angles should always be in hexadecimal
      • Functions, structs, unions, enums, and typedefs are TitleCase (DmRavine)
        • "Methods" for objects separate the system from the verb with an underscore (DmRavine_Init)
      • Variable names are camelCase (actionFunc)
        • Global variables start with g (gSaveContext)
        • Static global variables start with s (sSphereInit)
      • Macros and enum constants are SCREAMING_SNAKE_CASE (DM_RAVINE_STATE_ACTIVE)
      • Trailing commas in array and struct definitions (see EnJcMatoDamageTable)
• tools.md - description and how to use for the various manually run tools in the repository (diff.py, regconvert, permuter, etc)
  • Regconvert
  • Gfxdis
  • How to add new warnings
  • Diff.py
  • Permuter
  • fixle.sh
  • format.sh
  • mips_to_c
  • gen_mips_to_c_context.py
  • ichaindis.py
  • colliderinit.py
  • actor_symbols.py
  • TODO: Any other tools need documentation?
• tutorial.md - table of contents for the decompilation tutorial.

There has been the never ending discussion of how we should treat the various type of addresses that do not point to vram (ie, can't be derefernced directly).

Currently we use the void* type for holding vram pointers in struct members, temps, function parameters, etc. And cast them to uintptr_t when we need to do arithmetic on them.

We may want to have a distinction for the other numerical addresses.

• Rom address. Personally I would like to propose a RomOffset type, which would be the uintptr_t equivalent for rom addresses, allowing to represent this type, differentiate it from virtual addresses and allow arithmetic on them.
• Segmented address. @EllipticEllipsis brought up this possibility.
• Physical address. Isn't this the same as a rom address? 🤔

Hey I was trying to build this on my Raspberry pi 4 but I ran into a issue

Log:
https://gist.github.com/coreybruce/c3d9916c43bfa0124be599a02a53b9d5

The PlayerAgeProperties name is a holdover from the OoT decomp project because it is used for the two ages in OoT, but it is used for each transformation (and Kafei) in MM.

It would be nice if we could rename it to something that better reflects what it represents in MM. We should also consider if we want to keep the name synced with OoT.

Currently there are two possible options:

• PlayerTransformationProperties
• PlayerFormProperties

Structs to rename

• GameState -> Game
• GlobalContext -> GamePlay

Variable names for Game will be game where possible.
Variable names for GamePlay will be play where possible.

Actor this variables will be renamed to self. These are the derived class actor structs.
Actor thisx variables will be called super or maybe actor. These are the based class actor structs.

Actor constructor/destructor/update/draw methods will be changed to accept the Game base state rather than the GamePlay/GlobalContext derived class.

We will no longer be using submodules.
We also want to move tools that are used as part of building to a separate folder in the tools folder.
We need a specific directory for tools that are meant to be run manually on the command line.
We also want to ensure that there is a good reason for a tool in the root directory of the project.

hi, been a lurker of this project for a while, and i have noticed that "Please don't rebase and force-push: it makes it harder to review since GitHub loses all the comments and it's hard to see what's actually changed." or something along those lines as had to be say more than once(here and on the ocarina), wouldn't it be appropriate then to add this warning on the "Contributing" section of README.md?

what it says on the tin.

Whenever we use u32 or s32 to hold a pointer, we should change it to use uintptr_t or intptr_t instead.