n64decomp / mk64 Goto Github PK

View Code? Open in Web Editor NEW

578.0 578.0 66.0 415.44 MB

A speedy Mario Kart 64 decompilation, brought to you by the cousin of a tame racing driver.

Makefile 2.81% Assembly 8.69% Python 0.56% C 87.43% C++ 0.48% Shell 0.02% Dockerfile 0.01%

mk64's People

Contributors

Stargazers

Watchers

Forkers

farisawan-2000 kelebek1 booshsource jaideep25 duncanspumpkin pmarkive sostk mattschlosser tehzz guimmp92 classicvalues tmcg2 mk64mp coderstig wsluser valandil maciekbaron chieffruitcake mikeymikeftw emupedia mikerqwertyuytr43 megamech runthecoins speedruntooked lollipopman121 coco875 newpersonhere patch-griff mlohdael vdavid003 llonsit tailscreatesstuff32 vicenteicc2008 i-do-cpp wcolding 0xglitchbyte zek-c xdonedude shakeheartbreak cfillak weeblizer-1 thomasjrathbun itzswirlz spazzylemons aloxado320 fazanaj tommirommi just-archives markusbkk mistersheeple kyniselen unspaghettifykart alyxdeburca sonicdcer gongli1231 darkbattle0000 jtl3d inspectredc zestydevy manupawickramasinghe doublederek justincute3vercelhunnit silvercard

mk64's Issues

Delete gGfxSPTaskOutputBufferSize if possible

This probably requires GCC PR merged first.

But thus far it seems the bufferSize variable isn't really necessary. Should be able to do like an ARRAY_COUNT() macro or similar.

However, when it gets removed everything gets shifted. And it might be weird having a GFX_OUTPUT_BUFFER_SIZE of 0x3f01
That doesn't work of course because the output buffer is a u64 so that actually makes it too big.

Player struct

There's a duplicate player struct. Can we remove that? (It was required to match, but maybe not anymore)

Player stuff go in own header?

Vec3f and what not should go in ultratypes.h

or mk64.h

Assembler Formatting Warning other_textures.s

data/other_textures.s: Assembler messages:
data/other_textures.s:1423: Warning: end of file not at end of a line; newline inserted

Create define for gCharacterSize

~~f32 D_800DDBD4[] = {~~
f32 gCharacterSize[] = {
0.75f, 0.75f, 0.75f, 0.75f,
0.75f, 0.75f, 0.75f, 0.75f
};

Maybe in a player_defines.h file? or just in defines.h.

Fix flashing text array

D_02007BB8 array doesn't match as one whole array in this function:

D_02007CD8 matches but &D_02007BB8[18] does not.

Probably need to make D_02007BB8 a 3D array. But didn't do that for now.
This issue maybe depends on GCC PR merged first.

Gfx *func_800959F8(Gfx *displayListHead, Vtx *arg1) {
    s32 index;

    if ((s32) gTextColor < TEXT_BLUE_GREEN_RED_CYCLE_1) {
        index = gTextColor;
    } else {
        index = ((gTextColor * 2) + ((s32) gGlobalTimer % 2)) - 4;
    }
#ifdef AVOID_UB
    if (arg1 == D_02007BB8) {
        gSPDisplayList(displayListHead++, D_800E84CC[index]);
    } else if (arg1 == &D_02007BB8[18]) {
        gSPDisplayList(displayListHead++, D_800E84EC[index]);
    } else if (arg1 == &D_02007BB8[36]) {
        gSPDisplayList(displayListHead++, D_800E850C[index]);
    }
#else
    if (arg1 == D_02007BB8) {
        gSPDisplayList(displayListHead++, D_800E84CC[index]);
    } else if (arg1 == D_02007CD8) {
        gSPDisplayList(displayListHead++, D_800E84EC[index]);
    } else if (arg1 == D_02007DF8) {
        gSPDisplayList(displayListHead++, D_800E850C[index]);
    }
#endif


    return displayListHead;
}

wasm port?

would it be possible to port this to wasm through emscripten or other?

asm/code_8001F980.s:3150: Error: invalid operands `lw $a0,%lo(D_800DC4DC)$a0)'

Change from #11 breaks assembler.

mips64-elf-as -march=vr4300 -mabi=32 -I include -I build/us --defsym F3DEX_GBI=1 -o build/us/asm/code_8001F980.o asm/code_8001F980.s
asm/code_8001F980.s: Assembler messages:
asm/code_8001F980.s:3150: Error: invalid operands `lw $a0,%lo(D_800DC4DC)$a0)'
make: *** [Makefile:206: build/us/asm/code_8001F980.o] Error 1

mk64/asm/code_8001F980.s

Line 3150 in 850e3b2

/* 023468 80022868 8C84C4DC */ lw $a0, %lo(D_800DC4DC)$a0) # -0x3b24($a0)

Going back to what it was makes it build.

Making the rom shiftable; known bugs

It's likely that most shift bugs are due to segments colliding with each other. The below should be entirely outdated.

Memory Pool Hard-coded

The memory pool end addr is hard-coded. This needs to be fixed.
Segment addr in segments.h is also hard-coded. This needs to be fixed.

Bug tracker for rom shifts.

The rom appears to be shiftable. However, some segments are directly beside each other. As such, segments need to be manually moved to prevent segment overlap.

To test with TAS: http://tasvideos.org/Game/n64-mario-kart-64.html
Requires windows and Bizhawk v1.11.6

Note that these bugs do not exist in the stock build, only when modifying the game.

Bugs

Extreme shifts of 0x9C40:

Audio issues tracked to gDefaultPanVolume

.skip 50000:

game will not boot.

Segments other than the main segment may still have issues.

Todo:

Allow entry.s to shift (It can only shift from the end not the beginning)
Check segment 2 and 3 for shiftability.

Hook test 3850

CI8s that reference the same tlut do not match

Each CI8 that references it's own tlut appears to match just fine. However, if multiple textures use the same tlut, they do not match. This issue does not discuss the tlut. It matches. The issue is the texture itself.

There appears to be some sort of constant diff

Comma delimited (csv) data:
Column#, target, compiled, difference
texture_data_decimal.csv

target: top

target: left
compiled: right

Fix Compile Warnings & General Maintenance

Fixing up warnings will really help a lot when trying to make new tools, edit the build system, match functions, and just working with the project in-general. Note that main.c, memory, etc. have already had some work done to get rid of warnings.

Makefile

Beatify makefile. Well no. But clearer organization would be nice.
Add verbose $(V) to every compile command
Implement linker preprocessing

Done

Post warning fixup

Format Arrays using clang or whatever
Maybe actually implement clang into the repo properly

Other

Fix course_data building everytime make is run
If possible, all definitions for segmented assets/addr should all be in the same header.
Typedef structs

Consistent Ceremony/Ending Naming

Ceremony scene, credits, ending scene, cinematic, etc.

All these terms are likely used in the code-base to describe the ceremony scene.

Any ideas for choosing one to be consistent?

Podium Ceremony
has too many characters, but it's not a bad option. It does describe relatively well albeit clunky what it's for.
This is the proper term for this.
Ending scene
Not great but good to refer to ceremony and credits.
Cinematic
Well, it is a cinematic
Credits
Clearly, the credits is the credits. But where ceremony scene and credits start/end is kinda a question in the code. (they overlap so it's hard to choose a specific name)

Decide on name for waypoints

Trackwaypoints?
Pathwaypoints?

Just waypoints or path?

CoursePath
CourseWaypoints

Add script to fix windows line endings.

Tried a script from zeldaret. Didn't comprehend how it worked.

Windows line endings result in unknown character warnings.

Update recomp

Windows users have an issue with an include. The most recent version of recomp will likely fix this.

As such, this is just a reminder to update recomp.

https://github.com/decompals/ido-static-recomp

Should likely be added as a submodule

mk64.u.966260.bin

Rename this file to like audiobanks.us.bin or something.

Remaining functions to decomp

100% Match not necessary. Func Equivallency is good too. Don't forget to click "Family" in-case there are cleaner matches as some matches may be very fake-matchy.

render_objects

Function	Decompme	Comments
func_8004C6FC	https://decomp.me/scratch/TqXqn	There's an unexpected `mov v1,v0` and some register allocation differences
func_8004F168	https://decomp.me/scratch/FxA1w	See comment at decompme link for an explanation of the problem
func_80050E34	https://decomp.me/scratch/PvJ5D	Handling of the `player` variable is weird. The instructions are correct but out of place

code_8006E9C0

Function	Decompme	Comments
func_8006FA94	https://decomp.me/scratch/ohbAc	Register allocation differences, especially in the first for-loop. Smaller issues are probably the result of some single-line-multiple-variable assignment shenanigans

update_objects

Function name	Decomp.me link	Comments
func_80080E8C	https://decomp.me/scratch/YMJDJ	I think this is functionally identical (not 100% certain), I have no idea what the source of the diff is
func_80082F1C	https://decomp.me/scratch/RquH0	Register allocation differences, probably related to `D_800E5DF4` in some capacity
func_80086074	https://decomp.me/scratch/th08i	Register allocation differences, source unknown

code_800AF9B0

Function	Decompme	Comments
func_800AFC54	https://decomp.me/scratch/ldkgz	diffs
func_800B0004	https://decomp.me/scratch/TbO9o	Really dumb register allocation diff

save

Function	Decompme	Comments
func_800B5218	https://decomp.me/scratch/KOZ5J	func_equiv, stack diff, really close to ok
func_800B578C	https://decomp.me/scratch/wDbXx	missing asm, close to ok
func_800B68F4	https://decomp.me/scratch/NFjo1	reg alloc, close

code_80057C60

Function	Decomp	Comments
func_8005F90C	https://decomp.me/scratch/WjMqd	reg alloc. Appears to be func equiv
func_80065AB0	https://decomp.me/scratch/hdgHd	Missing stack variables or incorrect gfx macros
func_80065F0C	https://decomp.me/scratch/KEz08	Lots of diffs

Vehicles/AI pathing
code_80005FD0

Function	Decomp	Comments
func_800074D4	https://decomp.me/scratch/QeMFt	Matched :) !!!NEEDS A PR!!!
func_80007D04	https://decomp.me/scratch/xt5nz	Matched :) !!!NEEDS A PR!!!
func_800088D8	https://decomp.me/scratch/2pzjG	wip
func_8000929C	https://decomp.me/scratch/9li7Y	Weird stack issue
func_80009B60	https://decomp.me/scratch/uJCh3	reg alloc, minor asm diffs. See comments in the decmopme link
func_8000B140	https://decomp.me/scratch/ZtfJ3	lots of diffs
func_80017054	https://decomp.me/scratch/Ck7hV	Large diff, seemingly related to an empty `if` statement. There's also an unused `double`, don't know if its part of this function or the one after it
cpu_use_item_strategy	https://decomp.me/scratch/FOlbG	Some diffs, 10k score

code_80091750

Function	Decomp	Comments
func_80097274	https://decomp.me/scratch/DSi6A	Real close
func_8009195C	https://decomp.me/scratch/dXpT5	Some math reordering weirdness
func_80096CD8	https://decomp.me/scratch/xV83r	Weird issues
func_80099184	https://decomp.me/scratch/NAZ12	Register allocation differences
func_80099394	https://decomp.me/scratch/O2tkD	Register allocation differences
func_8009952C	https://decomp.me/scratch/Wv2MX	Register allocation differences
func_800996BC	https://decomp.me/scratch/hwAAp	Register allocation differences
add_8018D9E0_entry	https://decomp.me/scratch/1BHpa	Stack differences
func_8009F5E0		No decompme link yet. While marked as non-matching there's a ton work left to be done
func_800A09E0	https://decomp.me/scratch/6wA94	Register allocation. This one is a real motherfucker
func_800A1FB0	https://decomp.me/scratch/s1Hod	Lots of register allocation differences, neither the permuter nor I can find any improvements
func_800A474C	https://decomp.me/scratch/mWCHC	Differences seem to stem from the handling of the `textColor` function variable. The permuter reports an improvement if you make it `volatile`, but that seems wrong for several different reasons.
func_800AC458	https://decomp.me/scratch/NzdUC	Register allocation differences

code_80091750
Lots of funcs left 23 unattempted, 29 non_matching.

menus.c

Function	Decomp	Comments
main_menu_act	https://decomp.me/scratch/93qj8
player_select_menu_act	https://decomp.me/scratch/POeGU	Big diffs or outdated decompme

math_util.c

Function	Decomp	Comments
func_802B8614	https://decomp.me/scratch/cwX7l	unused, SpazzyLemons has made interesting progress. Something about the use/calculation of `lenght` is screwy

crash_screen.c

Function	Decomp	Comments
crash_screen_draw_square		Don't even bother trying (func equiv).

audio/external.c

Function	Decomp	Comments
func_800C16E8	https://decomp.me/scratch/99CQl	Register allocation and instruction ordering differences, no idea what the source is. Might(?) be functionally equivalent
func_800C284C	https://decomp.me/scratch/B9kUf	Register allocation differences
func_800C2A2C	https://decomp.me/scratch/TS7EW	Lots and lots of register allocation differences, but might be functionally equivalent
func_800C3724	https://decomp.me/scratch/LpM1t	Lots of work left to be done. Has different US and EU versions
func_800C4398	https://decomp.me/scratch/fmmyb	Stack issues
func_800C4888	https://decomp.me/scratch/cqBii	Probably a variant of `select_current_sounds` from SM64, lots of work left to be done
func_800C4FE4	https://decomp.me/scratch/Lm9EX	Register allocation differences

audio/load.c

Function	Decomp	Comments
audio_init	https://decomp.me/scratch/5FBUM	Register allocation differences. This function is an unholy bastard child of the Shindou and EU SM64 versions of this function with some extra MK64 special sauce thrown in. There are different US and EU versions

audio/synthesis.c

Function	Decomp	Comments
synthesis_process_note	https://decomp.me/scratch/htpLe	Probably func equiv. Mix of SM64 EU & Shindou. Some inaccuracies
func_800B86A0	No decompme :(	Probably a variant of `process_envelope` from SM64. Diff is huge, no idea why. Speculation: the version of the ABI we have/use is horribly horribly wrong but is only noticeably wrong in this specific function

General Cleanup 3

Feel free to help with this.

General Cleanup

Vec3f and similar types should go in ultratypes.h or mk64.h
Rename left over symbols using track_waypoint to just waypoint
Some packed names are left over still they need to be renamed to course_displaylists. The only time 'packed' should be referenced is when the DL actually get packed. I.e. A normal user would never notice that the file is packed.
Goto defines are poorly named. GotoMenuFromQuit --> GotoMenu or similar.
Issue #362 regarding ending/ceremony naming consistency
Typedef structs

CC0 License Request

Hi!

You are mentioned here because you previously contributed to the n64decomp/mk64 repo, a decompilation of the game Mario Kart 64.

There is a move to license the source of that repo under CC0, and for that we need your permission, as past contributors.

Why?

The mk64 decomp source code is currently under no explicit license.

This means authors reserve all rights about the source being shared, modified, ... (see for example https://choosealicense.com/no-permission/) besides the basic rights granted by the GitHub TOS, mainly forking.

This makes many people feel uneasy about using the source, since it's not explicitly allowed to be used.

Note the unofficial stance though, is that people can do whatever they want with the code without having to ask or credit.

The goal is to make that stance official. However to do it properly we need to ask the authors if they are okay with it.

Which license?

CC0 is a license that seems to fit the unofficial stance.

It can be thought of as "public domain", or a more robust version of the Unlicense.

It also has the added benefit that it does not consist of a copyright affirmation, which is good given the murky waters decompilation is in.

Read about CC0:

If you don't care, the best choice to do for the project and users of the project (researchers, fans, modders...) is to agree.

If you agree, you can reply to this issue with some message like "I agree to share all my contributions to the mk64decomp under CC0"

You can also privately DM me on the N64 Decompilation Discord, or MegaMech on the same discord, if you do not wish to leave a public message here.

@Tmcg2 @MegaMech @CoderStig @ItzSwirlz @coco875 @ChiefFruitcake @AloXado320 @MaciekBaron @duncanspumpkin @farisawan-2000 @TommiRommi @tehzz @valandil @VDavid003 @iProgramMC @spazzylemons @i-do-cpp @someone2639

test webhook

Remaining Gfx

code_80057C60.c

func_80065AB0
func_80065F0C
func_80067604
func_8006AFD0

code_80091750.c

A lot (~23 funcs)

hud_renderer.c

Variable, function and file name findings

In kart_attributes.inc.c

The function currently listed as gKartTopSpeedTable is not correct?
*D_800E261C should maybe have that label as it contains the individual top speeds per mode/cc:

D_800E257C is 50cc top speed table
D_800E259C is 100cc top speed table
D_800E25BC is 150cc top speed table
D_800E25DC is Extra top speed table
D_800E25FC is Battle top speed table
(Maybe "target speed" is more accurate?)

gKartTable800E36B0 is the Fast Accel(Triple Tap A) multiplier table

In code_80027D00.c

I believe code_80027D00.c is the player controller as is seems to have kart physics and controller functions.
Tentative renaming to "player_controller.c"?

func_80030FC8 is the acceleration/speed function

unk_09C is current speed
unk_214 is top speed
unk_0C4 is a plus or minus to acceleration dependent on the angle of the surface you're on

There has to be additional speed values somewhere, as unk_09C is largely unaffected by boosting and driving surfaces.
Boosting caps it at unk_214, but you're clearly faster. Driving offroad doesn't reduce unk_09C unless you actively decelerate.

I would agree that func_80030C34 and/or func_80030E00 is responsible for determining normal or fast accel(triple tap a)
In turn, I believe D_80165460 is the resulting variable.

code_8008C1D0.c seems closely related to code_80027D00.c as it uses unk_09C and unk_214.
Perhaps it's related to the AI racers? Or a secondary player file?

unk_0CA can affect the players visual effects.
Bitflags of 0x1000, 0x2000, determine particle effects when being pulled out of water/off course;
dripping water, and charred/smoking, respectively.
0x0000 is no particle "status" effects. Haven't played with other bitflags yet.

It might be tracking player states, as when displayed as a debug variable, the value changed when:
- falling off the course
- when being grabbed by Lakitu
- being lifted by Lakitu.

I'll post any additional finding as(if) I find them.

Link variables in compressed segments

Leaving this here so it doesn't get forgotten.

Currently only done for packed_dl

For common_textures stuff we have a header with all the symbols, but all the symbols are getting their addresses from undefined_syms.txt rather than from the linker.
For the packed_dl stuff, the rule for making the compressed bin file starts with this:

$(COURSE_PACKED_DL): %/packed_dl.inc.bin : %/packed.inc.o
    $(V)$(LD) -t -e 0 -Ttext=07000000 -Map $(@D)/packed.inc.elf.map -o $(@D)/packed.inc.elf $(@D)/packed.inc.o --no-check-sections

That second line, among other things, forces the starting address for symbols to 0x07000000. It also creates an elf file which we use when we make the course_data bin file.
For the course_data bin file we do this:

$(V)$(LD) -t -e 0 -Ttext=06000000 -Map $(@D)/course_data.inc.elf.map -R $(@D)/packed.inc.elf -o $(@D)/course_data.inc.elf $(@D)/course_data.inc.o --no-check-sections

The important thing here is the -R option which in effect tells the linker "Here is an elf file, please use it when looking for symbols but do not include those symbols in your output".

Splat Support

We want splat.

WayPoint needs to be renamed

Waypoint should be considered a single word imo.

Therefore all wayPoint should be renamed to waypoint. Also wayPointX --> waypointX or even just posX

TrackWayPoint --> TrackWaypoint

Remove ALIGN8 from main.h

see title

packed

Packed needs to be renamed to course_displaylists

Stale PRs

Stale PRs may contain good content, but may lack motivation to finish them off.

This issue lists stale PRs so they do not go missing. Feel free to re-open. They were only closed because the builder would have to re-build each PR everytime a merge happened.

Course Data Generation

#341
#339

Splat

#265

Progress.py

#260

COURSES enum

Should not be in common_structs.

Should be in defines.h or types.h or somewhere else.

Personally I think defines.h. because I can't find it quick enough.

Add 100x player capability

Hi,

do you think it would be possible to allow for unlimited players or 100 players

this could be all on one screen or 4 screen split with random or selective player following with camera. Maybe make the 3x other screen follow the leaders of the race

this would be excellent with lan network player capability

buffer related code files go in buffers/

framebuffers.c
and
gfx_output_buffer.c

Should go in a buffers folder just like sm64.

EU builds fail compilation in audio/external.c

Environment:

OS: Ubuntu 22.04.3 via WSL2
GCC: 11.4.0
bintutils-mips: 2.38
libcapstone-dev: 4.0.2-5

eu-1.0 and eu-final builds fail compilation when trying to compile src/audio/external.c
Error logs:

Compiling: src/audio/external.c -> build/eu-final/src/audio/external.o
src/audio/external.c: In function 'func_800C3478':
src/audio/external.c:1128:5: warning: statement with no effect [-Wunused-value]
 1128 |     for(D_800EA1E8; D_800EA1E4 != D_800EA1E8;) {
      |     ^~~
src/audio/external.c:1129:9: warning: implicit declaration of function 'func_800C2A2C'; did you mean 'func_8009CA2C'? [-Wimplicit-function-declaration]
 1129 |         func_800C2A2C(D_80192CD0[D_800EA1E8++]);
      |         ^~~~~~~~~~~~~
      |         func_8009CA2C
src/audio/external.c: In function 'func_800C357C':
src/audio/external.c:1147:18: warning: comparison of integer expressions of different signedness: 's32' {aka 'int'} and 'u32' {aka 'unsigned int'} [-Wsign-compare]
 1147 |         if (arg0 == D_80192CD0[i]) {
      |                  ^~
src/audio/external.c: In function 'func_800C357C_eu':
src/audio/external.c:1163:18: warning: comparison of integer expressions of different signedness: 's32' {aka 'int'} and 'u32' {aka 'unsigned int'} [-Wsign-compare]
 1163 |         if (arg0 == (D_80192CD0[i] & arg1)) {
      |                  ^~
src/audio/external.c: In function 'delete_sound_from_bank':
src/audio/external.c:1743:9: warning: unused variable 'stackPadding' [-Wunused-variable]
 1743 |     s32 stackPadding;
      |         ^~~~~~~~~~~~
src/audio/external.c: In function 'func_800C4FE4':
src/audio/external.c:2035:9: warning: unused variable 'cmd' [-Wunused-variable]
 2035 |     u32 cmd;
      |         ^~~
src/audio/external.c: In function 'func_800C550C':
src/audio/external.c:2136:26: warning: passing argument 2 of 'func_800C5384' makes pointer from integer without a cast [-Wint-conversion]
 2136 |         func_800C5384(i, arg0);
      |                          ^~~~
      |                          |
      |                          s32 {aka int}
src/audio/external.c:2098:34: note: expected 'f32 *' {aka 'float *'} but argument is of type 's32' {aka 'in'}
 2098 | void func_800C5384(u8 arg0, f32 *arg1) {
      |                             ~~~~~^~~~
src/audio/external.c: In function 'func_800C6108':
src/audio/external.c:2417:13: warning: the address of 'D_800E9EC4' will always evaluate as 'true' [-Waddres]
 2417 |         if (D_800E9EC4) {} // ?
      |             ^~~~~~~~~~
src/audio/external.c:2453:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
 2453 |     if ((D_800E9EE4[playerId] > 0.5f) || (D_800E9EE4[playerId] < -0.5f))
      |     ^~
src/audio/external.c:2458:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
 2458 |         D_800E9F7C[playerId].unk_0C = D_800E9EC4[playerId] + D_800E9ED4[playerId] + D_800E9F34[playerId];
      |         ^~~~~~~~~~
src/audio/external.c: At top level:
src/audio/external.c:2459:7: error: expected identifier or '(' before 'else'
 2459 |     } else {
      |       ^~~~
src/audio/external.c:2463:5: error: expected identifier or '(' before 'if'
 2463 |     if (D_800E9F7C[playerId].unk_0C < 0.0f) {
      |     ^~
src/audio/external.c:2467:5: error: expected identifier or '(' before 'if'
 2467 |     if (D_800E9F7C[playerId].unk_0C > 4.0f) {
      |     ^~
src/audio/external.c:2470:16: error: 'playerId' undeclared here (not in a function); did you mean 'Player'?
 2470 |     D_800E9EC4[playerId] = D_800E9F7C[playerId].unk_0C;
      |                ^~~~~~~~
      |                Player
src/audio/external.c:2470:5: warning: data definition has no type or storage class
 2470 |     D_800E9EC4[playerId] = D_800E9F7C[playerId].unk_0C;
      |     ^~~~~~~~~~
src/audio/external.c:2470:5: warning: type defaults to 'int' in declaration of 'D_800E9EC4' [-Wimplicit-int]
src/audio/external.c:2471:25: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
 2471 |     D_800E9F7C[playerId].unk_38 = (D_800E9F7C[playerId].unk_0C / 1.5f) + 0.4f;
      |                         ^
src/audio/external.c:2472:1: error: expected identifier or '(' before '}' token
 2472 | }
      | ^
src/audio/external.c: In function 'func_800C76C0':
src/audio/external.c:3005:29: error: break statement not within loop or switch
 3005 |                             break;
      |                             ^~~~~
src/audio/external.c:3007:21: error: break statement not within loop or switch
 3007 |                     break;
      |                     ^~~~~
src/audio/external.c:3008:17: error: case label not within a switch statement
 3008 |                 case BATTLE:
      |                 ^~~~
src/audio/external.c:3038:21: error: break statement not within loop or switch
 3038 |                     break;
      |                     ^~~~~
src/audio/external.c:3039:17: error: 'default' label not within a switch statement
 3039 |                 default:
      |                 ^~~~~~~
src/audio/external.c:3040:21: error: break statement not within loop or switch
 3040 |                     break;
      |                     ^~~~~
src/audio/external.c: At top level:
src/audio/external.c:3043:9: error: expected identifier or '(' before 'if'
 3043 |         if (D_800E9EA4[playerId] == 0x0000001E) {
      |         ^~
src/audio/external.c:3076:9: error: expected identifier or '(' before 'switch'
 3076 |         switch (gModeSelection) {                        /* switch 4; irregular */
      |         ^~~~~~
src/audio/external.c:3138:5: error: expected identifier or '(' before '}' token
 3138 |     }
      |     ^
src/audio/external.c:3139:1: error: expected identifier or '(' before '}' token
 3139 | }
      | ^
src/audio/external.c: In function 'func_800C9060':
src/audio/external.c:3378:88: warning: pointer targets in passing argument 6 of 'play_sound' differ in signedness [-Wpointer-sign]
 3378 |                 play_sound(arg1, D_800E9F7C[arg0].pos, arg0, &D_800EA1D4, &D_800EA1D4, &D_800E9F7C[arg0].unk_14);
      |                                                                                        ^~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                                        |
      |                                                                                        s8 * {aka signed char *}
src/audio/external.c:1522:82: note: expected 'u8 *' {aka 'unsigned char *'} but argument is of type 's8 *' {aka 'signed char *'}
 1522 | void play_sound(u32 soundBits, f32 *position, u8 arg2, f32 *arg3, f32 *arg4, u8 *arg5) {
      |                                                                              ~~~~^~~~
src/audio/external.c: In function 'func_800C9D0C':
src/audio/external.c:3609:19: warning: passing argument 1 of 'func_800C550C' makes integer from pointer without a cast [-Wint-conversion]
 3609 |     func_800C550C(func_800C21E8(gPlayers[playerId].pos, gPlayers[playerId].characterId + 0x31028000);
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                   |
      |                   f32 * {aka float *}
src/audio/external.c:2130:24: note: expected 's32' {aka 'int'} but argument is of type 'f32 *' {aka 'float '}
 2130 | void func_800C550C(s32 arg0) {
      |                    ~~~~^~~~
src/audio/external.c: In function 'func_800CA984':
src/audio/external.c:3857:45: warning: passing argument 2 of 'func_800C1C88' from incompatible pointer type [-Wincompatible-pointer-types]
 3857 |             temp_v0_2 = func_800C1C88(arg0, &gPlayers[arg0].pos, D_800EA1C8, &gPlayers[arg0].unk_098, (u8) i, 0x31029008U);
      |                                             ^~~~~~~~~~~~~~~~~~~
      |                                             |
      |                                             f32 (*)[3] {aka float (*)[3]}
In file included from src/audio/external.c:6:
src/audio/external.h:200:40: note: expected 'f32 *' {aka 'float *'} but argument is of type 'f32 (*)[3]' {aka 'float (*)[3]'}
  200 | struct Unk_8018EFD8 *func_800C1C88(u8, Vec3f, Vec3f, f32*, u8, u32);
      |                                        ^~~~~
src/audio/external.c: In function 'func_800CAB4C':
src/audio/external.c:3873:8: warning: unused variable 'temp_v0' [-Wunused-variable]
 3873 |     u8 temp_v0;
      |        ^~~~~~~
src/audio/external.c:3872:9: warning: unused variable 'temp_v1' [-Wunused-variable]
 3872 |     u8 *temp_v1;
      |         ^~~~~~~
make: *** [Makefile:571: build/eu-final/src/audio/external.o] Error 1

us version compiles without errors
The error is the same for both eu-1.0 and eu-final

course data renames

Incomplete Doxygen documentation

When generate doxygen documentation not all file and function appears

code_80027D00.c needs to be ran through m2c again

Many of the functions have incorrect types and wrong argument count

Enhancements

Enhancements that might be fun. Shouldn't be anything too big here.

Recording or adding your own staff ghosts?

Probably something cool that could be done.

ROM built with mips64-elf toolchain crashes mupen64plus

This is with latest build and fixed based on what I surmised in #14

Core: Goodname: MARIOKART64 (unknown rom)
Core: Name: MARIOKART64
Core: MD5: 6A644C475DFD19B56F86B59979819484
Core: CRC: 3E505A64 9626FBEE
Core: Imagetype: .z64 (native)
Core: Rom size: 12582912 bytes (or 12 Mb or 96 Megabits)
Core: Version: 1446
Core: Manufacturer: Nintendo
Core: Country: USA
UI-Console Status: Cheat codes disabled.
UI-Console: using Video plugin: 'GLideN64 rev.' v2.0.0
UI-Console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v2.5.9
UI-Console: using Input plugin: 'Mupen64Plus raphnetraw Input Plugin' v1.1.0
UI-Console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.5.9
Core: input plugin did not specify a render callback; there will be no on screen display by the input plugin.
Start listing
Hid enumerate returned NULL
Input Error: No adapters detected

RSP: RSP Fallback disabled !
Core Status: Selected state slot: 6
Core: Using video capture backend: dummy
Core: Game controller 0 (Standard controller) has nothing plugged in
Core: Game controller 1 (Standard controller) has nothing plugged in
Core: Game controller 2 (Standard controller) has nothing plugged in
Core: Game controller 3 (Standard controller) has nothing plugged in
Core: Using CIC type X102
Core: Setting video mode: 3840x2160
[New Thread 0x7fffc4110640 (LWP 1834917)]
[New Thread 0x7fffc390f640 (LWP 1834918)]
[New Thread 0x7fffc310e640 (LWP 1834919)]
[New Thread 0x7fffc290d640 (LWP 1834920)]
[New Thread 0x7fffc210c640 (LWP 1834921)]
[New Thread 0x7fffc190b640 (LWP 1834922)]
[New Thread 0x7fffc110a640 (LWP 1834923)]
[New Thread 0x7fffc0909640 (LWP 1834924)]
[New Thread 0x7fffc0108640 (LWP 1834925)]
[Thread 0x7fffc390f640 (LWP 1834918) exited]
[Thread 0x7fffc4110640 (LWP 1834917) exited]
[Thread 0x7fffc190b640 (LWP 1834922) exited]
[Thread 0x7fffc0909640 (LWP 1834924) exited]
[Thread 0x7fffc210c640 (LWP 1834921) exited]
[Thread 0x7fffc110a640 (LWP 1834923) exited]
[Thread 0x7fffc290d640 (LWP 1834920) exited]
[Thread 0x7fffc310e640 (LWP 1834919) exited]
[Thread 0x7fffc0108640 (LWP 1834925) exited]
Audio: Using resampler speex
[New Thread 0x7fffc0108640 (LWP 1834935)]
[New Thread 0x7fffcdc21640 (LWP 1834936)]
Audio: Initializing SDL audio subsystem...
[New Thread 0x7fffc0909640 (LWP 1834937)]
Core Warning: OSD not compatible with OpenGL core context. OSD deactivated.
Core: Initializing 4 RDRAM modules for a total of 8 MB
Core: Starting R4300 emulator: Dynamic Recompiler

Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault.
0x00007ffff1fc1736 in cart_rom_dma_write (opaque=0x7ffff70a98b8 <g_dev+19407896>, dram=0x7fffd17ee010 "\r\200\032<\300\021Z'\b", dram_addr=4294967288, cart_addr=<optimized out>,
    length=6160) at ../../src/device/cart/cart_rom.c:97
97      ../../src/device/cart/cart_rom.c: No such file or directory.
(ins)(gdb) bt
#0  0x00007ffff1fc1736 in cart_rom_dma_write (opaque=0x7ffff70a98b8 <g_dev+19407896>, dram=0x7fffd17ee010 "\r\200\032<\300\021Z'\b", dram_addr=4294967288,
    cart_addr=<optimized out>, length=6160) at ../../src/device/cart/cart_rom.c:97
#1  0x00007ffff1fdff3f in dma_pi_write (pi=0x7ffff6f28fc0 <g_dev+17832736>) at ../../src/device/rcp/pi/pi_controller.c:100
#2  write_pi_regs (opaque=0x7ffff6f28fc0 <g_dev+17832736>, address=<optimized out>, value=<optimized out>, mask=<optimized out>) at ../../src/device/rcp/pi/pi_controller.c:164
#3  0x00007ffff1fdf221 in mem_write32 (handler=<optimized out>, handler=<optimized out>, mask=4294967295, value=6159, address=<optimized out>)
    at ../../src/device/memory/memory.h:87
#4  r4300_write_aligned_word (r4300=0x7ffff5e274a0 <g_dev>, address=<optimized out>, value=6159, mask=4294967295) at ../../src/device/r4300/r4300_core.c:353
#5  0x00007fffc329a984 in ?? ()
#6  0x00007ffff5e274a0 in ?? () from /usr/lib64/libmupen64plus.so.2
#7  0x00007ffff1fdf221 in mem_write32 (handler=<optimized out>, handler=<optimized out>, mask=0, value=4125259424, address=<optimized out>) at ../../src/device/memory/memory.h:87
#8  r4300_write_aligned_word (r4300=0x7ffff1ff6200 <dynarec_write_aligned_word>, address=<optimized out>, value=4125259424, mask=0) at ../../src/device/r4300/r4300_core.c:353
#9  0x00007ffff5e274a0 in ?? () from /usr/lib64/libmupen64plus.so.2
#10 0x0000000000000000 in ?? ()

Issue when compiling

Got to what I assume is near the end of the compiling but I ran into error

mips64-elf-objcopy --pad-to=0xC00000 --gap-fill=0xFF build/us/mk64.us.elf build/us/mk64.us.bin -O binary
tools/n64cksum build/us/mk64.us.bin build/us/mk64.us.z64
build/us/mk64.us.z64: FAILED
sha1sum: WARNING: 1 computed checksum did NOT match
make: *** [Makefile:186: all] Error 1

I did have a issue with the checksum not matching with the original rom I downloaded, is this a similar issue with the second rom I downloaded?

Documentation

Track issues related to documentation here.

Every code file should have this sort of intro:

/**
  * @file file_name.c and what it does.
  */

Files ready for documentation

Easy

podium_ceremony_actors.c partially done

Medium

race_logic.c
staff_ghosts.c

Hard

memory.c
ceremony_and_credits.c

Others:

Everything not on this list

global.h

Global.h was added way back in the day with the purpose of cleaning of includes a bit.

This could be investigated and if it makes sense, apply it to the whole repo.

It's currently included in spawn_players.c

global.h contains includes for macros.h and ultra64.h sort of thing etc.

Or if chosen not to go this route, the file should be deleted.

Or perhaps it was more temporary solution and isn't needed anymore

Staff_ghosts.inc.c

This file should get renamed to something that clearly marks it as like a middle man file.

Sort of like staff_ghost_actions_container.inc.c

Segment offset macro misses

Missed a few macros:

staff_ghosts.c SEGMENT_OFFSET(D_80162DC4) atosPiStartDma

This needs SEGMENT_NUMBER and SEGMENT_OFFSET: (there's 2 of them)

VIRTUAL_TO_PHYSICAL2(gSegmentTable[arg0 >> 0x18] + (arg0 & 0xFFFFFF));

osPiStartDma(&gDmaIoMesg, 0, 0, (uintptr_t)&_other_texturesSegmentRomStart[((u32) devAddr) & 0xFFFFFF], address, size, &gDmaMesgQueue);

EUC-JP encoding

Apparently sm64 saves files as US. And the build system converts the necessary files to EUC-JP

Any reason that solution isn't relevant here?

progress.py and totalBadge will be inaccurate until this is solved.

Priority: 0