n64decomp / mk64 Goto Github PK
View Code? Open in Web Editor NEWA speedy Mario Kart 64 decompilation, brought to you by the cousin of a tame racing driver.
A speedy Mario Kart 64 decompilation, brought to you by the cousin of a tame racing driver.
Packed needs to be renamed to course_displaylists
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 ?? ()
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
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
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.
It's likely that most shift bugs are due to segments colliding with each other. The below should be entirely outdated.
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.
Tried a script from zeldaret. Didn't comprehend how it worked.
Windows line endings result in unknown character warnings.
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
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.
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.
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 |
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 |
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 |
Function | Decompme | Comments |
---|---|---|
func_800AFC54 | https://decomp.me/scratch/ldkgz | diffs |
func_800B0004 | https://decomp.me/scratch/TbO9o | Really dumb register allocation diff |
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 |
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 |
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 | Matched :) !!!NEEDS A PR!!! |
func_80099394 | https://decomp.me/scratch/UcyZ2 | Matched :) !!!NEEDS A PR!!! |
func_8009952C | https://decomp.me/scratch/Wv2MX | Matched :) !!!NEEDS A PR!!! |
func_800996BC | https://decomp.me/scratch/hwAAp | Matched :) !!!NEEDS A PR!!! |
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.
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). |
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 |
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 |
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 |
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);
Rename this file to like audiobanks.us.bin or something.
would it be possible to port this to wasm through emscripten or other?
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?
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;
}
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
Many of the functions have incorrect types and wrong argument count
Trackwaypoints?
Pathwaypoints?
Just waypoints or path?
CoursePath
CourseWaypoints
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".
Track issues related to documentation here.
Every code file should have this sort of intro:
/**
* @file file_name.c and what it does.
*/
partially done
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
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.
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
Line 3150 in 850e3b2
Going back to what it was makes it build.
When generate doxygen documentation not all file and function appears
Enhancements that might be fun. Shouldn't be anything too big here.
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.
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
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.
Feel free to help with this.
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.GotoMenuFromQuit
--> GotoMenu
or similar.framebuffers.c
and
gfx_output_buffer.c
Should go in a buffers folder just like sm64.
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
see title
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)
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
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.
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
data/other_textures.s: Assembler messages:
data/other_textures.s:1423: Warning: end of file not at end of a line; newline inserted
Environment:
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
We want splat.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.