* Match func_802B5450, func_802B5F00, func_802B71CC
* Match func_802B4FF8
Also do some import fixing
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Match func_800AB290 and func_800AC978
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Match func_800A15EC
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Match func_800A1A20
* Get func_800A1F30 to NON_MATCHING
* Match func_800A3C84
mips_to_c does not currently support labels being in delay slots, although
practice that is fine. To get around this I put a nop in the delay slot
instead. No permanent change is being made to the target assembly.
* Update the mips_to_c output for a couple functions
Split asm file containing unused funcs and added mips_to_c output for them.
* Remove extraneous data file
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Match func_800A4B38
* Match func_800A6034
* Change type of "blue" argument
This allows the function's type signature to look the same as the other
box drawing function.
* Match func_800AC300
* Matched func_800AAEF4
* Matched func_800AAF30 and func_800AAF70
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Match func_80021C78
* Match func_8006E8C4
* Match func_80295BF8
* Match func_8001F980 (already matching)
* Match func_800219BC
* Match func_80022A98
* Add item defines
* Update the GfxPool struct and match some functions
Also reordered variables.h a bit
* Match 2 more functions
* Replace reaming ->buffer references with ->mtxPool
Update the mips_to_c output of a couple functions based on new GfxPool
definition
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Match functions related to struct at D_8018EE10
* Remove asm for matched functions
* Match func_800B64EC, func_800B6708, and func_800B6798
* Match func_80091EE4. Fix unused variable warnings in code_80091750.c
* Name some of the fields in struct_8018EE10_entry
* Name variables related to selecting a game from the main menu
* Match a couple functions requiring jumptable
* Match func_800B4728
* Match func_800B536C, func_800B5888, func_800B5AAC, and func_800B5AD8
* Name functions related to loading and validating SaveData
* Match func_800B4CB4
* Update selected player defines
* Match func_800B5404
* Match func_800B6088
* Meaningful commit message
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Identify another struct and array
Regenerated a lot of mips_to_c code based on these identifications
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Rename a function
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Update the mips_to_c code
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
* Decompile a couple code_800AF9B0 functions
* Match func_800B34E8, func_800B44AC, and func_800B45E0
* Use sizeof in func_800B45E0 instead of hard-coded numbers
* Match func_800B4520. Separate unused function func_800B4560 into new asm file
* Match func_800B5B2C and func_800B6A68. Create new unused func_800B6AF8
* Match func_800B4874 and func_800B4A10
* Improve matched functions reading time trial records
* Match func_800B13B0. Name variables related to data menu
* Match func_800B3B58. Remove warnings due to pointer type in osEepromLongWrite calls
* Rename gStartMenuCounterForDemos to gMenuTimingCounter
* Match func_800B5F30
Some of this is identifying some functions and structs related to the Controller
pak menu
Some of it is related to structs concerning textures and "animations" and their
associated functions
* Match draw_box, func_80098C18, func_80098FC8
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
This matches more closely with similar functions in SM64
Identified a LUT for the segmented address of each glyph's texture
CharWidthMap is more accurately called GlyphDisplayWidthMap. The values in
the map don't exactly match the texture width for the given glyph. They
likely have more to do with how the glyph is drawn on screen rather than
being a measure of its true width.
There are other LUT-like entries in data_0DD0A0_2 that clearly contain
glyph textures, but it's not clear how they differ from the "main"
LUT.
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
gNextDemoId is a little weird. If a demo is currently running that variable is the ID
of the demo that will run next. It's never "current", its always one step ahead
Signed-off-by: Taggerung <tyler.taggerung@gmail.com>
Tyler McGavran