Super Mario 64 has been decompiled

[mountainflaw]

Will this make 60 fps version possible?

On console it's theoretical. The RDP is too stressed (even at 30 FPS in some points) for a consistent 60 FPS. There's an F3DEX2 microcode build option which I added in (GRUCODE=f3dex2 when running make), and even that doesn't improve the framerate. I guess one could try enabling fog and increasing clipping and see how that works, along with removing anti-aliasing.

 

[NightScript]

"Every single function was rewritten by hand" What does this mean, because technically this would mean probably some conversions were off.

It makes identical copies of the first NTSC-J and NTSC-U releases of the game.

 

[Ericthegreat]

Seems it's not 100% the code, like some spots were filled in by hand, and most give you he same result, but they might not be 100% the way Nintendo did it.

I do not know this, but this is my guess.

 

[mountainflaw]

Seems it's not 100% the code, like some spots were filled in by hand, and most give you he same result, but they might not be 100% the way Nintendo did it.

I do not know this, but this is my guess.

Of course, but there's not really much better we could do.

 

[Ericthegreat]

Of course, but there's not really much better we could do.

I understand, it's not that this is a bad thing, it's just some people seem to think it's literally 100% the source code from Nintendo.

 

[alivebacon]

I thought SuperSponge was the open source game.

 

[Deleted User]

It begins.

 

[CrashOveride]

I thought SuperSponge was the open source game.

While all dev assets were bought and uploaded to archive.org, the source code technically is not "open source" as it's a legal grey area due to not being "licensed" by the original developers

 

[TheGamingLord]

Hello, I'm having a bit of trouble compiling this.

This is the output:
"qemu-irix -silent -L tools/ido5.3_compiler tools/ido5.3_compiler/usr/bin/cc -c -Wab,-r4300_mul -non_shared -G 0 -Xcpluscomm -Xfullwarn -g -signed -I include -I build/us/include -I src -D_LANGUAGE_C -DVERSION_US=1 -mips2 -32 -DF3D_OLD -o build/us/src/engine/surface_collision.o src/engine/surface_collision.c
/usr/lib/libc.so.1: No such file or directory
Makefile:399: recipe for target 'build/us/src/engine/surface_collision.o' failed
make: *** [build/us/src/engine/surface_collision.o] Error 255"

It would be appreciated if someone could help.

 

[smf]

Seems it's not 100% the code, like some spots were filled in by hand, and most give you he same result, but they might not be 100% the way Nintendo did it.

I do not know this, but this is my guess.

Sure, you can't know whether Nintendo wrote

int i; for (i = 0; i < 10; i++)
{
...
}

or

int i = 0;
while (i < 10)
{
....
i++;
}

For what it is worth though you can convert plain old assembly games to other things too, it just takes hundreds of times longer so nobody really bothers when ROM hacking and emulators are a thing.

It depends on how similar the platforms are & how the code is structured. For example lots of games were converted between colecovision and MSX. They have the same CPU so converting back to source code is actually an unnecessary overhead.

We'd have to start with writing an OpenGL backend for the gSP API, gDP API, and the gu API. We would also have to write our own implementation of the os API and make a wrapper to SDL or SDL-equivalent for cross-platform audio and input.

The beneft of a wrapper is that you can reuse it on the next project, going through well defined calls also means you are less likely to make a mistake that kills the project. The alternative is going in and hacking the original code to call native functions, which can be worthwhile for performance and extending beyond the original limitations, but you could find half way through and find that all your changes are wrong & it becomes a nightmare to fix it all.

 

[CrashOveride]

Hello, I'm having a bit of trouble compiling this.

This is the output:
"qemu-irix -silent -L tools/ido5.3_compiler tools/ido5.3_compiler/usr/bin/cc -c -Wab,-r4300_mul -non_shared -G 0 -Xcpluscomm -Xfullwarn -g -signed -I include -I build/us/include -I src -D_LANGUAGE_C -DVERSION_US=1 -mips2 -32 -DF3D_OLD -o build/us/src/engine/surface_collision.o src/engine/surface_collision.c
/usr/lib/libc.so.1: No such file or directory
Makefile:399: recipe for target 'build/us/src/engine/surface_collision.o' failed
make: *** [build/us/src/engine/surface_collision.o] Error 255"

It would be appreciated if someone could help.

You read install.md right?

 

[TheGamingLord]

Yes, I have.

 

[mountainflaw]

Sure, you can't know whether Nintendo wrote

int i; for (i = 0; i < 10; i++)
{
...
}

or

int i = 0;
while (i < 10)
{
....
i++;
}



It depends on how similar the platforms are & how the code is structured. For example lots of games were converted between colecovision and MSX. They have the same CPU so converting back to source code is actually an unnecessary overhead.



The beneft of a wrapper is that you can reuse it on the next project, going through well defined calls also means you are less likely to make a mistake that kills the project. The alternative is going in and hacking the original code to call native functions, which can be worthwhile for performance and extending beyond the original limitations, but you could find half way through and find that all your changes are wrong & it becomes a nightmare to fix it all.

Actually, we can in that instance. The outputted assembly is different.

 

[smf]

Actually, we can in that instance. The outputted assembly is different.

Ok, the compiler must be incredibly bad. I guess I'm used to modern compilers, which have had two decades of improvements.

What things can't you tell?

 

[TheGag96]

Is there anyone that could help @BridgetX, @TheGamingLord, and I out? People have clearly gotten this to compile, but all 3 of us are unable to and get the same error message. @MurraySkull, maybe you'd be able to lend us a hand? Thanks.

 

[funkyzaps]

As the source was released in a .zip file and not a .tar.gz or similar, some files that need to be executable aren't.
Easy way to get it to compile is a

chmod -R +x tools/ido5.3_compiler/

Edit: Oh, my error was slightly different than the one regarding libc. No idea what's wrong there.

 

[TheGamingLord]

I've tried to compile it through Virtualbox and WSL, but I still get the same error.

 

[TheGag96]

As the source was released in a .zip file and not a .tar.gz or similar, some files that need to be executable aren't.
Easy way to get it to compile is a

chmod -R +x tools/ido5.3_compiler/

Edit: Oh, my error was slightly different than the one regarding libc. No idea what's wrong there.

Oh wow, that actually somehow worked! I got plenty of the same error I was getting before, but I guess they were warnings all along, as they just got ignored... The game compiled just fine after that. Thank you!!

 

[TheGamingLord]

Still not working for me. I'm extremely confused about why it's not working. Where am I even supposed to get libc.so.1 from?

 

[Ecchi95]

I'm using the decompilation, a hex editor, and LemASM to search for and identify where the .o (compiled C) files are in the Japanese ROM and make a ROM map. I'll put the map in my opening post when I've identified everything in the decompilation.