# Super Mario 64 has been decompiled



## Ecchi95 (Jul 7, 2019)

*For help navigating the files: https://gbatemp.net/threads/super-mario-64-has-been-decompiled.542918/page-7#post-8712520*

*Follow the social media campaign:

BBoard*
[Discussion]

*Beyond3D*
[Discussion]

*Exclusively Games*
[Discussion]

*Gaming Reinvented*
[Article] [Discussion]

*Hacker News*
[Discussion]

*OCAU*
[Discussion]

*Official Pyra and Pandora Site*
[Discussion]

*Reddit
/r/gamedev*
[1]

*/r/n64*
[1]

*/r/emulation*
[1]

*/r/linux_gaming*
[1]

*/r/programming*
[1]

*/r/DataHoarder*
[1]

*/r/Games*
[1]

*/r/nintendo*
[1][2]

*/r/speedrun*
[1]

*/r/REGames*
[1]

*/r/coding*
[1]

*/r/retrogaming*
[1]

*ResetEra*
[Discussion]

*Twitter*
[1][2]

Hi. I registered because nobody else was talking about this.

If you *do a google search for "n64 decomp" in quotes*, you'll get a warosu.org result (archived 4chan threads.) This thread contains a link to a full decompilation of Super Mario 64 that an IDENTICAL ROM can be built from if you have the proper environment setup. It seems it was leaked before the people involved finished renaming all the functions to be nice and clear.

It's not an ordinary decompilation generated by IDA. They actually rewrote all the functions from reading MIPS assembly and compiled it with the original compiler, adjusting the code until it produced identical output to a vanilla ROM.

*These are the files contained in the src/game directory:
(src is split into audio, engine, game, and goddard)*

```
area.c
area.h
camera.c
camera.h
debug.c
debug.h
debug_course.c
debug_course.h
decompress.h
display.c
display.h
envfx_bubbles.c
envfx_bubbles.h
envfx_snow.c
envfx_snow.h
file_select.c
file_select.h
game.c
game.h
geo_misc.c
geo_misc.h
hud.c
hud.h
ingame_menu.c
ingame_menu.h
interaction.c
interaction.h
intro_geo.c
intro_geo.h
level_geo.c
level_geo.h
level_select_menu.c
level_select_menu.h
level_update.c
level_update.h
macro_special_objects.c
macro_special_objects.h
main.c
main.h
main_entry.h
mario.c
mario.h
mario_actions_airborne.c
mario_actions_airborne.h
mario_actions_automatic.c
mario_actions_automatic.h
mario_actions_cutscene.c
mario_actions_cutscene.h
mario_actions_moving.c
mario_actions_moving.h
mario_actions_object.c
mario_actions_object.h
mario_actions_stationary.c
mario_actions_stationary.h
mario_actions_submerged.c
mario_actions_submerged.h
mario_misc.c
mario_misc.h
mario_step.c
mario_step.h
memory.c
memory.h
moving_texture.c
moving_texture.h
object_collision.c
object_collision.h
object_helpers.c
object_helpers.h
object_helpers2.h
object_list_processor.c
object_list_processor.h
obj_behaviors.c
obj_behaviors.h
obj_behaviors_2.c
obj_behaviors_2.h
paintings.c
platform_displacement.c
platform_displacement.h
print.c
print.h
profiler.c
profiler.h
rendering_graph_node.c
rendering_graph_node.h
room.c
room.h
save_file.c
save_file.h
screen_transition.c
screen_transition.h
segment2.h
segment7.h
shadow.c
shadow.h
skybox.c
skybox.h
sound_init.c
sound_init.h
spawn_object.c
spawn_object.h
spawn_sound.c
spawn_sound.h
star_select.c
star_select.h
```


----------



## 8BitWonder (Jul 7, 2019)

Grabbed from the same thread:



> Revo Sat Jun 8 00:01:57 2019 No.>>5644126 >>5644132 >>5644139 >>5644190 >>5644736 >>5646686 >>5649483 >>5652952 >>5654821
> 
> Ah.. fuck. Which doofus leaked it I will smegging fucking KILL THEM.
> 
> ...



So while yes it seems to be the real deal and compile-able, It's not actually finished.


----------



## pasc (Jul 7, 2019)

How the heck did they do that ?


----------



## Ecchi95 (Jul 7, 2019)

8BitWonder said:


> It's not actually finished.


Revo also said this:
"Don't misread me. 65% just means the renamed stuff from raw variable names like func_80F00F00. and D_80F00F00. You can compile it in its current state and it will produce a working Super Mario 64 ROM."

Like I said, the only thing not finished is renaming every function.


----------



## 8BitWonder (Jul 7, 2019)

Ecchi95 said:


> Revo also said this:
> "Don't misread me. 65% just means the renamed stuff from raw variable names like func_80F00F00. and D_80F00F00. You can compile it in its current state and it will produce a working Super Mario 64 ROM."
> 
> Like I said, the only thing not finished is renaming every function.


Whoops, must've missed that one.
My bad.


----------



## Ecchi95 (Jul 7, 2019)

pasc said:


> How the heck did they do that ?


As I said:



Ecchi95 said:


> It's not an ordinary decompilation generated by IDA. They actually rewrote all the functions from reading MIPS assembly and compiled it with the original compiler, adjusting the code until it produced identical output to a vanilla ROM.


----------



## lincruste (Jul 7, 2019)

Couldn't find a single download link for this.


----------



## uyjulian (Jul 7, 2019)

lincruste said:


> Couldn't find a single download link for this.





Ecchi95 said:


> If you do a *google search for "n64 decomp" in quotes*, you'll get a warosu.org result (archived 4chan threads.)


----------



## Ecchi95 (Jul 7, 2019)

lincruste said:


> Couldn't find a single download link for this.


It's at the top of the thread on warosu.org. The anonfile link.

I've been looking at it. That's how I made the file list from one of the src directories.


----------



## FAST6191 (Jul 7, 2019)

Interesting development. Wonder if the speedrun folks will have any discoveries as a result of this.

Personally I would have been content with something that could compile (and was not just kicking lots as a straight binary array to be left as is) similar to some of the disassembles we have seen on older consoles but if people want to gild the lily then "you do you" and all that.


----------



## Ecchi95 (Jul 7, 2019)

And yes, it uses the official SDK.

Apparently Kaze Emanuar and Pannenkoek2012 are just two of the people who made this a reality.


----------



## lincruste (Jul 7, 2019)

Ecchi95 said:


> It's at the top of the thread on warosu.org. The anonfile link.


Found. Thank you.


----------



## orangy57 (Jul 7, 2019)

So is this basically like how that one guy rewrote Diablo from scratch using only instruction names?


----------



## Concas_ (Jul 7, 2019)

May this lead to a homebrew source port of the game?


----------



## FAST6191 (Jul 7, 2019)

Orangy57 said:


> So is this basically like how that one guy rewrote Diablo from scratch using only instruction names?


For the others playing along at home that missed that one 


Anyway sort of yes, but also not yes (function names are nice to have but it is not a keys to the kingdom affair) and there were some different goals (don't know entirely why they went in for 1:1 binary recreation as opposed to functional/bug for bug equivalent but to each their own). Decompilation itself is also advancing somewhat quickly as far as C family, especially C is concerned.
The end result though is/will be something you can port to different things much as you would any other C program. Depending upon what was done to play to the N64 hardware there might be an optimised build that spares us the problems dodged by clever coding or that takes advantage of more modern hardware, and beyond that someone might also come along and do a DS functions mod (and probably another to allow certain speedruns to work in lesser emulators that might play differently in some manner).


----------



## Ecchi95 (Jul 7, 2019)

FAST6191 said:


> (don't know entirely why they went in for 1:1 binary recreation as opposed to functional/bug for bug equivalent but to each their own).


Nintendo didn't use any compiler optimizations, so it was "easy."



Concas_ said:


> May this lead to a homebrew source port of the game?


Yeah, you can port it to anything. A PC port, even rival consoles! You just have to get rid of the Nintendo 64 API calls.

You can even write Ocarina of Time the way Nintendo did, starting with Super Mario 64's engine.


----------



## Ecchi95 (Jul 8, 2019)

Is anyone going to talk about the contents besides me? This is the entire code of Super Mario 64 we have here.

I want to see people analyzing it.


----------



## uyjulian (Jul 8, 2019)

Ecchi95 said:


> Is anyone going to talk about the contents besides me? This is the entire code of Super Mario 64 we have here.
> 
> I want to see people analyzing it.


I don't think that much people are interested in incomplete work.


----------



## Ecchi95 (Jul 8, 2019)

uyjulian said:


> I don't think that much people are interested in incomplete work.


The code is complete, just not every symbol has been given a proper name. I told you, this wasn't a generated output. Every single function was rewritten by hand. It's proper code.

Here is all of geo_misc.c:


```
#include <ultra64.h>

#include "sm64.h"
#include "geo_misc.h"

#include "area.h"
#include "engine/math_util.h"
#include "level_update.h"
#include "mario_actions_cutscene.h"
#include "mario.h"
#include "memory.h"
#include "rendering_graph_node.h"
#include "save_file.h"
#include "segment2.h"

/**
 * @file geo_misc.c
 * This file contains miscellaneous geo_asm scripts. 
 * 
 * In particular, it builds:
 *   - the light that shows the player where to look for Tower of the Wing Cap, 
 *   - the flying carpets seen in Rainbow Ride, and 
 *   - the end screen displaying Peach's delicious cake.
 */

#define NUM_FLYING_CARPET_VERTICES 21
extern s16 flying_carpet_static_vertex_data[NUM_FLYING_CARPET_VERTICES];

extern Gfx dl_castle_lobby_wing_cap_light[];

extern Gfx dl_flying_carpet_begin[];
extern Gfx dl_flying_carpet_model_half[];
extern Gfx dl_flying_carpet_end[];

extern Gfx dl_cake_end_screen[];

static s16 sCurAreaTimer = 1;
static s16 sPrevAreaTimer = 0; 
static s16 sFlyingCarpetRippleTimer = 0;

s8 gFlyingCarpetState;

/**
 * Create a vertex with the given parameters and insert it into `vtx` at 
 * position `n`.
 */
void make_vertex(
    Vtx *vtx, s32 n, s16 x, s16 y, s16 z, s16 tx, s16 ty, u8 r, u8 g, u8 b, u8 a
) {
    vtx[n].v.ob[0] = x;
    vtx[n].v.ob[1] = y;
    vtx[n].v.ob[2] = z;

    vtx[n].v.flag = 0;

    vtx[n].v.tc[0] = tx;
    vtx[n].v.tc[1] = ty;

    vtx[n].v.cn[0] = r;
    vtx[n].v.cn[1] = g;
    vtx[n].v.cn[2] = b;
    vtx[n].v.cn[3] = a;
}

/**
 * Round `num` to the nearest `s16`.
 */
s16 round_float(f32 num) {
    // Note that double literals are used here, rather than float literals.
    if (num >= 0.0) {
        return num + 0.5;
    } else {
        return num - 0.5;
    }
}

/**
 * Create a display list for the light in the castle lobby that shows the
 * player where to look to enter Tower of the Wing Cap.
 */
Gfx *geo_exec_inside_castle_light(
    s32 run, 
    struct GraphNode *node, 
    UNUSED f32 mtx[4][4]
) {
    s32 flags;
    struct GraphNode12A *generatedNode;
    Gfx *displayListHead = NULL;
    Gfx *displayList = NULL;

    if (run == TRUE)
    {
        flags = save_file_get_flags();
        if (gDisplayedStars >= 10 && (flags & SAVE_FLAG_HAVE_WING_CAP) == 0)
        {
            displayList = alloc_display_list(2 * sizeof(*displayList));
           
            if (displayList == NULL) {
                return NULL;
            } else {
                displayListHead = displayList;
            }

            generatedNode = (struct GraphNode12A *) node;
            generatedNode->fnNode.node.flags = (
                generatedNode->fnNode.node.flags & 0xFF
            ) | 0x500;
           
            gSPDisplayList(displayListHead++, dl_castle_lobby_wing_cap_light);
            gSPEndDisplayList(displayListHead);
        }
    }

    return displayList;
}

/**
 * Update static timer variables that control the flying carpets' ripple effect.
 */
Gfx *geo_exec_flying_carpet_timer_update(
    s32 run, 
    UNUSED struct GraphNode *node, 
    UNUSED f32 mtx[4][4]
) {
    if (run != TRUE) {
        sFlyingCarpetRippleTimer = 0;
        sPrevAreaTimer = gAreaUpdateCounter - 1;
        sCurAreaTimer = gAreaUpdateCounter;
        gFlyingCarpetState = FLYING_CARPET_IDLE;
    } else {
        sPrevAreaTimer = sCurAreaTimer;
        sCurAreaTimer = gAreaUpdateCounter;
        if (sPrevAreaTimer != sCurAreaTimer) {
            sFlyingCarpetRippleTimer += 0x400;
        }
    }

    return NULL;
}

/**
 * Create a display list for a flying carpet with dynamic ripples.
 */
Gfx *geo_exec_flying_carpet_create(
    s32 run, 
    struct GraphNode *node, 
    UNUSED f32 mtx[4][4]
) {
    s16 n, row, col, x, y, z, tx, ty;
    Vtx *verts;
    struct GraphNode12A *generatedNode = (struct GraphNode12A *) node;

    s16 *sp64 = segmented_to_virtual(&flying_carpet_static_vertex_data);
    Gfx *displayList = NULL;
    Gfx *displayListHead = NULL;
    struct Object *curGraphNodeObject;
   

    if (run == TRUE)
    {
        verts = alloc_display_list(NUM_FLYING_CARPET_VERTICES * sizeof(*verts));
        displayList = alloc_display_list(7 * sizeof(*displayList));
        displayListHead = displayList;

        if (verts == NULL || displayList == NULL) {
            return NULL;
        }

        generatedNode->fnNode.node.flags = (
            generatedNode->fnNode.node.flags & 0xFF
        ) | 0x100;

        for (n = 0; n <= 20; n++)
        {
            row = n / 3;
            col = n % 3;

            x = sp64[n * 4 + 0];
            y = round_float(
                sins(
                    sFlyingCarpetRippleTimer + (row << 12) + (col << 14)
                ) * 20.0
            );
            z = sp64[n * 4 + 1];
            tx = sp64[n * 4 + 2];
            ty = sp64[n * 4 + 3];

            make_vertex(verts, n, x, y, z, tx, ty, 0, 127, 0, 255);
        }

        gSPDisplayList(displayListHead++, dl_flying_carpet_begin);

        // The forward half.
        gSPVertex(displayListHead++, verts, 12, 0);
        gSPDisplayList(displayListHead++, dl_flying_carpet_model_half);

        // The back half.
        gSPVertex(displayListHead++, verts + 9, 12, 0);
        gSPDisplayList(displayListHead++, dl_flying_carpet_model_half);

        gSPDisplayList(displayListHead++, dl_flying_carpet_end);
        gSPEndDisplayList(displayListHead);

        curGraphNodeObject = (struct Object *) D_8032CFA0;
        if (gMarioObject->platform == curGraphNodeObject) {
            gFlyingCarpetState = FLYING_CARPET_MOVING_WITH_MARIO;
        } else if (curGraphNodeObject->oForwardVel != 0.0) {
            gFlyingCarpetState = FLYING_CARPET_MOVING_WITHOUT_MARIO;
        } else {
            gFlyingCarpetState = FLYING_CARPET_IDLE;
        }
       
    }

    return displayList; 
}

/**
 * Create a display list for the end screen with Peach's delicious cake.
 */
Gfx *geo_exec_cake_end_screen(
    s32 run,
    struct GraphNode *node,
    UNUSED f32 mtx[4][4]
) {
    struct GraphNode12A *generatedNode = (struct GraphNode12A *) node;
    Gfx *displayList = NULL;
    Gfx *displayListHead = NULL;

    if (run == TRUE)
    {
        displayList = alloc_display_list(3 * sizeof(*displayList));
        displayListHead = displayList;

        generatedNode->fnNode.node.flags = (
            generatedNode->fnNode.node.flags & 0xFF
        ) | 0x100;

        gSPDisplayList(displayListHead++, dl_proj_mtx_fullscreen);
        gSPDisplayList(displayListHead++, dl_cake_end_screen);
        gSPEndDisplayList(displayListHead);
    }

    return displayList;
}
```


----------



## uyjulian (Jul 8, 2019)

Ecchi95 said:


> The code is complete, *just not every symbol has been given a proper name*. I told you, this wasn't a generated output. Every single function was rewritten by hand. It's proper code.



It's still *incomplete work*.


----------



## Ecchi95 (Jul 8, 2019)

uyjulian said:


> It's still *incomplete work*.




_*It builds a 100% identical ROM of the game.*_


```
# Super Mario 64

This is a decompilation of Super Mario 64.

It builds the following rom(s):

* sm64.j.z64 `sha1: 8a20a5c83d6ceb0f0506cfc9fa20d8f438cafe51`
* sm64.u.z64 `sha1: 9bef1128717f958171a4afac3ed78ee2bb4e86ce`

To set up the repository, see [INSTALL.md](INSTALL.md).
```

Don't be lazy. Everything that has been given a name is more than enough to make use of it, even porting it to other systems or PC.


----------



## FAST6191 (Jul 8, 2019)

Ecchi95 said:


> Is anyone going to talk about the contents besides me? This is the entire code of Super Mario 64 we have here.
> 
> I want to see people analyzing it.


To what end? 

We have long seen some fairly ridiculous analysis of its mechanics done

For others playing along at home




What the source code will provide us as far as analysis goes I am not sure. I imagine most around here are of the "wake me up when we have a new port of it (better yet a nice HD port), the DS remake features are backported/recreated, there is an interesting mod made with it (while ROM hacking can achieve anything the hardware can do there are certain types of mods that only tend to get seen when source code in involved), we have a fixed up version, it gets adaptation to run one of Rare's efforts...." persuasion. If you are expecting people around here to be going over the code like it is an obfuscation contest and we are trying to tease out secrets then it is probably not going to happen for Mario 64, partially because it is so old and outclassed and partially because it is already pretty well understood -- if the mechanics are already known (and I did see a version of it compare virtual console and n64 hardware flaws in float processing for some kind of wall clip I think it was so I am guessing that speaks to much) then most of it is less source code fun and more use said mechanics to analyse points on the level data which is a different matter really.

That said if you have been looking at the contents, or following the results of those that are, what files are we looking at and what interesting things that might not have been as apparent before have been found as a result?


----------



## Ecchi95 (Jul 8, 2019)

FAST6191 said:


> To what end?
> 
> We have long seen some fairly ridiculous analysis of its mechanics done
> 
> ...


It's the entire code for the finished commercial game. You can reference it for making your own 3D games. You can port it to other platforms.

People should be doing things with it right now.


----------



## FAST6191 (Jul 8, 2019)

Ecchi95 said:


> It's the entire code for the finished commercial game. You can reference it for making your own 3D games. You can port it to other platforms.
> 
> People should be doing things with it right now.


I got that. However we have far newer 3d engines available for free, and under even better licenses and nicer to work with code (this is first pass attempt at embedded C doing early stage 3d... it is not pretty code you can't help but play with, and with all the limitations discussed in the videos above, as well as related ones, it is not a stellar engine either). Ports are nice but not what many around here spend their time doing* -- you would do far better showcasing hacks, mods, fixes and tweaks, or cool speedrun type things.

*to say nothing of again it being early stage 3d with people doing embedded C that might not normally have used it on, on new hardware and attempting to show off a bit in the process. I imagine it is pretty far from anything I can compile with either one of the homebrew/ROM hacker compilers/assemblers or a common modern C compiler for the PC. A few months from now I imagine there will be a version more amenable to modern compilers but that is a few months from now. If I have to go through the utter ball ache of finding and installing a vintage compiler for the N64 (is it the sort of thing that installs fine on an otherwise vanilla X64 version of Windows 10 or is this a Windows 95 VM job?) I am going to need something to justify it.

Examples of things that might be nice or might catch someone around here's attention.
Most of us probably play N64 games on emulators and don't use one of the N64 pads to do it. Do you have a line on what we need to look at to create version with nicely remapped controls? Or maybe even some kind of macro or extra controls? (take hat off, easy triple jump for those that might not be able to play it otherwise, change some things from gesture control to something else). I don't much care for speedruns but others do so maybe a speed buildup option that does not take untold hours.
The camera, as with most early 3d games, sucks. Do you have some idea where the code might be so we can fine tune some variables to get it to behave better (perhaps more like the Rare efforts from later in the N64 life).
Hard mode is fun. Perhaps a line on what we might need to do to stop the water regen health thing (from a practical perspective then we could probably find what flag the ice world water uses but if I am looking at code), or maybe a no coin life refill mode, double damage perhaps, double enemy boss health.
We could probably level hack a way to a boss rush but a code approach also works. What might we care to look at as part of such a thing?
While there are some codes to show some debug information where is it so we can contemplate adding some more?
From a ROM hacker perspective then music modification is annoying. What have you got here that might allow volume tweaks or mods. Or on the flip side is it likely to be something nice to look at (ignoring licensing concerns for a moment) for a PC side music player for it?
Some kind of challenge mode as well similar to the endless enemies? Could we start on that? Do we have enemy spawn options or would we have to create such a thing, and possibly sort the 255 coins bug while we are at it?
This stuff

is bloody hilarious. Do you reckon we could find a way to also make homing mushrooms poison mushrooms (possibly even wipe health down to all but 1 as well as losing a life from the life counter)?


----------



## Dartz150 (Jul 8, 2019)

Nice, I wish I could have spare time to invest it to make a 3DS port with all the new mechanics introduced in the DS version, I have ideas that could make it completely possible.

For me that is the only port worth the time besides an HD port, because you know, you can have the DS version with proper analog direction control and... motherfucking 3D.

Now thinking of it makes me exited for something like it, I will see if I can give it a shot and start the snowball to roll, maybe many others want to join and help.


----------



## Ryccardo (Jul 8, 2019)

FAST6191 said:


> What the source code will provide us as far as analysis goes I am not sure. [...] If you are expecting people around here to be going over the code like it is an obfuscation contest and we are trying to tease out secrets then it is probably not going to happen for Mario 64, partially because it is so old and outclassed and partially because it is already pretty well understood [...]


I personally wouldn't say that so quickly - while correlation may not be causation, the Pokemon Red disassembly (started in 2010 but peaking in 2012-2015) enjoyed a symbiotic relationship with a respectable number of new discoveries some of them rather significant, as well as  making heads or tails of things that were known to exist but not really understood; and while for every Pannenkoek and Pannenkeok there may be four reputable youtubers making solid edutainment videos about obscure Pokemon mechanics, it's never a bad thing to allow more people to independently verify and understand something - or to give them a better chance at changing that game rule they don't like


----------



## FAST6191 (Jul 8, 2019)

Ryccardo said:


> I personally wouldn't say that so quickly - while correlation may not be causation, the Pokemon Red disassembly (started in 2010 but peaking in 2012-2015) enjoyed a symbiotic relationship with a respectable number of new discoveries some of them rather significant, as well as  making heads or tails of things that were known to exist but not really understood; and while for every Pannenkoek and Pannenkeok there may be four reputable youtubers making solid edutainment videos about obscure Pokemon mechanics, it's never a bad thing to allow more people to independently verify and understand something - or to give them a better chance at changing that game rule they don't like


Is the arbitrary execution a particularly significant thing? That would be about the height of ROP (or at least in its meteoric rise) and there was a bit of a fad for making exploits in random old things/games at that point in the world at large.

Granted most of my knowledge of pokemon glitches like that is more from a history of pokemon speedrunning video I once watched, and many of those still seemed accidental, so I will take your word on that one. That said the line quoted is more a response to the OP almost chastising us for not all having a copy and poking around it like it was some amazing bombshell dropped upon the world, or perhaps like those times when the ability to unpack ROMs or unpack tweaked new ROMs becomes a thing. I am always happy to see this sort of thing appear/be generated, and I imagine most around here would react positively to such developments, but as far as waves of excitement then what this will give us that ROM hacking has not/will not, and what would be better served starting from scratch/porting assets, is a different matter.


----------



## Ryccardo (Jul 8, 2019)

FAST6191 said:


> Is the arbitrary execution a particularly significant thing?


Well, it certainly became a symbol of "the new age of research" - the one based more on trying to understand the code, rather than just trying to understand observations! (Obviously it hasn't been an overnight change, and it existed to some degree beforehand, but you get the idea) 

The knowledge that certain items (like the mentioned ones) did something weird depending on current state was long known, but few practical applications or technical details were understood 10 years ago compared to today - even more importantly in my opinion, plenty of smaller things that are documented in some form can also be better understood with access to the technical reference (like the vertical-stripe crash? opcode FF infinite loop; Missingno crashing Yellow and corrupting the hall of fame in Red/Blue? non-picture data being interpreted as an oversized compressed bitmap, and it happens that the first bank of SRAM is used as general memory expansion followed by the hall of fame; ...)

Even the non-abnormal parts benefit from it - it used to be believed that having glitch items named as badges, floor numbers, or Safari Zone rock/bait were coincidences caused by accidentally meaningful undefined string pointers, but it turned out a deliberate attempt to recycle existing item menu code (oh, I said "non-abnormal"? never mind, it's Game Freak, the same company which multiple times has failed writing simple math functions)


----------



## FAST6191 (Jul 9, 2019)

I would be careful reading too much into pokemon as a state of the world at large there. If doing the whole ROM hacking thing then pokemon sits rather aside from the rest of the ROM hacking world. On the one hand there are loads of tools that allow things to be edited from top to bottom (ones that maybe only 5 other non PC/non open source games have anything close to), and I also see many new hackers learning the rudiments of assembly, but at the same time the level of understanding of concepts at large is lower than most general forms of ROM hacking. Of the things you mentioned there as examples I reckon I could find something as far back as the Amiga and possibly commodore64 covering those, certainly in general ROM hacking of many many years back -- go have a look at something like the feature history of fceux (things like function mapping/discovery*, all the Lua stuff, the serious big boy debugging stuff) or the no$ series of debug emulators and realise most of those were in response to requests or common (at least on the PC) debug options rather than a particularly ambitious dev cooking up new things for people to use.

*I forget the name of it offhand but it works sort of like a cheat search where you do everything you want in the game but the thing you want, and then once all that is done you do the thing you want to look at and it will say these new functions were called.

As far as pokemon itself is concerned then I saw some fairly advanced stuff done to finally dispel the up and b myth, and while things had not quite reached the levels of https://www.dragonflycave.com/mechanics/gen-i-capturing then they were not especially lacking.

On the flip side some might say all I wrote above is irrelevant and the pokemon disassembly did lead to advancements in code so...

On a different note entirely then for those not used to such things then I highly encourage you to have a scan through stuff discussing the princess maker source code (DS game accidentally left source in it), https://gbatemp.net/threads/japanese-programming-madness.320192/ , https://www.pagetable.com/?p=28 and that diablo link from earlier. Disassembly is subtly different to much of that, and getting this sort of result is more of a modern phenomenon for C family stuff (C#, visual basic and java not so much), but at the same time is not so far removed.


----------



## Ecchi95 (Jul 9, 2019)

Dartz150 said:


> Nice, I wish I could have spare time to invest it to make a 3DS port with all the new mechanics introduced in the DS version, I have ideas that could make it completely possible.
> 
> For me that is the only port worth the time besides an HD port, because you know, you can have the DS version with proper analog direction control and... motherfucking 3D.
> 
> Now thinking of it makes me exited for something like it, I will see if I can give it a shot and start the snowball to roll, maybe many others want to join and help.


You should start a thread in 3DS - Homebrew Development and Emulators! I can help with understanding code, but not with 3DS testing.


----------



## nim-ka (Jul 11, 2019)

People *are* analyzing SM64 through this. People *are* doing things with this. The SM64 Randomizer is one great example, not to mention all the glitches found with it. Just because you can't see it doesn't mean it doesn't exist


----------



## Ecchi95 (Jul 11, 2019)

nim-ka said:


> People *are* analyzing SM64 through this. People *are* doing things with this. The SM64 Randomizer is one great example, not to mention all the glitches found with it. Just because you can't see it doesn't mean it doesn't exist


The Randomizer author is one of the people who was already privy to it before it leaked.

I'm talking about the "common people" looking at it, and in public.


----------



## nim-ka (Jul 11, 2019)

The people who are really interested in it have already seeked out the community. Why not just be patient and wait until the full release, which will come with things like simple level editing, a fully documented codebase, etc.


----------



## FAST6191 (Jul 11, 2019)

nim-ka said:


> The people who are really interested in it have already seeked out the community. Why not just be patient and wait until the full release, which will come with things like simple level editing, a fully documented codebase, etc.


I don't necessarily disagree (I am certainly expecting the bulk of anything here to come from said really interested crowd) but across this console hacking, emulator writing and ROM hacking lark we have had a few examples of random people of enough baseline skills rock up to niche things before and drop something interesting. As baseline skills here with this have changed from needs obscure MIPS family CPU assembly skills to "solid C coding skills" (a far more common skillset), maybe with a "saw/played/enjoyed Mario 64 back in the day", then I can see spreading it a bit further than those that might naturally seek it out.


----------



## Kwyjor (Jul 11, 2019)

nim-ka said:


> People *are* analyzing SM64 through this. People *are* doing things with this. The SM64 Randomizer is one great example, not to mention all the glitches found with it. Just because you can't see it doesn't mean it doesn't exist


A lot of that was done long before this source code was released.


----------



## nim-ka (Jul 11, 2019)

FAST6191 said:


> As baseline skills here with this have changed from needs obscure MIPS family CPU assembly skills to "solid C coding skills" (a far more common skillset), maybe with a "saw/played/enjoyed Mario 64 back in the day", then I can see spreading it a bit further than those that might naturally seek it out.


It's really a lot more complicated to use this than it looks. The old version that was leaked isn't very well suited to modding



Kwyjor said:


> A lot of that was done long before this source code was released.


1- my message was in the present tense, not the past
2- all the top SM64 analysts have been using this code for about a year now


----------



## FAST6191 (Jul 11, 2019)

nim-ka said:


> It's really a lot more complicated to use this than it looks. The old version that was leaked isn't very well suited to modding



I am not a great C coder but I did have a quick shuffle through the files. Clearly 90s era embedded device C but no outrageous spaghetti, nothing much in the way of obfuscation, functions and variables named reasonably well for a lot of things, some comments where things are maybe not the clearest,... all things that source releases and the other things that led to the contents of https://osgameclones.com/ have happily handled, or handled worse than, in the past. I would say more or less anybody that will be able to handle it in a few months will be able to make good headway with things now, and probably not be too turned off by it* to come back in said few months if it is not as shiny as they might like or they might like some more commentary/analysis of the project as a whole done first.

*for ROM hacking and early stages coding environments on consoles we occasionally see bright new people come in, be faced with the initial hurdle and drop out where they might have made it 6-12 months later when such challenges are not quite as immediate. While I probably would not be too shocked to see some "just graduated java school but they did teach us some C18" types balk at the code then anybody else likely still able to do C at something like professional level (never mind the more hardcore legacy/K&R C set) will do OK here.


On a different note scrolled down a bit and "377 people currently viewing this thread". Bit more than I normally see for this sort of thing. Did it get picked up somewhere?


----------



## nim-ka (Jul 11, 2019)

FAST6191 said:


> I am not a great C coder but I did have a quick shuffle through the files. Clearly 90s era embedded device C but no outrageous spaghetti, nothing much in the way of obfuscation, functions and variables named reasonably well for a lot of things, some comments where things are maybe not the clearest,... all things that source releases and the other things that led to the contents of https://osgameclones.com/ have happily handled, or handled worse than, in the past. I would say more or less anybody that will be able to handle it in a few months will be able to make good headway with things now, and probably not be too turned off by it* to come back in said few months if it is not as shiny as they might like or they might like some more commentary/analysis of the project as a whole done first.


As someone who has been working with this codebase for quite a while now, it is really a lot more complicated than it looks until you get used to it. Most people's interests are in stuff like adding levels and items and models etc., which cannot be easily done with what was leaked



FAST6191 said:


> On a different note scrolled down a bit and "377 people currently viewing this thread". Bit more than I normally see for this sort of thing. Did it get picked up somewhere?


The thread was crossposted to multiple subreddits


----------



## PhyChris (Jul 11, 2019)

If its incomplete but builds a 1/1 rom copy then the important subroutine labels are all thats needed for some huge romhacking power.


----------



## hippy dave (Jul 11, 2019)

Awesome, now can someone decompile a more modern mario game and port some of the improved controls & camera code to mario 64?


----------



## cearp (Jul 11, 2019)

this is sick. absolutely amazing! i hope the fact that it was leaked doesn't stop people finishing tidying it up. (if it isn't finished already)
@Reecey i thought you might like this bud?


----------



## mountainflaw (Jul 11, 2019)

cearp said:


> this is sick. absolutely amazing! i hope the fact that it was leaked doesn't stop people finishing tidying it up. (if it isn't finished already)
> @Reecey i thought you might like this bud?



It's not stopping.


----------



## hippy dave (Jul 11, 2019)

mountainflaw said:


> It's not stopping.


So their plan was, and still is, to release when finished?


----------



## mountainflaw (Jul 11, 2019)

hippy dave said:


> So their plan was, and still is, to release when finished?



Yes. I've been trying to get it publicly released for awhile at this point.


----------



## hippy dave (Jul 11, 2019)

mountainflaw said:


> Yes. I've been trying to get it publicly released for awhile at this point.


Cool. Also happy gbatemp birthday


----------



## mountainflaw (Jul 11, 2019)

hippy dave said:


> Cool. Also happy gbatemp birthday


Heh, I never even realized.


----------



## FAST6191 (Jul 11, 2019)

nim-ka said:


> As someone who has been working with this codebase for quite a while now, it is really a lot more complicated than it looks until you get used to it. Most people's interests are in stuff like adding levels and items and models etc., which cannot be easily done with what was leaked
> 
> 
> The thread was crossposted to multiple subreddits



I have not kept up with the Mario 64 stuff on the N64 as much as the Banjo Kazooie stuff and editing done for Rare games but are those not already within the realms of level editors and existing tools?

When I was looking at the code it was more with an eye to doing some of the things on https://gbatemp.net/threads/super-mario-64-has-been-decompiled.542918/page-2#post-8707994 which is what we normally see when code like this gets released (camera tweaks, boss rushes, hard mode tweaks that don't involve some assembly doing a shift somewhere, control remapping without having to worry about edge cases, increasing delays/windows for certain moves, shifting songs from within the game to elsewhere within the game). Some things were not immediately obvious and a bit obtuse but as any fixes or mods made to them will be equally so (3d cameras are hard and all that).


----------



## Ecchi95 (Jul 11, 2019)

Ocarina of Time, Majora's Mask, and Paper Mario are being decompiled, too:
https://github.com/camthesaxman/zelda_ocarina_mq_debug
https://github.com/Rozelette/Majora-Unmasked
https://github.com/pm-reverse-engineering/papermario_source

Extremely early stages.


----------



## Reecey (Jul 11, 2019)

cearp said:


> this is sick. absolutely amazing! i hope the fact that it was leaked doesn't stop people finishing tidying it up. (if it isn't finished already)
> @Reecey i thought you might like this bud?


Thanks for the heads up! Ive only just red up on this fantastic news! I have been following some really cool Mario64 hacks on YouTube there’s some really interesting projects going on lately, whether these have any connection I’m not sure but the fact we can compile mario 64 to other consoles with freedom is a huge accomplishment, excellent work all involved in the project.


----------



## Zacharybinx34 (Jul 11, 2019)

So does this mean it's graphics can be drastically upgraded now?


----------



## CeeDee (Jul 11, 2019)

Dartz150 said:


> Nice, I wish I could have spare time to invest it to make a 3DS port with all the new mechanics introduced in the DS version


I'd pay good money for a 3DS port that was completely vanilla, even.


----------



## Reecey (Jul 11, 2019)

There are some really good historic projects for mario64 on kudos64 now sm64hacks, you can inject the projects into a DS SM64 rom and use it on a DSTwo supercard and play this on your 3DS I have done this plenty in the past and some of the projects are so impressive.

Edit: I think it used to be called Kudos64 maybe someone can correct me?


----------



## Dartz150 (Jul 11, 2019)

Zacharybinx34 said:


> So does this mean it's graphics can be drastically upgraded now?



In theory, yes, in practice, it still would require some work, because one has to re-model everything, or just import models from newer Mario games, but again, that requires some extra time to be worked, because the developers back then, made tricky workarounds for many things that were still unknown for it's time, after all, 3D Videogame development was on its early days. For example, many people doesn't know that Mario's body isn't textured at all, those are raw colored polygons and nothing else lol.



CeeDee said:


> I'd pay good money for a 3DS port that was completely vanilla, even.



Well, I would need some time to know the 3DS internals and capabilities homebrew-wise, such as what control we have on the system so far. I believe that as today we have full control, so _*anything*_ is possible inside that tiny but marvelous handheld. I will try to play around with the source code on PC first, and maybe, _little maybe_ I will look if I can port that to the 3DS, if someone can put me in the right direction it would be much appreciated.


----------



## mountainflaw (Jul 11, 2019)

btw, good luck porting graphics over. there's no internal model format except for the mario head system. so everything basically is just a bunch of n64 drawcalls :^)


----------



## cearp (Jul 11, 2019)

mountainflaw said:


> btw, good luck porting graphics over. there's no internal model format except for the mario head system. so everything basically is just a bunch of n64 drawcalls :^)


wow that's intense. but still, not impossible to work with. maybe a script to parse those drawcalls and make a model...?
no idea but i won't be surprised if someone manages it.


----------



## CrashOveride (Jul 11, 2019)

While I am very interested in the progress of the various N64 decomp projects (particularly GoldenEye's) I don't like messing with leaked stuff, particularly a leaked revision of the repo which was uploaded without the permission of anyone on the team. Considering that only 60% of function names are done, according to revo at least, I'd rather wait until the team considers it done.


----------



## Ecchi95 (Jul 11, 2019)

cearp said:


> wow that's intense. but still, not impossible to work with. maybe a script to parse those drawcalls and make a model...?
> no idea but i won't be surprised if someone manages it.


That is a misleading statement. Models for almost every individual thing are in neatly-packed binary files. The decompilation did something redundant and turned those binary files into C-like files.

Only some graphics are dynamically generated.


----------



## Dartz150 (Jul 11, 2019)

mountainflaw said:


> btw, good luck porting graphics over. there's no internal model format except for the mario head system. so everything basically is just a bunch of n64 drawcalls :^)



Yeah, expected no more as I said earlier. Now that you confirm this then there's much work to do to port this to other platforms, we will need to re-write everything first to a standard format, and that's a lot by itself.



cearp said:


> wow that's intense. but still, not impossible to work with. maybe a script to parse those drawcalls and make a model...?
> no idea but i won't be surprised if someone manages it.



Yeh not impossible, and yeah those can be parsed, the problem is that that would require processing everything and write it back to the main code, we'll have to edit everything as the new format to have it working properly, and that takes weeks by my experience.


----------



## CrashOveride (Jul 11, 2019)

Good luck parsing F3D displaylists to a contemporary model format

--------------------- MERGED ---------------------------

Of particular interest however is that this has been crossposted to a LOT of subreddits, which is very odd considering Nintendo's nature about fan projects.


----------



## Ecchi95 (Jul 11, 2019)

CrashOveride said:


> Good luck parsing F3D displaylists to a contemporary model format


You can rewrite the graphics routines to not use F3D if you're porting this, and it's already possible to dump graphics to a higher level format while emulating.

You almost don't have to touch the F3D GBI at all. Only a very small number of graphics are dynamically generated.


----------



## CrashOveride (Jul 11, 2019)

Ecchi95 said:


> You can rewrite the graphics routines to not use F3D if you're porting this, and it's already possible to dump graphics to a higher level format while emulating.
> 
> You almost don't have to touch the F3D GBI at all. Only a very small number of graphics are dynamically generated.



So you're saying you'd rather use crappy export from VRML than editing the raw displaylist data?


----------



## Ecchi95 (Jul 11, 2019)

CrashOveride said:


> So you're saying you'd rather use crappy export from VRML than editing the raw displaylist data?


My point is you don't have to use the original models. You could make all new models if you're doing an enhanced port. (Original code, brand new assets.)


----------



## Zacharybinx34 (Jul 11, 2019)

Dartz150 said:


> In theory, yes, in practice, it still would require some work, because one has to re-model everything, or just import models from newer Mario games, but again, that requires some extra time to be worked, because the developers back then, made tricky workarounds for many things that were still unknown for it's time, after all, 3D Videogame development was on its early days. For example, many people doesn't know that Mario's body isn't textured at all, those are raw colored polygons and nothing else lol.
> 
> 
> 
> Well, I would need some time to know the 3DS internals and capabilities homebrew-wise, such as what control we have on the system so far. I believe that as today we have full control, so _*anything*_ is possible inside that tiny but marvelous handheld. I will try to play around with the source code on PC first, and maybe, _little maybe_ I will look if I can port that to the 3DS, if someone can put me in the right direction it would be much appreciated.



I would LOVE to see an upgraded Camera + Mario 64 looking like Mario Sunshine/Odyssey


----------



## mountainflaw (Jul 11, 2019)

>My point is you don't have to use the original models. You could make all new models if you're doing an enhanced port. (Original code, brand new assets.

Hard when a lot of the code is tied to the graphics


----------



## Ecchi95 (Jul 11, 2019)

mountainflaw said:


> >My point is you don't have to use the original models. You could make all new models if you're doing an enhanced port. (Original code, brand new assets.
> 
> Hard when a lot of the code is tied to the graphics


You can get rid of that code. You only really need the logic for Mario and the things he interacts with.


----------



## mountainflaw (Jul 11, 2019)

I never said it was impossible. However as someone who actually has worked on the project, I can tell you removing the n64 graphicsisms from the main code isn't fun. Also, there is much much MUCH more than just Mario's code you'd want, especially since it's all intertwined.


----------



## CrashOveride (Jul 11, 2019)

>You can get rid of that code. You only really need the logic for Mario and the things he interacts with.

what? have you even looked at the code at all?


----------



## Ecchi95 (Jul 11, 2019)

CrashOveride said:


> >You can get rid of that code. You only really need the logic for Mario and the things he interacts with.
> 
> what? have you even looked at the code at all?


Yes, I have. I couldn't have made the file list for one of the src directories if I didn't have it.

The most important parts are the player code and the code for all the animate and inanimate objects they interact with. You can abstract out the N64-dependent stuff. You just reference it to get the gist of what it's trying to do.


----------



## CrashOveride (Jul 11, 2019)

I didn't ask if you had the code, I asked have you bothered to read it at all.

Using a search function for .c and .asm is not an answer

I consider arguing with @mountainflaw, someone who actively participated in the decomp process, useless


----------



## Ecchi95 (Jul 11, 2019)

CrashOveride said:


> I didn't ask if you had the code, I asked have you bothered to read it at all.
> 
> Using a search function for .c and .asm is not an answer
> 
> I consider arguing with @mountainflaw, someone who actively participated in the decomp process, useless


YES, I HAVE. Look at the files in src/behaviors. Not too many N64 graphics things in them: *(you can REFERENCE the graphics stuff in the other files to get the GIST of it instead of faithfully doing every little thing)

(what @mountainflaw is saying is irrelevant depending on how much accuracy you want to trade)*


```
/**
 * Behavior for bhvEnemyLakitu.
 * Lakitu comes before it spawned spinies in processing order.
 * TODO: bhvCloud processing oredr
 */


/**
 * Hitbox for evil lakitu.
 */
static struct ObjectHitbox sEnemyLakituHitbox =
{
    /* interactType:      */ INTERACT_HIT_FROM_BELOW,
    /* downOffset:        */ 0,
    /* damageOrCoinValue: */ 2,
    /* health:            */ 0,
    /* numLootCoins:      */ 5,
    /* radius:            */ 50,
    /* height:            */ 50,
    /* hurtboxRadius:     */ 40,
    /* hurtboxHeight:     */ 50,
};


/**
 * Wait for mario to approach, then spawn the cloud and become visible.
 */
static void enemy_lakitu_act_uninitialized(void)
{
    if (o->oDistanceToMario < 2000.0f)
    {
        spawn_object_relative_with_scale(
            CLOUD_BP_LAKITU_CLOUD,
            0, 0, 0,
            2.0f,
            o,
            MODEL_MIST,
            bhvCloud);

        obj_unhide();
        o->oAction = ENEMY_LAKITU_ACT_MAIN;
    }
}

/**
 * Accelerate toward mario vertically.
 */
static void enemy_lakitu_update_vel_y(f32 offsetY)
{
    // In order to encourage oscillation, pass mario by a small margin before
    // accelerating the opposite direction
    f32 margin;
    if (o->oVelY < 0.0f)
    {
        margin = -3.0f;
    }
    else
    {
        margin = 3.0f;
    }

    if (o->oPosY < gMarioObject->oPosY + offsetY + margin)
    {
        obj_y_vel_approach(4.0f, 0.4f);
    }
    else
    {
        obj_y_vel_approach(-4.0f, 0.4f);
    }
}

/**
 * Control speed based on distance to mario, turn toward mario, and change move
 * angle toward mario.
 */
static void enemy_lakitu_update_speed_and_angle(void)
{
    f32 minSpeed;
    s16 turnSpeed;

    f32 distToMario = o->oDistanceToMario;
    if (distToMario > 500.0f)
    {
        distToMario = 500.0f;
    }

    // Move faster the farther away mario is and the faster mario is moving
    if ((minSpeed = 1.2f * gMarioStates[0].forwardVel) < 8.0f)
    {
        minSpeed = 8.0f;
    }
    o->oForwardVel = distToMario * 0.04f;
    clamp_f32(&o->oForwardVel, minSpeed, 40.0f);

    // Accelerate toward mario vertically
    enemy_lakitu_update_vel_y(300.0f);

    // Turn toward mario except right after throwing a spiny
    if (o->oEnemyLakituFaceForwardCountdown != 0)
    {
        o->oEnemyLakituFaceForwardCountdown -= 1;
    }
    else
    {
        obj_face_yaw_approach(o->oAngleToMario, 0x600);
    }

    // Change move angle toward mario faster when farther from mario
    turnSpeed = (s16)(distToMario * 2.0f);
    clamp_s16(&turnSpeed, 0xC8, 0xFA0);
    obj_rotate_yaw_toward(o->oAngleToMario, turnSpeed);
}

/**
 * When close enough to mario and facing roughly toward him, spawn a spiny and
 * hold it, then enter the hold spiny sub-action.
 */
static void enemy_lakitu_sub_act_no_spiny(void)
{
    func_8029ED38(1);

    if (o->oEnemyLakituSpinyCooldown != 0)
    {
        o->oEnemyLakituSpinyCooldown -= 1;
    }
    else if (o->oEnemyLakituNumSpinies < 3 &&
        o->oDistanceToMario < 800.0f &&
        abs_angle_diff(o->oAngleToMario, o->oFaceAngleYaw) < 0x4000)
    {
        struct Object *spiny = spawn_object(o, MODEL_SPINY_BALL, bhvSpiny);
        if (spiny != NULL)
        {
            o->prevObj = spiny;
            spiny->oAction = SPINY_ACT_HELD_BY_LAKITU;

            func_8029EE20(spiny, spiny_egg_seg5_anims_050157E4, 0);

            o->oEnemyLakituNumSpinies += 1;
            o->oSubAction = ENEMY_LAKITU_SUB_ACT_HOLD_SPINY;
            o->oEnemyLakituSpinyCooldown = 30;
        }
    }
}

/**
 * When close to mario and facing toward him or when mario gets far enough away,
 * enter the throw spiny sub-action.
 */
static void enemy_lakitu_sub_act_hold_spiny(void)
{
    func_802F927C(3);

    if (o->oEnemyLakituSpinyCooldown != 0)
    {
        o->oEnemyLakituSpinyCooldown -= 1;
    }
    // TODO: Check if anything interesting happens if we bypass this with speed
    else if (o->oDistanceToMario > o->oDrawingDistance - 100.0f ||
        (o->oDistanceToMario < 500.0f &&
            abs_angle_diff(o->oAngleToMario, o->oFaceAngleYaw) < 0x2000))
    {
        o->oSubAction = ENEMY_LAKITU_SUB_ACT_THROW_SPINY;
        o->oEnemyLakituFaceForwardCountdown = 20;
    }
}

/**
 * Throw the spiny, then enter the no spiny sub-action.
 */
static void enemy_lakitu_sub_act_throw_spiny(void)
{
    if (func_802F92EC(2, 2))
    {
        PlaySound2(SOUND_OBJECT_EVILLAKITUTHROW);
        o->prevObj = NULL;
    }

    if (func_8029F788())
    {
        o->oSubAction = ENEMY_LAKITU_SUB_ACT_NO_SPINY;
        o->oEnemyLakituSpinyCooldown = random_linear_offset(100, 100);
    }
}

/**
 * Main update function.
 */
static void enemy_lakitu_act_main(void)
{
    PlaySound(SOUND_CH6_UNKNOWN002);

    obj_update_floor_and_walls();

    enemy_lakitu_update_speed_and_angle();
    if (o->oMoveFlags & OBJ_MOVE_HIT_WALL)
    {
        o->oMoveAngleYaw = obj_reflect_move_angle_off_wall();
    }

    obj_update_blinking(&o->oEnemyLakituBlinkTimer, 20, 40, 4);

    switch (o->oSubAction)
    {
    case ENEMY_LAKITU_SUB_ACT_NO_SPINY:    enemy_lakitu_sub_act_no_spiny();    break;
    case ENEMY_LAKITU_SUB_ACT_HOLD_SPINY:  enemy_lakitu_sub_act_hold_spiny();  break;
    case ENEMY_LAKITU_SUB_ACT_THROW_SPINY: enemy_lakitu_sub_act_throw_spiny(); break;
    }

    obj_move_standard(78);

    // Die and drop held spiny when attacked by mario
    if (obj_check_attacks(&sEnemyLakituHitbox, o->oAction))
    {
        // The spiny uses this as a signal to get thrown
        o->prevObj = NULL;
    }
}

/**
 * Update function for bhvEnemyLakitu.
 */
void bhv_enemy_lakitu_update(void)
{
    //PARTIAL_UPDATE

    treat_far_home_as_mario(2000.0f);

    switch (o->oAction)
    {
    case ENEMY_LAKITU_ACT_UNINITIALIZED: enemy_lakitu_act_uninitialized(); break;
    case ENEMY_LAKITU_ACT_MAIN:          enemy_lakitu_act_main();          break;
    }
}
```


----------



## SuckerPunch32 (Jul 11, 2019)

Ecchi95 said:


> YES, I HAVE. Look at the files in src/behaviors. Not too many N64 graphics things in them: (you can REFERENCE the graphics stuff in the other files to get the GIST of it instead of faithfully doing every little thing)
> 
> (what @mountainflaw is saying is irrelevant depending on how much accuracy you want to trade)
> 
> ...



That has nothing to do with the game or Mario, it's just behaviour code for an object. The rest of the game is basically tied to the N64 hardware. (Graphics, Audio, Engine (partially), etc.)


----------



## CrashOveride (Jul 11, 2019)

>(you can REFERENCE the graphics stuff in the other files to get the GIST of it instead of faithfully doing every little thing)
Then what is the point of making a source port if you can just do it from scratch


----------



## Cy8org1 (Jul 11, 2019)

yeah i rather side with @mountainflaw. Ive know him in multiple servers and he does alot for decomp so...


----------



## Ecchi95 (Jul 11, 2019)

CrashOveride said:


> >(you can REFERENCE the graphics stuff in the other files to get the GIST of it instead of faithfully doing every little thing)
> Then what is the point of making a source port if you can just do it from scratch


You have the precise code for the behaviors. You can do everything else yourself, just referencing the original code for the gist.

You think when they made Ocarina of Time 3D they reproduced EVERYTHING? No.


----------



## SuckerPunch32 (Jul 11, 2019)

Ecchi95 said:


> You have the precise code for the behaviors. You can do everything else yourself, just referencing the original code for the gist.
> 
> You think when they made Ocarina of Time 3D they reproduced EVERYTHING? No.



So what you're saying is basically just port over the logic? That has already been done, here:


----------



## mountainflaw (Jul 11, 2019)

I'm not sure who said it was impossible, all I was trying to say is that it's still not a walk in the park for a port.
The port bad_boot made took about a week to make, getting the graphics and sound systems to work would probably be a pain in the ass that would take a month or two.


----------



## nim-ka (Jul 11, 2019)

hey mountainflaw, wens modconv so everyone can shut up and hack???


----------



## Ecchi95 (Jul 11, 2019)

Change of pace, here's all the Reddit threads talking about this...

https://www.reddit.com/r/gamedev/comments/caekcg/super_mario_64_was_decompiled_by_someone/
https://www.reddit.com/r/n64/comments/cbmiyj/super_mario_64_decompiled/
https://www.reddit.com/r/emulation/comments/cbro9u/super_mario_64_has_been_decompiled/
https://www.reddit.com/r/linux_gami...per_mario_64_has_been_decompiled_possible_to/
https://www.reddit.com/r/programming/comments/cbvl6l/super_mario_64_was_fully_decompiled_c_source/
https://www.reddit.com/r/Technology...super_mario_64_was_fully_decompiled_c_source/
https://www.reddit.com/r/DataHoarder/comments/cbxlm2/decompiled_super_mario_64_source/
https://www.reddit.com/r/Games/comments/cbymz3/super_mario_64_has_been_decompiled/

And a humorous take on what Nintendo was doing to release the game in time:

https://forums.overclockers.com.au/threads/mario-64-source-code-released.1267815/





SuckerPunch32 said:


> So what you're saying is basically just port over the logic? That has already been done, here: https_:_//www_._youtube_._com/watch?v=7VbTe7U-bo4


That's exactly what I'm saying. That's the sane approach. And there can be competition for the cleanest logic port.


----------



## CrashOveride (Jul 11, 2019)

Why was this posted to so many threads? I'd rather the project not attract attention from nintendo


----------



## SuckerPunch32 (Jul 11, 2019)

CrashOveride said:


> Why was this posted to so many threads? I'd rather the project not attract attention from nintendo



^^THIS (Whoever posted that leak is going to get f*cked 23 times in the a**.)


----------



## mountainflaw (Jul 11, 2019)

SuckerPunch32 said:


> ^^THIS (Whoever posted that leak is going to get f*cked 23 times in the a**.)


geek gets pounded by angry lawyers


----------



## iGom (Jul 11, 2019)

https://ukikipedia.net/wiki/Version_Differences


----------



## nim-ka (Jul 11, 2019)

iGom said:


> https://ukikipedia.net/wiki/Version_Differences


Yo I made that page!


----------



## halo5307 (Jul 11, 2019)

Ecchi95 said:


> People should be doing things with it right now.





Ecchi95 said:


> Is anyone going to talk about the contents besides me? This is the entire code of Super Mario 64 we have here.
> 
> I want to see people analyzing it.



Nobody is going to spend quality time with a leaked project simply out of respect for the developers. The fact that you have the audacity to supplement the leak, and then demand people look into it (when it's very clear you know absolutely nothing about the code) is ridiculous.

That being said, I would like to thank the original developers behind the project. I've always been interested in learning how to decompile projects, so this is quite cool! If any of you are in the thread, where/ how did you learn to decompile programs?


----------



## nim-ka (Jul 11, 2019)

halo5307 said:


> I've always been interested in learning how to decompile projects, so this is quite cool! If any of you are in the thread, where/ how did you learn to decompile programs?



Most of my work was on cleaning up the C, but I've started learning how to decompile, simply through asking questions to people in the community about MIPS assembly, how the ROM is layed out, etc. It's not very hard to decompile a given bit of ASM if you know MIPS and C; it also requires experience with the compiler's output to know how to make optimized ASM match the compiled C.


----------



## Ecchi95 (Jul 11, 2019)

halo5307 said:


> when it's very clear you know absolutely nothing about the code


Excuse me. I've been looking at the code on and off since I posted this thread. I have a different vision for porting it than total accuracy.


----------



## halo5307 (Jul 11, 2019)

nim-ka said:


> Most of my work was on cleaning up the C, but I've started learning how to decompile, simply through asking questions to people in the community about MIPS assembly, how the ROM is layed out, etc. It's not very hard to decompile a given bit of ASM if you know MIPS and C; it also requires experience with the compiler's output to know how to make optimized ASM match the compiled C.



Very interesting, thanks! Until now I haven't even heard of MIPS assembly. I'll make sure to take a look at it.

My experience with programming is really limited to just Java, but C is on my radar. I hear projects are a good way to learn -- while something like this is out of my scope, it does give me incentive to start something smaller.


----------



## mountainflaw (Jul 11, 2019)

Basically, this started off a disassembly with almost no symbols named using n64split. People would just pick a file to convert to C in a manner that nim described.


----------



## Ecchi95 (Jul 11, 2019)

halo5307 said:


> Nobody is going to spend quality time with a leaked project simply out of respect for the developers.


If it's publicly available, it's public domain. That's what I live by.


----------



## halo5307 (Jul 11, 2019)

mountainflaw said:


> Basically, this started off a disassembly with almost no symbols named using n64split. People would just pick a file to convert to C in a manner that nim described.


So you guys must've had to use the code itself to infer what symbol to give it. Makes sense to me. Must've been a pain dealing with 20+ year old code. Hope there wasn't too many roadbumps on your side.

I'm at work currently, but I'd love to read the documentation 

--------------------- MERGED ---------------------------



Ecchi95 said:


> Excuse me. I've been looking at the code on and off since I posted this thread. I have a different vision for porting it than total accuracy.


Anyone can read code. I'm willing to bet that if I pointed to a line of code and asked you explain exactly what it did, you would have no idea. It's for  this reason programmers are paid so much, it's hard work! It's even rarer for passion projects like this to come to fruition, because you are essentially working for free. So please, treat the devs with respect.

 I can infer this because of how excited you are for the project, and how angsty you got when you realized that nobody was researching the code alongside you.


Ecchi95 said:


> If it's publicly available, it's public domain. It's what I live by.


There are...._so_ many things wrong with this statement. Best of luck with your future mate, thanks for the interesting find.


----------



## nim-ka (Jul 11, 2019)

Just wanna reiterate, lots of people *are* investigating SM64's code with this, it's just a relatively obscure community


----------



## FAST6191 (Jul 11, 2019)

Zacharybinx34 said:


> So does this mean it's graphics can be drastically upgraded now?


Others already went but that will depend upon what you mean by that.

It is early efforts at N64 3d and later devs (homebrew, demoscene and commercial) will likely have discovered more ways to push the hardware to the limit (don't know if we will be seeing expansion pack edition any time soon). Such things will be far easier added at source level than playing ROM hacker to do that -- most ROM hacking is limited by practicality to fun things like big head, simple texture or colour swaps, simple alignments tweaks to more closely match hit boxes, simple things to change sizes of items but keep them essentially the same rather than implementing a trick found by some dev 5 years into the system life to effect a slightly better anti aliasing or whatever. I don't know how far the code leans into the hardware at this point (sometimes such things make it harder to adapt, even within the hardware) but if it is reasonable within hardware then it is should be doable.

If source is available then realistically it could also be ported to another system, like the PC, and then all bets are off. Others have mentioned how tricky such things likely will be -- early 3d does not translate that well to modern opengl or directx approaches to the world owing to some quirks so it is a bit more work in some regards than it would be to convert a 360 game to a modern PC, though still far easier than a mechanics recreation followed by an asset conversion/recreation. Or go another way notice the general lack of widescreen hacks of PS1-N64 era games when later stuff is littered with them (even within what is still almost hardware backwards compatibility) -- there is a reason for that one.

The N64 however is something of a poster child for the texture replacement at emulator level approach (usually referred to by names like HD texture replacement) -- it was around before, and has been taken to greater heights on newer systems, but the N64 is where most of the world was introduced to it all. Initially I am not expecting too much here (it has already been mapped fairly well and replacements already achievable) but it does open the door to stick a whole bunch of debug flags in a game that an emulator might be more carefully crafted around, future emulators given to use (part of the problem with texture hacks is how not portable they actually are, and how much effort over baseline emulation they require), or non hacker/coder end users to swap out their own textures at file level to create a nice mix and match approach.
As such things have happened for years then technically speaking this is not going to see drastic upgrades in the short term beyond what you, a special PC emulator and finding a working download of a texture pack can probably do over the next few hours if you were so inclined.


----------



## Ecchi95 (Jul 11, 2019)

halo5307 said:


> I'm willing to bet that if I pointed to a line of code and asked you explain exactly what it did, you would have no idea. It's for  this reason programmers are paid so much, it's hard work! It's even rarer for passion projects like this to come to fruition, because you are essentially working for free. So please, treat the devs with respect.
> 
> I can infer this because of how excited you are for the project, and how angsty you got when you realized that nobody was researching the code alongside you.


I am a programmer. I'm making my own Nintendo 64 emulator.


```
#include <badn64.h>
#include <stdio.h>

/*
RAM: rambus dynamic Random-Access Memory
REG: rdram REGisters
RCP: Reality CoProcessor
LEO: LEO registers (64DD)
IPL: Initial Program Load (64DD)
STA: STAtic ram
ROM: ROM (cartridge)
PIF: Program Information File
*/

/* enumerated memory segments */
enum SEGMENT{RAM, REG, RCP, LEO, IPL, STA, ROM, PIF};

/* lookup table for the purpose of translating n64 memory segments to our segments */
BYTE LUT[0x20]=
{/* 0x00           0x03 0x04 0x05 0x06      0x08                                    */
    RAM,   0,   0, REG, RCP, LEO, IPL,   0, STA,   0,   0,   0,   0,   0,   0,   0,
   
 /* 0x10                                                                       0x1F */
    ROM,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0,   0, PIF
};

WORD loop;

/* function for sign extension of immediate values */
WORD extend(HALF imm);
WORD extend(HALF imm)
{
    WORD extended;
    if(sign(imm)==0x8000)
    {
         extended=0xffff0000|imm;
    }
    else
    {
         extended=imm;
    }
    return extended;
}

/* function for reading 32 bits */
WORD read32(BYTE *mem[8], WORD ptr);
WORD read32(BYTE *mem[8], WORD ptr)
{
    BYTE temp=(ptr>>24)&0x1f;
    switch(LUT[temp])
    {
         case REG:
              ptr&=0x0fffff;
              break;
         case PIF:
              ptr&=0x3fffff;
              break;
         default:
              ptr&=0xffffff;
              break;
    }
    return (WORD)((mem[LUT[temp]][ptr]<<24)|(mem[LUT[temp]][ptr+1]<<16)|(mem[LUT[temp]][ptr+2]<<8)|mem[LUT[temp]][ptr+3]);
}

void handle_pi(BYTE *mem[8], WORD ptr);
void handle_pi(BYTE *mem[8], WORD ptr)
{
    WORD dram_addr, cart_addr, rd_len, wr_len;
    dram_addr=read32(mem,0xa4600000);
    cart_addr=read32(mem,0xa4600004)&0xffffff;
    rd_len=1+read32(mem,0xa4600008);
    wr_len=1+read32(mem,0xa460000c);
    if(ptr==0x600008)
    {
    }
    else if(ptr==0x60000c)
    {
         for(loop=0;loop<wr_len;loop+=1)
         {
              mem[RAM][dram_addr+loop]=mem[ROM][cart_addr+loop];
         }
    }
}

/* function for writing 32 bits */
void write32(BYTE *mem[8], WORD ptr, WORD val);
void write32(BYTE *mem[8], WORD ptr, WORD val)
{
    BYTE handle=9;
    BYTE temp=(ptr>>24)&0x1f;
    switch(LUT[temp])
    {
         case REG:
              ptr&=0x0fffff;
              break;
         case RCP:
              handle=(ptr&0xf00000)>>20;
              ptr&=0xffffff;
              break;
         case PIF:
              ptr&=0x3fffff;
              break;
         default:
              ptr&=0xffffff;
              break;
    }
    mem[LUT[temp]][ptr]=(val>>24)&0xff;
    mem[LUT[temp]][ptr+1]=(val>>16)&0xff;
    mem[LUT[temp]][ptr+2]=(val>>8)&0xff;
    mem[LUT[temp]][ptr+3]=val&0xff;
    switch(handle)
    {
         case 6:
              handle_pi(mem,ptr);
              break;
    }
}

int main(int argc, char **argv)
{
    const char names[32][3]=
    {
         "r0", "at", "v0", "v1",
         "a0", "a1", "a2", "a3",
         "t0", "t1", "t2", "t3",
         "t4", "t5", "t6", "t7",
         "s0", "s1", "s2", "s3",
         "s4", "s5", "s6", "s7",
         "t8", "t9", "k0", "k1",
         "gp", "sp", "fp", "ra"
    };
    BYTE *mem[8], delay=0, depth=0;
    WORD CPU[32]={0},CP0[32]={0},pc=0xa4000040,tick=0,ticks,inst;
    unsigned long long sixtyfour;
    WORD hi, lo;
    FILE *cart=fopen(argv[1],"rb");
    fseek(cart,0,SEEK_END);
    loop=ftell(cart);
    WORD sizes[8]=
    {
         0x800000, /* RAM */
         0x100000, /* REG */
         0x80001c, /* RCP */
         0x0005c0, /* LEO */
         0x400000, /* IPL */
         0x008000, /* STA */
         loop,     /* ROM */
         0x000800  /* PIF */
    };
    for(loop=0;loop<8;loop+=1)
    {
         mem[loop]=(BYTE*)calloc(sizes[loop],1); /* allocate our memory segments and init to zero */
    }
    fseek(cart,0,SEEK_SET);
    fread(mem[ROM],1,sizes[ROM],cart);
    fclose(cart);
    for(loop=0;loop<0xfc0;loop+=1)
    {
         mem[RCP][0x40+loop]=mem[ROM][0x40+loop];
    }
    write32(mem,0xa4001000,0x3c0dbfc0); /* SP IMEM +0 */
    write32(mem,0xa4001004,0x8da807fc); /* SP IMEM +4 */
    write32(mem,0xa4001008,0x25ad07c0); /* SP IMEM +8 */
    write32(mem,0xa400100c,0x31080080); /* SP IMEM +0xC */
    write32(mem,0xa4001010,0x5500fffc); /* SP IMEM +0x10*/
    write32(mem,0xa4001014,0x3c0dbfc0); /* SP IMEM +0x14*/
    write32(mem,0xa4001018,0x8da80024); /* SP IMEM +0x18*/
    write32(mem,0xa400101c,0x3c0bb000); /* SP IMEM +0x1C*/
    write32(mem,0xa4040010,1);          /* SP status */
    write32(mem,0xa4300004,0x02020102); /* MI version*/
    write32(mem,0xa4600014,0x40);       /* PI dom1 latency */
    write32(mem,0xa4600018,0x12);       /* PI dom1 pulse width */
    write32(mem,0xa460001c,7);          /* PI dom1 page size */
    write32(mem,0xa4600020,3);          /* PI dom1 dom1 release*/
    CPU[S4]=1;                          /* tv type */
    CPU[S6]=0x3f;                       /* seed */
    CPU[T3]=pc;
    CPU[SP]=0xa4001ff0;                 /* Stack Pointer */
    CPU[RA]=0xa4001550;                 /* Return Address*/
    /*printf("How many ticks? ");*/
    /*scanf("%d",&ticks);*/
    while(tick<0xffffffff)
    {
         if(pc==read32(mem,0xb0000008))
         {
              printf("%10d\n",tick);
              break;
         }
         inst=read32(mem,pc);
         switch(op(inst))
         {
              case SPECIAL:
                   switch(funct(inst))
                   {
                        case SLL:
                             CPU[rd(inst)]=CPU[rt(inst)]<<sa(inst);
                             break;
                        case SRL:
                             CPU[rd(inst)]=CPU[rt(inst)]>>sa(inst);
                             break;
                        case SLLV:
                             CPU[rd(inst)]=CPU[rt(inst)]<<(CPU[rs(inst)]&0x1f);
                             break;
                        case SRLV:
                             CPU[rd(inst)]=CPU[rt(inst)]>>(CPU[rs(inst)]&0x1f);
                             break;
                        case JR:
                             if(delay==0)
                             {
                                  delay=1;
                             }
                             else if(delay==3)
                             {
                                  pc=CPU[rs(inst)]-4;
                                  if(pc==CPU[RA]-4)
                                  {
                                       depth-=1;
                                       printf("%10d %08x: ",tick+1,pc+4);
                                       for(loop=0;loop<depth;loop+=1)
                                       {
                                            printf(" ");
                                       }
                                       printf("returned from function\n");
                                  }
                                  delay=0;
                             }
                             break;
                        case JALR:
                             if(delay==0)
                             {
                                  CPU[rd(inst)]=pc+8;
                                  delay=1;
                             }
                             else if(delay==3)
                             {
                                  pc=CPU[rs(inst)]-4;
                                  delay=0;
                             }
                             break;
                        case MFLO:
                             CPU[rd(inst)]=lo;
                             break;
                        case MULTU:
                             sixtyfour=CPU[rs(inst)]*CPU[rt(inst)];
                             hi=sixtyfour>>32;
                             lo=sixtyfour&0xffffffff;
                             break;
                        case ADD:
                             CPU[rd(inst)]=CPU[rs(inst)]+CPU[rt(inst)];
                             break;
                        case ADDU:
                             CPU[rd(inst)]=CPU[rs(inst)]+CPU[rt(inst)];
                             break;
                        case SUBU:
                             CPU[rd(inst)]=CPU[rs(inst)]-CPU[rt(inst)];
                             break;
                        case AND:
                             CPU[rd(inst)]=CPU[rs(inst)]&CPU[rt(inst)];
                             break;
                        case OR:
                             CPU[rd(inst)]=CPU[rs(inst)]|CPU[rt(inst)];
                             break;
                        case XOR:
                             CPU[rd(inst)]=CPU[rs(inst)]^CPU[rt(inst)];
                             break;
                        case SLT:
                             CPU[rd(inst)]=0;
                             if((int)(CPU[rs(inst)])<(int)(CPU[rt(inst)]))
                             {
                                  CPU[rd(inst)]=1;
                             }
                             break;
                        case SLTU:
                             CPU[rd(inst)]=0;
                             if(CPU[rs(inst)]<CPU[rt(inst)])
                             {
                                  CPU[rd(inst)]=1;
                             }
                             break;
                   }
                   break;
              case REGIMM:
                   switch(rt(inst))
                   {
                        case BLTZ:
                             if(delay==0)
                             {
                                  delay=1;
                             }
                             else if(delay==3)
                             {
                                  if(CPU[rs(inst)]<0)
                                  {
                                       pc+=extend(imm(inst)<<2)-4;
                                  }
                                  pc+=4;
                                  delay=0;
                             }
                             break;
                        case BGEZ:
                             if(delay==0)
                             {
                                  delay=1;
                             }
                             else if(delay==3)
                             {
                                  if(CPU[rs(inst)]>=0)
                                  {
                                       pc+=extend(imm(inst)<<2)-4;
                                  }
                                  pc+=4;
                                  delay=0;
                             }
                             break;
                        case BLTZL:
                             if(delay==0)
                             {
                                  if(CPU[rs(inst)]<0)
                                  {
                                       delay=1;
                                  }
                                  else
                                  {
                                       pc+=4;
                                  }
                             }
                             else if(delay==3)
                             {
                                  pc+=extend(imm(inst)<<2);
                                  delay=0;
                             }
                             break;
                        case BGEZL:
                             if(delay==0)
                             {
                                  if(CPU[rs(inst)]>=0)
                                  {
                                       delay=1;
                                  }
                                  else
                                  {
                                       pc+=4;
                                  }
                             }
                             else if(delay==3)
                             {
                                  pc+=extend(imm(inst)<<2);
                                  delay=0;
                             }
                             break;
                        case BLTZAL:
                             if(delay==0)
                             {
                                  CPU[RA]=pc+8;
                                  delay=1;
                             }
                             else if(delay==3)
                             {
                                  if(CPU[rs(inst)]<0)
                                  {
                                       pc+=extend(imm(inst)<<2)-4;
                                  }
                                  pc+=4;
                                  delay=0;
                             }
                             break;
                        case BGEZAL:
                             if(delay==0)
                             {
                                  CPU[RA]=pc+8;
                                  delay=1;
                             }
                             else if(delay==3)
                             {
                                  if(CPU[rs(inst)]>=0)
                                  {
                                       pc+=extend(imm(inst)<<2)-4;
                                  }
                                  pc+=4;
                                  delay=0;
                             }
                             break;
                        case BLTZALL:
                             if(delay==0)
                             {
                                  CPU[RA]=pc+8;
                                  if(CPU[rs(inst)]<0)
                                  {
                                       delay=1;
                                  }
                                  else
                                  {
                                       pc+=4;
                                  }
                             }
                             else if(delay==3)
                             {
                                  pc+=extend(imm(inst)<<2);
                                  delay=0;
                             }
                             break;
                        case BGEZALL:
                             if(delay==0)
                             {
                                  CPU[RA]=pc+8;
                                  if(CPU[rs(inst)]>=0)
                                  {
                                       delay=1;
                                  }
                                  else
                                  {
                                       pc+=4;
                                  }
                             }
                             else if(delay==3)
                             {
                                  pc+=extend(imm(inst)<<2);
                                  delay=0;
                             }
                             break;
                   }
                   break;
              case J:
                   if(delay==0)
                   {
                        delay=1;
                   }
                   else if(delay==3)
                   {
                        pc=((pc&0xf0000000)|target(inst))-4;
                        delay=0;
                   }
                   break;
              case JAL:
                   if(delay==0)
                   {
                        CPU[RA]=pc+8;
                        delay=1;
                   }
                   else if(delay==3)
                   {
                        printf("%10d %08x: ",tick+1,pc);
                        for(loop=0;loop<depth;loop+=1)
                        {
                             printf(" ");
                        }
                        pc=((pc&0xf0000000)|target(inst))-4;
                        printf("jumped inside function (%08x)\n",pc+4);
                        depth+=1;
                        delay=0;
                   }
                   break;
              case BEQ:
                   if(delay==0)
                   {
                        delay=1;
                   }
                   else if(delay==3)
                   {
                        if(CPU[rs(inst)]==CPU[rt(inst)])
                        {
                             pc+=extend(imm(inst)<<2)-4;
                        }
                        pc+=4;
                        delay=0;
                   }
                   break;
              case BNE:
                   if(delay==0)
                   {
                        delay=1;
                   }
                   else if(delay==3)
                   {
                        if(CPU[rs(inst)]!=CPU[rt(inst)])
                        {
                             pc+=extend(imm(inst)<<2)-4;
                        }
                        pc+=4;
                        delay=0;
                   }
                   break;
              case BLEZ:
                   if(delay==0)
                   {
                        delay=1;
                   }
                   else if(delay==3)
                   {
                        if(CPU[rs(inst)]<=0)
                        {
                             pc+=extend(imm(inst)<<2)-4;
                        }
                        pc+=4;
                        delay=0;
                   }
                   break;
              case BGTZ:
                   if(delay==0)
                   {
                        delay=1;
                   }
                   else if(delay==3)
                   {
                        if(CPU[rs(inst)]>0)
                        {
                             pc+=extend(imm(inst)<<2)-4;
                        }
                        pc+=4;
                        delay=0;
                   }
                   break;
              case ADDI:
                   CPU[rt(inst)]=CPU[rs(inst)]+extend(imm(inst));
                   break;
              case ADDIU:
                   CPU[rt(inst)]=CPU[rs(inst)]+extend(imm(inst));
                   break;
              case SLTI:
                   CPU[rt(inst)]=0;
                   if((int)(CPU[rs(inst)])<(int)(extend(imm(inst))))
                   {
                        CPU[rt(inst)]=1;
                   }
                   break;
              case SLTIU:
                   CPU[rt(inst)]=0;
                   if(CPU[rs(inst)]<extend(imm(inst)))
                   {
                        CPU[rt(inst)]=1;
                   }
                   break;
              case ANDI:
                   CPU[rt(inst)]=CPU[rs(inst)]&imm(inst);
                   break;
              case ORI:
                   CPU[rt(inst)]=CPU[rs(inst)]|imm(inst);
                   break;
              case XORI:
                   CPU[rt(inst)]=CPU[rs(inst)]^imm(inst);
                   break;
              case LUI:
                   CPU[rt(inst)]=imm(inst)<<16;
                   break;
              case COP0:
                   switch(rs(inst))
                   {
                        case MT:
                             CP0[rd(inst)]=CPU[rt(inst)];
                             break;
                   }
                   break;
              case BEQL:
                   if(delay==0)
                   {
                        if(CPU[rs(inst)]==CPU[rt(inst)])
                        {
                             delay=1;
                        }
                        else
                        {
                             pc+=4;
                        }
                   }
                   else if(delay==3)
                   {
                        pc+=extend(imm(inst)<<2);
                        delay=0;
                   }
                   break;
              case BNEL:
                   if(delay==0)
                   {
                        if(CPU[rs(inst)]!=CPU[rt(inst)])
                        {
                             delay=1;
                        }
                        else
                        {
                             pc+=4;
                        }
                   }
                   else if(delay==3)
                   {
                        pc+=extend(imm(inst)<<2);
                        delay=0;
                   }
                   break;
              case BLEZL:
                   if(delay==0)
                   {
                        if(CPU[rs(inst)]<=0)
                        {
                             delay=1;
                        }
                        else
                        {
                             pc+=4;
                        }
                   }
                   else if(delay==3)
                   {
                        pc+=extend(imm(inst)<<2);
                        delay=0;
                   }
                   break;
              case BGTZL:
                   if(delay==0)
                   {
                        if(CPU[rs(inst)]>0)
                        {
                             delay=1;
                        }
                        else
                        {
                             pc+=4;
                        }
                   }
                   else if(delay==3)
                   {
                        pc+=extend(imm(inst)<<2);
                        delay=0;
                   }
                   break;
              case LW:
                   loop=CPU[rs(inst)]+extend(imm(inst));
                   CPU[rt(inst)]=read32(mem,loop);
                   break;
              case LBU:
                   loop=CPU[rs(inst)]+extend(imm(inst));
                   CPU[rt(inst)]=read32(mem,loop)>>24;
                   break;
              case SB:
                   loop=CPU[rs(inst)]+extend(imm(inst));
                   switch(LUT[(loop>>24)&0x1f])
                   {
                        case REG:
                             mem[REG][loop&0x0fffff]=CPU[rt(inst)]&0xff;
                             break;
                        case PIF:
                             mem[PIF][loop&0x3fffff]=CPU[rt(inst)]&0xff;
                             break;
                        default:
                             mem[LUT[(loop>>24)&0x1f]][loop&0xffffff]=CPU[rt(inst)]&0xff;
                             break;
                   }
                   break;
              case SW:
                   loop=CPU[rs(inst)]+extend(imm(inst));
                   write32(mem,loop,CPU[rt(inst)]);
                   break;
              case CACHE:
                   break;
         }
         pc+=4;
         tick+=1;
         if(delay>0)
         {
              delay+=1;
              tick-=1;
              if(delay==3)
              {
                   pc-=8;
                   tick+=1;
              }
         }
    }
    for(loop=0;loop<32;loop+=1)
    {
         printf("%s: %08x ",names[loop],CPU[loop]);
         if(loop%4==3)
         {
              printf("\n");
         }
    }
    printf("pc: %08x\n",pc);
    system("pause");
    for(loop=0;loop<8;loop+=1)
    {
         free(mem[loop]);
    }
    return 0;
}
```


----------



## nim-ka (Jul 11, 2019)

Ecchi95 said:


> I'm making my own Nintendo 64 emulator.


lol good luck with graphics


----------



## TheMrIron2 (Jul 11, 2019)

It would be such a colossal pain in the ass to rework graphics code alone for PC. I'll explain in a little more detail, but my intention here is not to steal the spotlight from the actual developers who have done a _ton_ of work.

Super Mario 64 was an early N64 game that was not among the platform's most extreme efforts, from a programming or technical perspective. But even despite this, it's worth noting a few things about the game - or the N64 hardware in general. The N64 had the main CPU, the function of which can be found by googling what a processor is, but it also had a separate graphics chip - though I'd say it was too primitive to be called a "GPU" by today's standards. This second chip was called the Reality Coprocessor, or RCP.

The RCP was further subdivided into the Reality Signal Processor (RSP), which handled the geometry and some audio, and the Reality Display Processor (RDP), which handled display lists and other functionality which I won't delve into in too much detail. The RSP used "microcode" at runtime, which could be compared to modern-day shader languages (eg. OpenGL's GLSL) - Mario 64 used the very first iteration of Nintendo's microcode, Fast3D (meaning, on a side note, it was never going to be able to push quite as many polygons as later N64 games - but microcode on N64 is a whole other discussion!). As FAST mentioned above, despite passing resemblances to modern shader languages, a lot of this graphics code is _very old _and is just not conducive to new graphics cards which are geared for use with modern rendering techniques. Even the Xbox 360 and PS3 were not particularly suited to the PS2's rendering techniques, let alone an even older console vs. the latest PCs.

So consider this, before considering a PC port; are you willing to rework all of the microcode-related code, all of the RCP/RDP code for graphics and audio _and_ any MIPS code (if any still exists - I haven't looked at the code out of respect until it's finished) to port this game? Such an undertaking is massive even with knowledge of the system and the game. I really want everyone to settle down with their expectations of what can be done with this project.

More pragmatically, this could be used to attain better performance on real N64 hardware. That's nice, given that the game does not always maintain its 30FPS target, and many mods suffer from performance problems(mostly due to loading textures into the paltry 4KB cache and the high latency the RAM has, despite the system advantage of using high-bandwidth cartridges...) - so this opens up new avenues for the incredibly developed modding scene. The microcode could be updated, but even more simply, you could just compile the game with newer tools and with actual optimisation flags this time (Thanks, Nintendo!) to see some gains.
And while I am not ruling out a port of the game to other platforms (primarily PC, but not limited to it!) it would require a lot of work, even if knowing exactly what you're doing with an understanding of the original code, hardware and your target platform.

TLDR: Porting is complicated, if you want to understand why you can read the whole post but at least N64 owners can benefit from better performance if someone wants to work on that.


----------



## Ecchi95 (Jul 11, 2019)

nim-ka said:


> lol good luck with graphics


The source code is available for many graphics plugins, including an OpenGL one. I will reference them.


----------



## nim-ka (Jul 11, 2019)

Some little comments:



TheMrIron2 said:


> any MIPS code (if any still exists - I haven't looked at the code out of respect until it's finished)


No assembly is left except that of a few audio functions whose C have not been made to match 1-1 with the assembly; for hacks and ports, this obviously doesn't matter



TheMrIron2 said:


> The microcode could be updated, but even more simply, you could just compile the game with newer tools and with actual optimisation flags this time (Thanks, Nintendo!) to see some gains.


Compiling SM64 with optimizations and using F3DEX/F3DEX2 microcode has been done and does allow for huge performance improvements. These have been implemented in the SM64 Randomizer


----------



## TheMrIron2 (Jul 11, 2019)

nim-ka said:


> No assembly is left except that of a few audio functions whose C have not been made to match 1-1 with the assembly; for hacks and ports, this obviously doesn't matter
> 
> Compiling SM64 with optimizations and using F3DEX/F3DEX2 microcode has been done and does allow for huge performance improvements. These have been implemented in the SM64 Randomizer



Thanks for the clarification, I appreciate it. I imagined that for a decompilation project, no MIPS code would remain as the end goal, but I couldn't be sure.

No surprise that newer microcode allows for massive performance improvements. I'm not sure how "huge" we're talking here - I could hardly imagine a 60FPS version of Mario 64 on real hardware - but newer microcode is stupidly more efficient than the original Fast3D, for sure. Factor 5 went ballistic with their own microcode instead of SGI's and fair play to them, they really pulled off some cool stuff. 

I'm fairly sure the game gets penalised harshly based on fillrate and bandwidth rather than geometry (perhaps that's more of a _general_ N64 issue); to my understanding, the game uses some Gouraud shading just to avoid loading new textures and wasting time with memory latency and the texture cache, and mod performance is heavily affected. Glad to see this improved at least. 

Has anyone tried to make a "high resolution" patch for Mario 64, in the vein of GoldenEye 64's 640x480 hack? I'm not aware of one, but if one exists, pardon my ignorance - while I've contributed to a N64 emulator myself and I understand the hardware, I'm quite out of touch with the scene.


----------



## Milenko (Jul 12, 2019)

Seeing if a device can run doom is so last year, my toaster can play Mario 64


----------



## CrashOveride (Jul 12, 2019)

>Has anyone tried to make a "high resolution" patch for Mario 64, in the vein of GoldenEye 64's 640x480 hack? I'm not aware of one, but if one exists, pardon my ignorance - while I've contributed to a N64 emulator myself and I understand the hardware, I'm quite out of touch with the scene.

SubDrag did a patch.... it lagged like hell.

>If it's available, it's public domain. It's what I live by.

This makes absolutely no sense in legal perspectives. That's like if I hack valve and steal the source to GoldSrc, then spread it around because the binary exists

Another example is including the SM64 rom with the Rom Manager. I mean it's publicly available right?


----------



## CrashOveride (Jul 12, 2019)

What kind of rebuttal is that? So if i get arrested for stealing that source, I'm gonna tell the cops I'm in the right because "I'm not a moralfag"


----------



## Ecchi95 (Jul 12, 2019)

CrashOveride said:


> What kind of rebuttal is that? So if i get arrested for stealing that source, I'm gonna tell the cops I'm in the right because "I'm not a moralfag"


You have to pick and choose what's viable. Can I cover my tracks? Can I not?


----------



## nim-ka (Jul 12, 2019)

Lol "I am above you because I don't have ethics and anyone who does is a fag"


----------



## mouthbreathe (Jul 12, 2019)

nim-ka said:


> Lol "I am above you because I don't have ethics and anyone who does is a fag"


Honestly, I'm with Ecchi95 on this, though his wording could be a bit better.
Morals and ethics, especially in regards to something as inconsequential as this, tends to stifle progress and, in some cases, outright prevent things from happening.


----------



## nim-ka (Jul 12, 2019)

mouthbreathe said:


> Honestly, I'm with Ecchi95 on this, though his wording could be a bit better.
> Morals and ethics, especially in regards to something as inconsequential as this, tends to stifle progress and, in some cases, outright prevent things from happening.


You know what else prevents things from happening? Working with an outdated codebase that doesn't let you do what you want lol


----------



## halo5307 (Jul 12, 2019)

CrashOveride said:


> What kind of rebuttal is that? So if i get arrested for stealing that source, I'm gonna tell the cops I'm in the right because "I'm not a moralfag"


You can see from my earlier replies with him that OP really isn't one for coherent discussion. He reads like a preteen that just discovered torrenting.



mouthbreathe said:


> Honestly, I'm with Ecchi95 on this, though his wording could be a bit better.
> Morals and ethics, especially in regards to something as inconsequential as this, tends to stifle progress and, in some cases, outright prevent things from happening.



I agree with you, but this doesn't mean flaunting your immoral lifestyle is proper. "Can I cover my tracks? Can I not?" almost makes it sound like he's getting off to the idea of willingly doing something wrong, lmao. Spare the dramatics, please.


----------



## mountainflaw (Jul 12, 2019)

Ecchi95 said:


> The source code is available for many graphics plugins, including an OpenGL one. I will reference them.


Good luck dealing with addresses :^)

--------------------- MERGED ---------------------------



TheMrIron2 said:


> I'm fairly sure the game gets penalised harshly based on fillrate and bandwidth rather than geometry (perhaps that's more of a _general_ N64 issue); to my understanding, the game uses some Gouraud shading just to avoid loading new textures and wasting time with memory latency and the texture cache, and mod performance is heavily affected. Glad to see this improved at least.


This is true.


----------



## Ecchi95 (Jul 12, 2019)

"PC Port of SM64 Game Logic" video is no longer available. Nintendo Ninjas got bad_boot!


----------



## CrashOveride (Jul 12, 2019)

Ecchi95 said:


> "PC Port of SM64 Game Logic" video is no longer available. Nintendo Ninjas got bad_boot!



the relentless publicty of the decomp didn't exactly help


----------



## nim-ka (Jul 12, 2019)

Ecchi95 said:


> "PC Port of SM64 Game Logic" video is no longer available. Nintendo Ninjas got bad_boot!


Actually, it seems bad_boot made it private pre-emptively.


----------



## CrashOveride (Jul 12, 2019)

nim-ka said:


> Actually, it seems bad_boot made it private pre-emptively.


 exactly my point, damage control


----------



## Deleted User (Jul 12, 2019)

FAST6191 said:


> Interesting development. Wonder if the speedrun folks will have any discoveries as a result of this.
> 
> Personally I would have been content with something that could compile (and was not just kicking lots as a straight binary array to be left as is) similar to some of the disassembles we have seen on older consoles but if people want to gild the lily then "you do you" and all that.


Maybe they can finally figure out that infamous tick tock clock glitch


----------



## Ecchi95 (Jul 12, 2019)

CrashOveride said:


> the relentless publicty of the decomp didn't exactly help


Don't think for a second that I'm not entertained.


----------



## CrashOveride (Jul 12, 2019)

Ecchi95 said:


> Don't think for a second that I'm not entertained.



get off your high horse


----------



## halo5307 (Jul 12, 2019)

Ecchi95 said:


> Don't think for a second that I'm not entertained.


What? Do you have a god complex? It would explain why you consistently come across as childish and rude. 

Like it or not, you contributed to that video getting privated. It shouldn't be entertaining, then again, you are the sole embodiment of a teenage 4chan user -- so what do I know?


----------



## Ecchi95 (Jul 12, 2019)

halo5307 said:


> What? Do you have a god complex? It would explain why you consistently come across as childish and rude.
> 
> Like it or not, you contributed to that video getting privated. It shouldn't be entertaining, then again, you are the sole embodiment of a teenage 4chan user -- so what do I know?


I registered to make waves with the decomp. I said so in my OP.


----------



## DrOctapu (Jul 12, 2019)

Ecchi95 said:


> Don't think for a second that I'm not entertained.


You seem pretty insufferable all around.

Interesting project though, wondering what'll come of it in the long-term. Kudos to the people working on it, I've tried to mess around with writing GBA homebrew and similar before and gotten frustrated with the spotty documentation. Cannot imagine working backwards on the N64, but it's a noble cause.


----------



## halo5307 (Jul 12, 2019)

Ecchi95 said:


> I registered to make waves with the decomp. I said so in my OP.


No shit, sherlock. I'm asking if you have a mental illness, or if your consistent rudeness is just part of your "lifestyle", as you don't live by an ethical or moral code.


----------



## Ecchi95 (Jul 12, 2019)

halo5307 said:


> No shit, sherlock. I'm asking if you have a mental illness, or if your consistent rudeness is just part of your "lifestyle", as you don't live by an ethical or moral code.


I'm just carrying out my agenda.

This is my main profile: https://myanimelist.net/profile/IpreferEcchi


----------



## halo5307 (Jul 12, 2019)

Good riddance. We should make a new thread so we stop gassing up the OP. I would love to learn more about the intricacies of the project, but this guy is a total narcissist who clearly thinks far too highly of himself.

Kudos to the mod team. This will be the last time I engage in this thread.


----------



## nim-ka (Jul 12, 2019)

If someone makes a new thread, please send it to me, otherwise I will continue to lurk here


----------



## Ecchi95 (Jul 12, 2019)

Files containing particular strings:

*    spawn_*

```
src/engine/behavior_script.c
src/engine/surface_load.c
src/game/area.c
src/game/behaviors/beta_boo_key.inc.c
src/game/behaviors/beta_chest.inc.c
src/game/behaviors/bird.inc.c
src/game/behaviors/blue_coin.inc.c
src/game/behaviors/bobomb.inc.c
src/game/behaviors/boo.inc.c
src/game/behaviors/boo_cage.inc.c
src/game/behaviors/bowser.inc.c
src/game/behaviors/bowser_bomb.inc.c
src/game/behaviors/bowser_key.inc.c
src/game/behaviors/breakable_box_small.inc.c
src/game/behaviors/bub.inc.c
src/game/behaviors/bullet_bill.inc.c
src/game/behaviors/bully.inc.c
src/game/behaviors/camera_lakitu.inc.c
src/game/behaviors/capswitch.inc.c
src/game/behaviors/celebration_star.inc.c
src/game/behaviors/chain_chomp.inc.c
src/game/behaviors/chuckya.inc.c
src/game/behaviors/cloud.inc.c
src/game/behaviors/coin.inc.c
src/game/behaviors/controllable_platform.inc.c
src/game/behaviors/corkbox.inc.c
src/game/behaviors/enemy_lakitu.inc.c
src/game/behaviors/exclamation_box.inc.c
src/game/behaviors/explosion.inc.c
src/game/behaviors/falling_pillar.inc.c
src/game/behaviors/fishing_boo.inc.c
src/game/behaviors/flame_mario.inc.c
src/game/behaviors/goomba.inc.c
src/game/behaviors/king_bobomb.inc.c
src/game/behaviors/klepto.inc.c
src/game/behaviors/koopa.inc.c
src/game/behaviors/koopa_shell.inc.c
src/game/behaviors/little_cage.inc.c
src/game/behaviors/mips.inc.c
src/game/behaviors/moneybag.inc.c
src/game/behaviors/monty_mole.inc.c
src/game/behaviors/moving_coin.inc.c
src/game/behaviors/mr_blizzard.inc.c
src/game/behaviors/mr_i.inc.c
src/game/behaviors/mushroom_1up.inc.c
src/game/behaviors/piranha_particles.inc.c
src/game/behaviors/piranha_plant.inc.c
src/game/behaviors/pound_explode.inc.c
src/game/behaviors/pyramid_top.inc.c
src/game/behaviors/racing_penguin.inc.c
src/game/behaviors/skeeter.inc.c
src/game/behaviors/snowman.inc.c
src/game/behaviors/sparkle_spawn_star.inc.c
src/game/behaviors/spawn_star.inc.c
src/game/behaviors/sushi.inc.c
src/game/behaviors/switch_hidden_objects.inc.c
src/game/behaviors/thi_top.inc.c
src/game/behaviors/treasure_chest.inc.c
src/game/behaviors/triplet_butterfly.inc.c
src/game/behaviors/tweester.inc.c
src/game/behaviors/water_bomb.inc.c
src/game/behaviors/water_mist_particle.inc.c
src/game/behaviors/water_objs.inc.c
src/game/behaviors/water_splash.inc.c
src/game/behaviors/whomp.inc.c
src/game/behaviors/wind_particle.inc.c
src/game/behavior_actions.c
src/game/debug.c
src/game/interaction.c
src/game/macro_special_objects.c
src/game/mario_actions_cutscene.c
src/game/object_helpers.c
src/game/object_list_processor.c
src/game/obj_behaviors.c
src/game/obj_behaviors_2.c
```

*water*

```
include/audio_defines.h
include/behavior_data.h
include/collision.inc
include/geo_commands.inc
include/macro_presets.h
include/macro_presets.inc
include/macro_preset_names.h
include/mario_animation_ids.h
include/model_ids.h
include/model_ids.inc
include/object_constants.h
include/object_fields.h
include/seq_ids.h
include/seq_ids.inc
include/sm64.h
include/special_presets.h
include/special_presets.inc
include/special_preset_names.h
include/types.h
src/audio/interface_2.c
src/engine/behavior_script.c
src/engine/surface_collision.c
src/engine/surface_collision.h
src/engine/surface_load.c
src/game/area.h
src/game/behaviors/beta_chest.inc.c
src/game/behaviors/beta_fish_splash_spawner.inc.c
src/game/behaviors/bub.inc.c
src/game/behaviors/bubble.inc.c
src/game/behaviors/corkbox.inc.c
src/game/behaviors/explosion.inc.c
src/game/behaviors/fish.inc.c
src/game/behaviors/floating_platform.inc.c
src/game/behaviors/fly_guy.inc.c
src/game/behaviors/heave_ho.inc.c
src/game/behaviors/hoot.inc.c
src/game/behaviors/klepto.inc.c
src/game/behaviors/koopa_shell.inc.c
src/game/behaviors/koopa_shell_underwater.inc.c
src/game/behaviors/manta_ray.inc.c
src/game/behaviors/mips.inc.c
src/game/behaviors/moat_drainer.inc.c
src/game/behaviors/monty_mole.inc.c
src/game/behaviors/skeeter.inc.c
src/game/behaviors/snowman.inc.c
src/game/behaviors/sushi.inc.c
src/game/behaviors/thi_top.inc.c
src/game/behaviors/treasure_chest.inc.c
src/game/behaviors/water_bomb.inc.c
src/game/behaviors/water_mist_particle.inc.c
src/game/behaviors/water_objs.inc.c
src/game/behaviors/water_pillar.inc.c
src/game/behaviors/water_ring.inc.c
src/game/behaviors/water_splash.inc.c
src/game/behaviors/water_wave.inc.c
src/game/behaviors/wdw_water_level.inc.c
src/game/behaviors/whirlpool.inc.c
src/game/behavior_actions.c
src/game/camera.c
src/game/camera.h
src/game/debug.c
src/game/envfx_snow.c
src/game/envfx_snow.h
src/game/interaction.c
src/game/interaction.h
src/game/level_select_menu.c
src/game/level_update.c
src/game/mario.c
src/game/mario_actions_airborne.c
src/game/mario_actions_automatic.c
src/game/mario_actions_cutscene.c
src/game/mario_actions_moving.c
src/game/mario_actions_object.c
src/game/mario_actions_stationary.c
src/game/mario_actions_submerged.c
src/game/mario_step.c
src/game/mario_step.h
src/game/moving_texture.c
src/game/object_helpers.c
src/game/object_helpers.h
src/game/object_list_processor.c
src/game/obj_behaviors.c
src/game/obj_behaviors.h
src/game/obj_behaviors_2.c
src/game/rendering_graph_node.c
src/game/room.c
src/game/room.h
src/game/segment2.h
src/game/shadow.c
src/game/shadow.h
src/game/skybox.c
src/game/sound_init.c
```

*bug*

```
include/audio_defines.h
include/behavior_data.h
include/config.h
include/macro_presets.h
include/macro_presets.inc
include/macro_preset_names.h
include/model_ids.h
include/model_ids.inc
include/object_fields.h
include/sm64.h
src/audio/interface_2.c
src/engine/surface_collision.c
src/engine/surface_collision.h
src/game/behaviors/beta_following_circling_obj.inc.c
src/game/behaviors/boo.inc.c
src/game/behaviors/bowser.inc.c
src/game/behaviors/chuckya.inc.c
src/game/behaviors/collide_particles.inc.c
src/game/behaviors/goomba.inc.c
src/game/behaviors/king_bobomb.inc.c
src/game/behaviors/lll_octagonal_rotating_mesh.inc.c
src/game/behaviors/scuttlebug.inc.c
src/game/behaviors/static_checkered_platform.inc.c
src/game/behaviors/tweester.inc.c
src/game/behaviors/ukiki_cage.inc.c
src/game/behaviors/walking_penguin.inc.c
src/game/behavior_actions.c
src/game/debug.c
src/game/debug.h
src/game/debug_course.h
src/game/display.c
src/game/game.c
src/game/level_select_menu.c
src/game/level_update.c
src/game/main.c
src/game/main.h
src/game/mario.c
src/game/mario_actions_cutscene.c
src/game/object_collision.c
src/game/object_helpers.c
src/game/object_list_processor.c
src/game/object_list_processor.h
src/game/obj_behaviors_2.c
src/game/profiler.c
src/game/rendering_graph_node.c
src/game/save_file.c
src/game/shadow.c
src/game/star_select.c
src/goddard/bad_declarations.h
src/goddard/draw_objects.c
src/goddard/dynlist_proc.c
src/goddard/gd_main.c
src/goddard/gd_memory.h
src/goddard/gd_types.h
src/goddard/mario_head_1.c
src/goddard/mario_head_1.h
src/goddard/mario_head_6.c
src/goddard/old_obj_fn.c
```

*test*

```
src/engine/level_script.c
src/game/camera.c
src/game/camera.h
src/game/debug.c
src/game/file_select.c
src/game/level_select_menu.c
src/game/macro_special_objects.c
src/game/mario_misc.c
src/game/spawn_sound.c
src/goddard/dynlists/dynlists.h
src/goddard/dynlists/dynlist_test_cube.c
src/goddard/gd_types.h
src/goddard/half_6.c
src/goddard/mario_head_6.c
src/goddard/mario_head_6.h
```

*beta*

```
include/behavior_data.h
include/macro_presets.h
include/macro_presets.inc
include/object_fields.h
include/special_presets.h
src/game/behaviors/beta_boo_key.inc.c
src/game/behaviors/beta_chest.inc.c
src/game/behaviors/beta_fish_splash_spawner.inc.c
src/game/behaviors/beta_following_circling_obj.inc.c
src/game/behaviors/beta_green_shell.inc.c
src/game/behaviors/beta_trampoline.inc.c
src/game/behaviors/fishing_boo.inc.c
src/game/behavior_actions.c
src/game/object_helpers.h
src/game/obj_behaviors.c
src/game/obj_behaviors.h
src/goddard/draw_objects.c
src/goddard/dynlist_proc.c
```

*gfx*

```
include/behavior_data.h
include/object_fields.h
include/types.h
src/game/behaviors/bowser.inc.c
src/game/behaviors/capswitch.inc.c
src/game/behaviors/corkbox.inc.c
src/game/behaviors/door_key.inc.c
src/game/display.c
src/game/display.h
src/game/envfx_bubbles.c
src/game/envfx_bubbles.h
src/game/envfx_snow.c
src/game/envfx_snow.h
src/game/file_select.c
src/game/file_select.h
src/game/game.c
src/game/game.h
src/game/geo_misc.c
src/game/hud.h
src/game/ingame_menu.c
src/game/intro_geo.c
src/game/intro_geo.h
src/game/level_geo.c
src/game/level_geo.h
src/game/main.c
src/game/mario_misc.c
src/game/mario_misc.h
src/game/memory.c
src/game/moving_texture.c
src/game/object_helpers.c
src/game/obj_behaviors.c
src/game/obj_behaviors_2.c
src/game/paintings.c
src/game/print.c
src/game/profiler.c
src/game/profiler.h
src/game/rendering_graph_node.c
src/game/screen_transition.c
src/game/segment2.h
src/game/segment7.h
src/game/shadow.c
src/game/shadow.h
src/game/skybox.c
src/game/skybox.h
src/game/star_select.c
src/goddard/gd_tex_dl.h
src/goddard/mario_head_6.c
```

*nintendo*

```
include/config.h
src/game/camera.c
src/game/display.c
src/game/game.c
src/game/level_update.c
src/game/object_helpers.c
```

*mtx*

```
src/engine/graph_node.c
src/engine/math_util.c
src/engine/math_util.h
src/game/hud.c
src/game/ingame_menu.c
src/game/intro_geo.c
src/game/level_geo.c
src/game/obj_behaviors.c
src/game/print.c
src/game/rendering_graph_node.c
src/game/skybox.c
src/goddard/draw_objects.c
src/goddard/dynlist_proc.c
src/goddard/gd_types.h
src/goddard/mario_head_1.c
src/goddard/mario_head_2.c
src/goddard/mario_head_6.c
```

*setsound*

```
include/audio_defines.h
src/audio/interface_2.c
src/audio/interface_2.h
src/game/behaviors/bbh_merry_go_round.inc.c
src/game/behaviors/beta_chest.inc.c
src/game/behaviors/blue_coin.inc.c
src/game/behaviors/boo.inc.c
src/game/behaviors/bowser.inc.c
src/game/behaviors/hidden_star.inc.c
src/game/behaviors/mushroom_1up.inc.c
src/game/behaviors/purple_switch.inc.c
src/game/behaviors/red_coin.inc.c
src/game/behaviors/sound_spawner.inc.c
src/game/behaviors/treasure_chest.inc.c
src/game/behaviors/tuxie.inc.c
src/game/behaviors/water_ring.inc.c
src/game/behaviors/yoshi.inc.c
src/game/camera.c
src/game/envfx_bubbles.c
src/game/file_select.c
src/game/ingame_menu.c
src/game/interaction.c
src/game/level_select_menu.c
src/game/level_update.c
src/game/mario.c
src/game/mario_actions_airborne.c
src/game/mario_actions_automatic.c
src/game/mario_actions_cutscene.c
src/game/mario_actions_moving.c
src/game/mario_actions_object.c
src/game/mario_actions_stationary.c
src/game/mario_actions_submerged.c
src/game/mario_misc.c
src/game/mario_step.c
src/game/obj_behaviors.c
src/game/obj_behaviors_2.c
src/game/sound_init.c
src/game/spawn_sound.c
src/game/star_select.c
```

*luigi*

```
include/model_ids.h
include/model_ids.inc
src/game/camera.c
src/game/mario.h
src/game/mario_misc.c
src/game/object_list_processor.c
src/game/object_list_processor.h
src/game/shadow.c
```

*vtx*

```
src/game/envfx_bubbles.c
src/game/envfx_snow.c
src/game/envfx_snow.h
src/game/geo_misc.c
src/game/geo_misc.h
src/game/moving_texture.c
src/game/paintings.c
src/game/screen_transition.c
src/game/shadow.c
src/game/skybox.c
src/goddard/draw_objects.c
src/goddard/dynlists/dynlists_mario_eyebrows_mustache.c
src/goddard/dynlists/dynlists_mario_eyes.c
src/goddard/dynlists/dynlist_mario_face.c
src/goddard/dynlist_proc.c
src/goddard/gd_main.c
src/goddard/gd_main.h
src/goddard/gd_types.h
src/goddard/half_6.c
src/goddard/mario_head_1.c
src/goddard/mario_head_1.h
src/goddard/mario_head_2.c
src/goddard/mario_head_3.c
src/goddard/mario_head_6.c
src/goddard/mario_head_6.h
src/goddard/skin_fns.c
```

*alloc*

```
include/geo_commands.inc
include/level_commands.inc
src/audio/dac.c
src/audio/dac.h
src/audio/dma.c
src/audio/interface_1.c
src/audio/interface_2.c
src/audio/something.c
src/engine/geo_layout.c
src/engine/graph_node.c
src/engine/level_script.c
src/engine/surface_load.c
src/engine/surface_load.h
src/game/behaviors/bowser.inc.c
src/game/behaviors/chain_chomp.inc.c
src/game/behaviors/wiggler.inc.c
src/game/camera.c
src/game/envfx_bubbles.c
src/game/envfx_snow.c
src/game/game.c
src/game/geo_misc.c
src/game/hud.c
src/game/ingame_menu.c
src/game/intro_geo.c
src/game/level_geo.c
src/game/mario_misc.c
src/game/memory.c
src/game/memory.h
src/game/moving_texture.c
src/game/object_helpers.c
src/game/object_list_processor.c
src/game/obj_behaviors.c
src/game/paintings.c
src/game/print.c
src/game/rendering_graph_node.c
src/game/screen_transition.c
src/game/shadow.c
src/game/skybox.c
src/game/spawn_object.c
src/goddard/dynlist_proc.c
src/goddard/gd_memory.c
src/goddard/gd_memory.h
src/goddard/half_6.c
src/goddard/mario_head_1.c
src/goddard/mario_head_3.c
src/goddard/mario_head_6.c
src/goddard/mario_head_6.h
src/goddard/profiler_utils.c
src/goddard/profiler_utils.h
```

*dl_*

```
include/geo_commands.inc
include/model_ids.h
include/model_ids.inc
src/game/envfx_bubbles.c
src/game/envfx_snow.c
src/game/file_select.c
src/game/file_select.h
src/game/geo_misc.c
src/game/hud.c
src/game/hud.h
src/game/ingame_menu.c
src/game/ingame_menu.h
src/game/intro_geo.c
src/game/moving_texture.c
src/game/paintings.c
src/game/print.c
src/game/screen_transition.c
src/game/segment2.h
src/game/segment7.h
src/game/shadow.c
src/game/skybox.c
src/game/star_select.c
src/goddard/draw_objects.c
src/goddard/draw_objects.h
src/goddard/half_6.c
src/goddard/mario_head_6.c
src/goddard/mario_head_6.h
```

*fuck*

```
src/game/camera.c
src/game/level_select_menu.c
```

*gdp*

```
src/game/area.c
src/game/display.c
src/game/envfx_bubbles.c
src/game/file_select.c
src/game/hud.c
src/game/ingame_menu.c
src/game/intro_geo.c
src/game/mario_misc.c
src/game/moving_texture.c
src/game/object_helpers.c
src/game/obj_behaviors.c
src/game/paintings.c
src/game/print.c
src/game/profiler.c
src/game/rendering_graph_node.c
src/game/screen_transition.c
src/game/skybox.c
src/game/star_select.c
src/goddard/mario_head_6.c
```

*gsp*

```
sm64/src/game/area.c
sm64/src/game/behaviors/bowser.inc.c
sm64/src/game/display.c
sm64/src/game/envfx_bubbles.c
sm64/src/game/envfx_snow.c
sm64/src/game/file_select.c
sm64/src/game/geo_misc.c
sm64/src/game/hud.c
sm64/src/game/ingame_menu.c
sm64/src/game/intro_geo.c
sm64/src/game/level_geo.c
sm64/src/game/main.c
sm64/src/game/main.h
sm64/src/game/mario_misc.c
sm64/src/game/moving_texture.c
sm64/src/game/object_helpers.c
sm64/src/game/obj_behaviors.c
sm64/src/game/paintings.c
sm64/src/game/print.c
sm64/src/game/rendering_graph_node.c
sm64/src/game/screen_transition.c
sm64/src/game/shadow.c
sm64/src/game/skybox.c
sm64/src/game/star_select.c
sm64/src/goddard/mario_head_6.c
```

*gssp*

```
src/goddard/mario_head_6.c
```

*make_v*

```
src/game/area.c
src/game/display.c
src/game/display.h
src/game/geo_misc.c (vertex)
src/game/geo_misc.h (vertex)
src/game/moving_texture.c (vertex)
src/game/paintings.c (vertex)
src/game/rendering_graph_node.c
src/game/screen_transition.c (vertex)
src/game/shadow.c (vertex)
src/game/skybox.c (vertex)
src/goddard/draw_objects.c
src/goddard/dynlist_proc.c (vertex)
src/goddard/half_6.c (vertex)
src/goddard/half_6.h (vertex)
src/goddard/mario_head_1.c
src/goddard/mario_head_1.h
src/goddard/mario_head_6.c
```

*weird*

```
src/audio/something.c
src/game/behaviors/corkbox.inc.c
src/game/behaviors/flamethrower.inc.c
src/game/behaviors/flame_mario.inc.c
src/game/behaviors/spiny.inc.c
src/game/behaviors/ukiki_cage.inc.c
src/game/behaviors/water_splash.inc.c
src/game/mario_misc.c
src/goddard/gd_types.h
src/goddard/mario_head_6.c
```

*wtf*

```
src/game/debug.c
```


----------



## nim-ka (Jul 12, 2019)

I really hate the use of this outdated codebase also because names like beta_green_shell are completely wrong


----------



## Erokaution (Jul 12, 2019)

Made a account real quick to jump in on this conversation.
I find it unfortunate that I live in the universe where SM64 got decompiled before OOT, I would be all over a OOT decompilation and already thinking of large projects to start. Still, this is absolutely amazing. It's really easy and fun to work with.
I've had the displeasure of spending years hacking various games, and I've spent too much time looking at and trying to write assembly. Really not fun stuff, but it opens up a ton of doors.
But now, with this, SM64 hacks will be far easier to create, and you can do so much more with it in a fraction of the time.
I'm excited for the future of SM64 hacking, as well as maybe some smaller projects of my own.

I picked up the decomp when it was posted elsewhere a few weeks ago, and I spent a few days fiddling with it. As a challenge to myself, I wanted to see how long it would take me to implement a rudimentary inventory system into the pause menu, as well as changeable equipment you can toggle.
So in a single day, I did so.

When you killed 1 and 5 Goombas, 'icons' would unlock on the pause menu which you could put your cursor over and enable.
First one altered the belly slide mechanics a bit, the second one made mario giant.

It was extremely ugly, both in code and on screen, but I wanted to see how fast I could make it at all to begin with.
For the record, it would normally take me maybe a week or two without the source, mostly because I'd have to spend a bunch of time trying to find routines and how to modify them without breaking everything.


Again, this opens up so many doors for the SM64 hacking community. I'm excited to see what comes out of it in the years to come.
I've been slowly working on a model importer and level editor for the source, but I expect someone else might get it done faster than I am since I'm juggling multiple other projects at the moment.


----------



## nim-ka (Jul 12, 2019)

Erokaution said:


> I've been slowly working on a model importer and level editor for the source, but I expect someone else might get it done faster than I am since I'm juggling multiple other projects at the moment.


Those already exist, for the up-to-date code...


----------



## Erokaution (Jul 12, 2019)

nim-ka said:


> Those already exist, for the up-to-date code...


Are they out somewhere already? I think the current code that I picked up a few weeks ago is still the only one public, right? Or am I misunderstanding something?

In all honesty, I've seen plenty of people who work with roms up and drop projects, usually due to either loss of motivation or drama. I'm not going to hold my breath for a final release for the codebase when the one that's currently out is more than enough for standard rom modifications. So while I'm aware the people who worked on the decomp have a few tools of their own, I don't expect it to be released soon enough for it to truly matter.

That said, I forgot where, but I did see a level viewer for the decomp on github somewhere, but it wasn't anywhere near usable for anything practical.
Which is why I'm working on one of my own- to take matters into my own hands since I'm impatient and don't hold too much faith in people. Nothing against them obviously, but just in case.


----------



## minestory (Jul 12, 2019)

i'm trying to port it to the switch


----------



## nim-ka (Jul 12, 2019)

Erokaution said:


> Which is why I'm working on one of my own- to take matters into my own hands since I'm impatient and don't hold too much faith in people. Nothing against them obviously, but just in case.


See, that's cool and all, except when the full release comes out (that's a when not an if) with all the new function names, documentation, file names, PAL support, etc., it'll be a huge pain to update your project. (Can tell you this from experience when we did this for the Randomizer; it took *forever* even with multiple people working on it.)


----------



## Erokaution (Jul 12, 2019)

nim-ka said:


> See, that's cool and all, except when the full release comes out (that's a when not an if) with all the new function names, documentation, file names, PAL support, etc., it'll be a huge pain to update your project. (Can tell you this from experience when we did this for the Randomizer; it took *forever* even with multiple people working on it.)


Eh, I'll take the risk.


----------



## Magnus87 (Jul 12, 2019)

Super 64 Maker (?)


----------



## nim-ka (Jul 12, 2019)

Magnus87 said:


> Super 64 Maker (?)


Lol why does everyone ask about making Super Mario 64 Maker? it's such a random idea, and it already exists!


----------



## mountainflaw (Jul 12, 2019)

Erokaution said:


> Made a account real quick to jump in on this conversation.
> I find it unfortunate that I live in the universe where SM64 got decompiled before OOT, I would be all over a OOT decompilation and already thinking of large projects to start. Still, this is absolutely amazing. It's really easy and fun to work with.
> I've had the displeasure of spending years hacking various games, and I've spent too much time looking at and trying to write assembly. Really not fun stuff, but it opens up a ton of doors.
> But now, with this, SM64 hacks will be far easier to create, and you can do so much more with it in a fraction of the time.
> ...




https://github.com/mountainflaw/modconv_2

This bad boy supports:
1.) Fast3D and Fast3DEX
2.) Adjusting lighting colors
3.) Toggling geometry modes from Blender
4.) Mirrored and clamped UVs
5.) The collision format, can also select types in Blender.
6.) Fog
7.) Transparency

It works with all modeling programs, and uses material names to select collision surfaces, geometry modes, mirroring, etc.


----------



## Erokaution (Jul 12, 2019)

mountainflaw said:


> This bad boy supports:
> 1.) Fast3D and Fast3DEX
> 2.) Adjusting lighting colors
> 3.) Toggling geometry modes from Blender
> ...


Oh hey, nice. Thanks for posting this.
Now we only need a level editor to make adding/editing objects/actors in levels less of a pain in the butt.
Takes some of my workload off at least.


----------



## Ecchi95 (Jul 13, 2019)

https://en.wikipedia.org/wiki/List_...rce_code#Games_with_reconstructed_source_code

We Wikipedia now.


----------



## MurraySkull (Jul 15, 2019)

Two questions:

1. How do I compile this?
2. What do I need to change so Bowser appears normal in the final battle, as on the DS?


----------



## Ecchi95 (Jul 15, 2019)

MurraySkull said:


> Two questions:
> 
> 1. How do I compile this?
> 2. What do I need to change so Bowser appears normal in the final battle, as on the DS?


*Linux*
1] Install the following packages:


make
git
binutils-mips-linux-gnu (>= 2.27)
python3
build-essential
pkg-config
zlib1g-dev
libglib2.0-dev
libpixman-1-dev
libcapstone3
2] Clone https://github.com/camthesaxman/qemu-irix to somewhere and follow its install instructions in the README.

2b] Optionally, grab the prebuilt qemu-irix from the Releases section.

3] Take the executable "qemu-irix" in irix-linux-user and put it somewhere where you will define an environment variable to it.

4] Define "QEMU_IRIX" in your bashrc to point to this qemu-irix executable.

5] After setting this repository up, run make to build the ROM. Make sure your path is not too long or else this process will error, as the emulated IDO compiler cannot handle paths longer than 255 characters.

*Windows*
For Windows, install WSL and a distro of your choice and follow the Linux guide.





*And for Bowser:*
*In src/game/behaviors/bowser.inc.c get rid of this, I believe:*


```
if(sp24->oUnk1B2 != 0)
       {
           gSPClearGeometryMode(sp28++, G_LIGHTING);
       }
```


----------



## BiggieCheese (Jul 15, 2019)

I can’t wait to see if source ports could be built from this in the coming years; imagine if there could be a port that would allow you to load romhacks in a similar way to how DOOM source ports allow you to run homemade WADs over the base game(s) IWAD file


----------



## eyeliner (Jul 15, 2019)

ROMHacks?! Begone with that!

I want total conversions! New games made by talented individuals using the engine for devious purposes.


----------



## OkazakiTheOtaku (Jul 15, 2019)

If you recompile this without changing any code, does the output rom's hash match any known real dump?


----------



## Ecchi95 (Jul 16, 2019)

OkazakiTheOtaku said:


> If you recompile this without changing any code, does the output rom's hash match any known real dump?


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


----------



## MurraySkull (Jul 16, 2019)

Is it possible to recompile with Cygwin? I have Windows 7, and thus can't use WSL.


----------



## Ecchi95 (Jul 16, 2019)

MurraySkull said:


> *Is it possible to recompile with Cygwin?* I have Windows 7, and thus can't use WSL.


Nope.

I might try to write my own compiler for this for Windows.


----------



## SM64-X1 (Jul 16, 2019)

.


----------



## Nemisbeast (Jul 16, 2019)

Why was this leaked? Great idea, let's piss off the N64 dev community, and have them buckle down and just not fuck with any public releases.

Anyways, regardless of whether they finish it or not, it's only a matter of time before it's finished considered what's been leaked, so they might as well finish it and hope that Nintendo doesn't come along with a water hose and a tub of icy-hot.

Ecchi, speaking from the things I've witnessed throughout the years, the majority of people that get on forums and post in such angst and seemingly uninformed manner whilst speaking with a sense of idealistic grandeur do not typically get jack shit done and their "projects" usually end up never making any meaningful progress.

Then again, I could be wrong, I seem to remember a rather punchable guy in the DC scene and came out with a product in which he acted a lot like you in the beginning, and most of us had wanted to strangle him.


----------



## Ecchi95 (Jul 16, 2019)

Nemisbeast said:


> Why was this leaked? Great idea, let's piss off the N64 dev community, and have them buckle down and just not fuck with any public releases.
> 
> Anyways, regardless of whether they finish it or not, it's only a matter of time before it's finished considered what's been leaked, so they might as well finish it and hope that Nintendo doesn't come along with a water hose and a tub of icy-hot.
> 
> ...


It is finished. It compiles an IDENTICAL ROM. Any extra labeling can be done by people working with it. The "N64 dev community" is no longer needed. (Also got every single 64DD game dumped, so they're really irrelevant now.)

It's in the hands of the general public now.


----------



## JoshDuMan (Jul 16, 2019)

Ecchi95 said:


> It is finished. It compiles an IDENTICAL ROM. Any extra labeling can be done by people working with it. The "N64 dev community" is no longer needed. (Also got every single 64DD game dumped, so they're really irrelevant now.)
> 
> It's in the hands of the general public now.


This is so laughable that I made an account just to point it out.

This same logic says that you could very well have just done the decomping work yourself and the "community" is still no longer needed. A community to do this work is no more needed than before- and yet, a source code matching or non-matching didn't exist to this point.

You've been talking like you've somehow achieved something so far with this work- I really don't understand why you've been so rude and arrogant with absolutely no achievement in regards to this whatsoever.


----------



## mountainflaw (Jul 16, 2019)

Ecchi95 said:


> It is finished. It compiles an IDENTICAL ROM. Any extra labeling can be done by people working with it. The "N64 dev community" is no longer needed. (Also got every single 64DD game dumped, so they're really irrelevant now.)
> 
> It's in the hands of the general public now.


It's not finished. The real version has EU support now, along with much better documentation.


----------



## Nemisbeast (Jul 16, 2019)

Ecchi95 said:


> It is finished. It compiles an IDENTICAL ROM. Any extra labeling can be done by people working with it. The "N64 dev community" is no longer needed. (Also got every single 64DD game dumped, so they're really irrelevant now.)
> 
> It's in the hands of the general public now.



Look into the progress the N64 homebrew community has made over the last several years; you act like games being dumped, and being able to compile an identical ROM for a single game is the nail in the coffin for the developers out there making this possible.

You have literally no idea what you've been speaking on, and there's a lot more than can be done with homebrew, custom versions of games using their source codes for Mario 64 AND other games that are to be de-compiled.

You're not relevant to the N64 development community, and you don't get to decide they're no longer needed; stop trolling and flaunting your arrogance like you're the one that accomplished something. You have such a narrow range of vision in regards of being able to perceive the usefulness of the N64 homebrew community if you honestly believe ROM dumps makes them irrelevant; nope, that only opens up more possibilities and more things for them to pursue.

Go hang out in #n64dev and report back on how long it takes for them to ban you after they get sick of your BS.

Get real, take this trolling nonsense somewhere else.


----------



## Ecchi95 (Jul 17, 2019)

@JoshDuMan I take what I can get and I give my assessment of it. Then I do things with it later after I've spoken my mind on it.
@Nemisbeast I don't want to be part of the "N64 development community." I don't need to have a "prestigious" title. I'm an individual with individual wants and individual opinions. I do what I want.



mountainflaw said:


> It's not finished. The real version has EU support now, along with much better documentation.


I don't care about EU support and I'm making my own documentation.


----------



## FAST6191 (Jul 17, 2019)

Ecchi95 said:


> @JoshDuMan I take what I can get and I give my assessment of it. Then I do things with it later after I've spoken my mind on it.
> @Nemisbeast I don't want to be part of the "N64 development community." I don't need to have a "prestigious" title. I'm an individual with individual wants and individual opinions. I do what I want.
> 
> 
> I don't care about EU support and I'm making my own documentation.


Some might ask why the redundancy if it would otherwise be a matter of waiting a few months.

There are certainly some cool things which can be done as is, and some things that can be far better understood about the game but if it is as they claim you are doing a whole lot of work which will likely be rendered obsolete in a short while, and if they have already gone to the effort of creating a compilable work this is not likely to be some abstract "3 months away and always will be" type scenario we so often encounter in these sorts of circles.


----------



## Ecchi95 (Jul 17, 2019)

FAST6191 said:


> Some might ask why the redundancy if it would otherwise be a matter of waiting a few months.
> 
> There are certainly some cool things which can be done as is, and some things that can be far better understood about the game but if it is as they claim you are doing a whole lot of work which will likely be rendered obsolete in a short while, and if they have already gone to the effort of creating a compilable work this is not likely to be some abstract "3 months away and always will be" type scenario we so often encounter in these sorts of circles.


Because some people want to get cracking with it immediately.

I'm only giving people an attitude because they gave me an attitude. How stupid is it to moan about being given a head start with something?


----------



## FAST6191 (Jul 17, 2019)

Ecchi95 said:


> Because some people want to get cracking with it immediately.
> 
> I'm only giving people an attitude because they gave me an attitude. How stupid is it to moan about being given a head start with something?



There are various quotes about the enthusiasm of the young, and things like "work smarter, not harder", something I have doubtless been guilty of myself at times.

Also to be fair you are operating in a manner that is likely to rub most of the ROM hacking, game fiddling, emulator fiddling and such crowd the wrong way a bit -- the bit about public domain probably being the most overt but in general most people I meet doing this sort of thing are all about pulling things apart and having a bit of fun where you seem to be taking a rather different approach, and said approaches are somewhat dubious as far as leading to results in a reasonable amount of time. Here it is not even like they are being cagey, intractable or making things harder for dubious ethical reasons either. Also it is not really a head start if you almost have to scrap it and start over, or have that as a viable option.


----------



## Ecchi95 (Jul 17, 2019)

FAST6191 said:


> There are various quotes about the enthusiasm of the young, and things like "work smarter, not harder", something I have doubtless been guilty of myself at times.
> 
> Also to be fair you are operating in a manner that is likely to rub most of the ROM hacking, game fiddling, emulator fiddling and such crowd the wrong way a bit -- the bit about public domain probably being the most overt but in general most people I meet doing this sort of thing are all about pulling things apart and having a bit of fun where you seem to be taking a rather different approach, and said approaches are somewhat dubious as far as leading to results in a reasonable amount of time. Here it is not even like they are being cagey, intractable or making things harder for dubious ethical reasons either. Also it is not really a head start if you almost have to scrap it and start over, or have that as a viable option.


If you're someone like me, you want to tailor something to your needs and have no use for many of the things that the "proper" release offers.

And I stand by my public domain spat. If something is out there, it is effectively yours if you use it smartly.


----------



## Nemisbeast (Jul 17, 2019)

Ecchi95 said:


> If you're someone like me, you want to tailor something to your needs and have no use for many of the things that the "proper" release offers.
> 
> And I stand by my public domain spat. If something is out there, it is effectively yours if you use it smartly.



So, as long as you're smart about it, technically, pirating isn't pirating since it's effectively yours, I mean, being out there and all, yeah?


----------



## Ecchi95 (Jul 17, 2019)

Nemisbeast said:


> So, as long as you're smart about it, technically, pirating isn't pirating since it's effectively yours, I mean, being out there and all, yeah?


That's exactly what I'm saying. I don't give a shit if I'm pirating something if I have a use for it, otherwise I wouldn't be pirating it.


----------



## mountainflaw (Jul 17, 2019)

Ecchi95 said:


> Nope.
> 
> I might try to write my own compiler for this for Windows.



Yes, waste your time writing a compiler which would be worse than the ancient IRIX one the game originally used.



Ecchi95 said:


> @JoshDuMan I take what I can get and I give my assessment of it. Then I do things with it later after I've spoken my mind on it.
> @Nemisbeast I don't want to be part of the "N64 development community." I don't need to have a "prestigious" title. I'm an individual with individual wants and individual opinions. I do what I want.
> 
> 
> I don't care about EU support and I'm making my own documentation.



LOL, I'd love to see you document the audio system, or graph nodes.

Oh, you can have fun with camera too.


----------



## Ericthegreat (Jul 17, 2019)

Interesting I thought this happened a long time ago... "Every single function was rewritten by hand" What does this mean, because technically this would mean probably some conversions were off.


----------



## Ecchi95 (Jul 17, 2019)

mountainflaw said:


> Yes, waste your time writing a compiler which would be worse than the ancient IRIX one the game originally used.
> 
> LOL, I'd love to see you document the audio system, or graph nodes.
> 
> Oh, you can have fun with camera too.


I will "waste my time" writing a compiler to stick it to you. People shouldn't be forced to use Linux and Windows 7 users can't even use WSL.

I will document those things, also to stick it to you.


----------



## CrashOveride (Jul 17, 2019)

Ecchi95 said:


> I will "waste my time" writing a compiler to stick it to you. People shouldn't be forced to use Linux and Windows 7 users can't even use WSL.
> 
> I will document those things, also to stick it to you.



Nice spiteful bullshit 

Considering your annoying attitude you'll probably be ignored anyway


----------



## mountainflaw (Jul 17, 2019)

Ecchi95 said:


> I will "waste my time" writing a compiler to stick it to you. People shouldn't be forced to use Linux and Windows 7 users can't even use WSL.
> 
> I will document those things, also to stick it to you.



All I have to say is "good luck" judging by your N64 "emulator"


----------



## Ecchi95 (Jul 17, 2019)

mountainflaw said:


> All I have to say is "good luck" judging by your N64 "emulator"


My emulator emulates the bare minimum of the CPU and the peripheral interface to successfully do the first DMA transfer for a game. I'm satisfied with that for now.

Compilers, especially ones with no optimizations, are easier than an emulator.


----------



## mountainflaw (Jul 17, 2019)

I'm not sure why'd you waste your time writing a compiler when N64Chain works just fine.


----------



## Ecchi95 (Jul 17, 2019)

mountainflaw said:


> I'm not sure why'd you waste your time writing a compiler when N64Chain works just fine.


Because it doesn't use IDO?

I'm making a "poor man's" IDO.


----------



## CrashOveride (Jul 17, 2019)

Ecchi95 said:


> Because it doesn't use IDO?
> 
> I'm making a "poor man's" IDO.



Even though it compiles with GCC, which IS n64chain?? https://github.com/tj90241/n64chain


----------



## mountainflaw (Jul 17, 2019)

Why would you gimp urself with IDO garbage


----------



## Ecchi95 (Jul 17, 2019)

@mountainflaw I'm aiming literally for a Super Mario 64 compiler. Not something reusable.



CrashOveride said:


> Even though it compiles with GCC, which IS n64chain?? https://github.com/tj90241/n64chain


GCC != IDO. Mine will compile an identical ROM like IDO.


----------



## CrashOveride (Jul 17, 2019)

Ecchi95 said:


> @mountainflaw I'm aiming literally for a Super Mario 64 compiler. Not something reusable.
> 
> 
> GCC != IDO. Mine will compile an identical ROM like IDO.



so you seriously think that you can just recreate IDO? are you going to decompile it or something


----------



## Ecchi95 (Jul 17, 2019)

CrashOveride said:


> so you seriously think that you can just recreate IDO? are you going to decompile it or something


I don't have to decompile it. I can identify where the binary data is in the ROM, compare it to the source code, and figure out the logic.


----------



## JoshDuMan (Jul 17, 2019)

So let me get this straight, you are going to:
* Document the rest of the code, much of which is some of the more complicated bits. (And a decent chunk of which is labelled privately)
* Make your own compiler that perfectly emulates a 20 year old software.

And yet, when things are offered from the team working on this you've just directly insulted them instead.

PAL support? Who cares! It's not like we have official debug support, multi-language support, and improved graphics from it.

mountainflaw releases something to allow level imports? Fuck 'em! We can do that.

Surely that compiler set-up that took literal months to work out was put together by a bunch of idiots.

And yet, when you're 100 hours into labeling a camera system in an old game by yourself, perhaps you will realize how foolish it is to rest your laurels on something you haven't completed while the people who put it together are sitting around laughing at this thread.


----------



## Deleted User (Jul 17, 2019)

OP is a complete pervert and narcissist? Who would have thunk it?

Insulting the very people who have been working on this and providing support is nothing short of pure stupidity. You deserve every bit of ridicule you get in this thread for being an utter brat who's too self-absorbed to accept any form of help.

Good luck to the team working on this whole thing. Hopefully it'll lead to greater things yet to come.


----------



## Ecchi95 (Jul 17, 2019)

@JoshDuMan Yes, I'm going to do it, and do it my way.



kikongokiller said:


> *OP is a complete pervert* and narcissist? Who would have thunk it?


https://myanimelist.net/profile/IpreferEcchi


----------



## Retro_Mod_Gamer (Jul 17, 2019)

I'm super fascinated by this.


----------



## MurraySkull (Jul 17, 2019)

Ran into a problem trying to compile:


----------



## JoshDuMan (Jul 17, 2019)

MurraySkull said:


> Ran into a problem trying to compile:


Do you have qemu-irix set up? You've gotta grab it from the GitHub and set its path.


----------



## MurraySkull (Jul 17, 2019)

JoshDuMan said:


> Do you have qemu-irix set up? You've gotta grab it from the GitHub and set its path.


Yes, I have qemu-irix, and have added it to .bashrc


----------



## The_Free_Real_Estate (Jul 17, 2019)

Ecchi95 said:


> It is finished. It compiles an IDENTICAL ROM. Any extra labeling can be done by people working with it. The "N64 dev community" is no longer needed. (Also got every single 64DD game dumped, so they're really irrelevant now.)
> 
> It's in the hands of the general public now.


Please stop embarrassing yourself on the internet. You have said that you would make:
an N64 emulator
a MIPS compiler
100% finished decompilation
and that the """""The "N64 dev community" is no longer needed."""" In reality you have done _nothing_. Nothing but compile the game using IDO.
You will be basing anything developed on this code base on an outdated, incomplete leak.


----------



## Ecchi95 (Jul 17, 2019)

The_Free_Real_Estate said:


> Please stop embarrassing yourself on the internet. You have said that you would make:
> an N64 emulator
> a MIPS compiler
> 100% finished decompilation
> ...


I thought that to embarrass yourself you have to be /embarrassed/.

I'm having the time of my life. I disseminated the leak. It's on multiple subreddits and multiple forums. I have 100k hits on this thread. I've established myself in non-gaming communities and go here for boredom relief during low activity in those places.


----------



## The_Free_Real_Estate (Jul 17, 2019)

Ecchi95 said:


> I thought that to embarrass yourself you have to be /embarrassed/.
> 
> I'm having the time of my life. I disseminated the leak. It's on multiple subreddits and multiple forums. I have 100k hits on this thread. I've established myself in non-gaming communities and go here for boredom relief during low activity in those places.


Off of our backs? You have no morals. You are going to take somebody else's work and try to take credit for it. What is wrong with you?

It won't matter anyway. I don't think you will be able to finish this. When the real decomp, with its extensions and fixes comes out, it will be leagues better than any leak effort. But that won't matter, because your 15 minutes of fame for propagating this leak is going to run out soon.


----------



## Harumyne (Jul 17, 2019)

For the love of God, someone fix that awful camera please!!!


----------



## Ecchi95 (Jul 17, 2019)

/nope


----------



## The_Free_Real_Estate (Jul 17, 2019)

Ecchi95 said:


> I have a brother-in-law who appreciates the leak as much as I do and the rest of the internet that's not the hardasses on GBAtemp.


Enjoying something doesn't make it any less of a characterless, disgusting thing to do. The public doesn't know about the dweeb who gave them this software. Doing this does not make you any more respected. They really could not care. Come back to me when you've made that N64 emulator


----------



## BridgetX (Jul 17, 2019)

Hello everyone, so I'm running into a problem while compiling this, if anyone can help me out here i would really appreciate it.


----------



## uyjulian (Jul 17, 2019)

BridgetX said:


> Hello everyone, so I'm running into a problem while compiling this, if anyone can help me out here i would really appreciate it.View attachment 173331


That screenshot doesn't help.


----------



## BridgetX (Jul 17, 2019)

uyjulian said:


> That screenshot doesn't help.


what other specifications do you want?


----------



## uyjulian (Jul 17, 2019)

BridgetX said:


> what other specifications do you want?


the entire terminal output


----------



## BridgetX (Jul 17, 2019)

uyjulian said:


> the entire terminal output


for "make" the output is simply

/home/bridget/Qemu/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
make: *** [Makefile:400: build/us/src/engine/surface_collision.o] Error 1

for "make -d" the output is in the text file attached since it's really long.


----------



## mountainflaw (Jul 17, 2019)

Elemi said:


> For the love of God, someone fix that awful camera please!!!


The camera is fine smh

--------------------- MERGED ---------------------------



BridgetX said:


> for "make" the output is simply
> 
> /home/bridget/Qemu/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
> make: *** [Makefile:400: build/us/src/engine/surface_collision.o] Error 1
> ...



What is your bashrc? Also dumb question: But are you using WSL/Linux?


----------



## BridgetX (Jul 17, 2019)

mountainflaw said:


> The camera is fine smh
> 
> --------------------- MERGED ---------------------------
> 
> ...


I'm running Linux (Debian 10), and the contents of my bashrc are in the attached file


----------



## HE1NZ (Jul 18, 2019)

Will this make 60 fps version possible?


----------



## nullpointer128 (Jul 18, 2019)

HE1NZ said:


> Will this make 60 fps version possible?


Should be, however it would take a lot of work updating the timings.


----------



## nullpointer128 (Jul 18, 2019)

Ecchi95 said:


> I don't give a shit. I'm a socialist. Reverse-engineering work product belongs to everyone.


Github?


----------



## MurraySkull (Jul 18, 2019)

Well, I finally got it working.














"Ha-ha-ha-ha-ha-ha-haaaa!"

I have attempted to upload an IPS patch at Romhacking.net.


----------



## phreaksho (Jul 18, 2019)

So... What does this actually mean? like what could this lead to?


----------



## Jayro (Jul 18, 2019)

This is incredible!


----------



## FAST6191 (Jul 18, 2019)

MurraySkull said:


> Well, I finally got it working.
> "Ha-ha-ha-ha-ha-ha-haaaa!"
> 
> I have attempted to upload an IPS patch at Romhacking.net.



Not sure what that is supposed to showcase (been too long since I last did SM64) but be careful with recompiles and IPS -- if the compiler generates something with different offsets or you do a few changes of variables it will appear as very different to IPS and you would then include a whole chunk of Nintendo code with it, which would be less than ideal. Xdelta might be a better plan but even then I have seen very subtle tweaks have massive changes across a binary before.


----------



## eyeliner (Jul 18, 2019)

MurraySkull said:


> Well, I finally got it working.
> 
> "Ha-ha-ha-ha-ha-ha-haaaa!"
> 
> I have attempted to upload an IPS patch at Romhacking.net.


Explain yourself for us dumb people. As in: "This is what I did, yo..."

Please.


----------



## TheGag96 (Jul 21, 2019)

mountainflaw said:


> *snip*
> What is your bashrc? Also dumb question: But are you using WSL/Linux?



I appear to be getting the same compiler error as him... I'm on Arch Linux x64 - had to install mips64-elf-binutils off the AUR (hoping that's right lol). For some reason I had to chmod +x the cc executable mentioned in this error.


```
In file included from include/ultra64.h:23,
                 from src/engine/surface_collision.c:1:
include/PR/os_libc.h:82:17: warning: mismatch in argument 3 type of built-in function ‘bcopy’; expected ‘unsigned int’ [-Wbuiltin-declaration-mismatch]
   82 | extern void     bcopy(const void *, void *, int);
      |                 ^~~~~
include/PR/os_libc.h:83:17: warning: mismatch in argument 3 type of built-in function ‘bcmp’; expected ‘unsigned int’ [-Wbuiltin-declaration-mismatch]
   83 | extern int      bcmp(const void *, const void *, int);
      |                 ^~~~
include/PR/os_libc.h:84:17: warning: mismatch in argument 2 type of built-in function ‘bzero’; expected ‘unsigned int’ [-Wbuiltin-declaration-mismatch]
   84 | extern void     bzero(void *, int);
      |                 ^~~~~
/home/grayson/Apps/qemu-irix/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
make: *** [Makefile:400: build/us/src/engine/surface_collision.o] Error 1
```


----------



## bunny_wabbit (Jul 21, 2019)

I'm going to show much knowledge of machine code I don't have, but does mean that it would be theoretically possible to install it on PC and play it without the need for an emulator?


----------



## FAST6191 (Jul 21, 2019)

bunny_wabbit said:


> I'm going to show much knowledge of machine code I don't have, but does mean that it would be theoretically possible to install it on PC and play it without the need for an emulator?


While C has often been called portable assembler I don't think we have seen anybody manage to slap a modern PC compiler hard enough that it spits out a workable program just yet (even a slow version).

Eventually though with some code tweaking then yes you will probably get a super_mario_64.exe and click on it and experience the joys of Mario 64 on a PC without emulation, remote play, simulation or some kind of quasi recreation and asset rip thing that some not quite emulators go in for. 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.


----------



## nullpointer128 (Jul 22, 2019)

bunny_wabbit said:


> I'm going to show much knowledge of machine code I don't have, but does mean that it would be theoretically possible to install it on PC and play it without the need for an emulator?



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. This is just for getting a "vanilla" SM64 experience (e.g. no modified graphics).

If we'd want to overhaul the graphics, we would not write an implementation of the APIs, but we would have to completely rework the rendering logic for SM64, because it currently relies heavily on rendering n64 display lists and SPTasks. And there are 451 gSP calls in the code, and over 936 references to display lists.

This doesn't even include porting all the code so it conforms to modern C compiler requirements. So it's a big undertaking, but given another couple years and community teamwork, it will be done.


----------



## mountainflaw (Jul 24, 2019)

HE1NZ said:


> 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 (Jul 26, 2019)

Ericthegreat said:


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





Ecchi95 said:


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


----------



## Ericthegreat (Jul 26, 2019)

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 (Jul 26, 2019)

Ericthegreat said:


> 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 (Jul 26, 2019)

mountainflaw said:


> 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 (Jul 26, 2019)

I thought SuperSponge was the open source game.


----------



## Deleted User (Jul 26, 2019)

*It begins.*


----------



## CrashOveride (Jul 27, 2019)

alivebacon said:


> 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 (Aug 3, 2019)

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 (Aug 3, 2019)

Ericthegreat said:


> 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++;
}



FAST6191 said:


> 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.



nullpointer128 said:


> 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 (Aug 3, 2019)

TheGamingLord said:


> 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
> ...



You read install.md right?


----------



## TheGamingLord (Aug 4, 2019)

Yes, I have.


----------



## mountainflaw (Aug 5, 2019)

smf said:


> Sure, you can't know whether Nintendo wrote
> 
> int i; for (i = 0; i < 10; i++)
> {
> ...



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


----------



## smf (Aug 5, 2019)

mountainflaw said:


> 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 (Aug 11, 2019)

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 (Aug 12, 2019)

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 (Aug 12, 2019)

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


----------



## TheGag96 (Aug 13, 2019)

funkyzaps said:


> 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
> 
> ```
> ...



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 (Aug 15, 2019)

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 (Aug 16, 2019)

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.


----------



## BridgetX (Aug 17, 2019)

funkyzaps said:


> 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
> 
> ```
> ...


Thank you, it did work, i guess it was having problems with permissions and i was too dumb to give permission to the entire compiler folder
in any case now that i can compile it i will see what kind of fun stuff you can do with the source


----------



## godreborn (Aug 17, 2019)

now, we just need super man 64 to be decompiled.


----------



## uyjulian (Aug 17, 2019)

You know you can get the ROM map by looking at the debug information, right?


----------



## Ecchi95 (Aug 17, 2019)

uyjulian said:


> You know you can get the ROM map by looking at the debug information, right?


No shit. But I'm doing this by hand. I have no intent of compiling it.


----------



## TheGamingLord (Aug 18, 2019)

I've completely given up on compiling this, I have no idea why it doesn't work for me, I've followed the install.md instructions several times on two different computers through both virtualbox and wsl, but I keep getting the exact same error.


----------



## CrashOveride (Aug 20, 2019)

TheGamingLord said:


> I've completely given up on compiling this, I have no idea why it doesn't work for me, I've followed the install.md instructions several times on two different computers through both virtualbox and wsl, but I keep getting the exact same error.



You tried the solution that worked for @BridgetX ?


----------



## TheGamingLord (Aug 20, 2019)

CrashOveride said:


> You tried the solution that worked for @BridgetX ?


Yes, but that didn't work


----------



## Ecchi95 (Aug 22, 2019)

Here are the compiled versions of stuff from src/engine and src/game, plus the decompress function from the asm folder.
(Super Mario 64 (J) [!])

Located BY HAND without ever compiling it.

Still to-do:

src/audio
src/goddard


```
001050 001E3F main.o
001E40 0031AF display.o
0031B0 003C0F game.o
003C10 0045AF sound_init.o
0045B0 006E4F level_update.o
006E50 00B76F interaction.o
00B770 00FE1F mario.o
00FE20 011C1F mario_step.o
011C20 0189EF mario_actions_cutscene.o
0189F0 01B4DF mario_actions_automatic.o
01B4E0 01EA4F mario_actions_stationary.o
01EA50 024ACF mario_actions_moving.o
024AD0 02AB9F mario_actions_airbone.o
02ABA0 02F93F mario_actions_submerged.o
02F940 030C1F mario_actions_object.o
030C20 030EFF level_geo.o
030F00 03292F mario_misc.o
032930 033BAF memory.o
033BB0 03521F save_file.o
035220 03610F area.o
036110 038E2F rendering_graph_node.o
038E30 039F2F profiler.o
039F30 039FDF decompress()
039FE0 056FEF camera.o
056FF0 056FFF debug_course.o
057000 0580FF object_list_processor.o
058100 05FDAF object_helpers.o
05FDB0 082F1F behavior_actions.o
082F20 08345F platform_displacement.o
083460 083CEF object_collision.o
083CF0 08455F spawn_object.o
084560 08488F spawn_sound.o
084890 085ADF debug.o
085AE0 08779F screen_transition.o
0877A0 089ACF shadow.o
089AD0 08A59F skybox.o
08A5A0 08C72F moving_texture.o
08C730 08CEDF geo_misc.o 
08CEE0 09031F paintings.o
090320 09143F print.o
091440 097EDF ingame_menu.o
097EE0 099E3F envfx_snow.o
099E40 09C18F envfx_bubbles.o
09C190 09CDDF macro_special_objects.o
09CDE0 09DF3F hud.o
09DF40 0B367F obj_behaviors.o
0B3680 0CE91F obj_behaviors_2.o

0F4210 0F6C2F math_util.o
0F6C30 0F876F graph_node.o
0F8770 0F9BAF geo_layout.o
0F9BB0 0FC09F level_script.o
0FC0A0 0FDE9F surface_collision.o
0FDEA0 0FF57F surface_load.o
0FF580 10199F behavior_script.o

21D7D0 21DD9F level_select_menu.o
21DDA0 21E9AF intro_geo.o
21E9B0 224F6F file_select.o
224F70 225D9F star_select.o
```


----------



## CrashOveride (Aug 25, 2019)

The decomp is officially released. I won't link it per forum rules, but it's very easy to find. I will disclose it is on a certain git site


----------



## uyjulian (Aug 25, 2019)

Try "Nintendo 64 Decompilation Projects"


...going right on my Git mirror.


----------



## FAST6191 (Aug 25, 2019)

Did a little compare between a handful of bigger and more important looking files (I opened both zips and chucked choice files on separate screens so I could look back and forth). No dates in the leaked version and github says all today which means we will have to have some fun with proper tools.

In some cases the github version is a bit cleaner formatting, other cases there are some curious choices like having parts of tables/arrays on new lines (I don't much care about the tabs vs spaces debate). The original did not especially lack here though.

Not seeing much in the way of new/better function names, comments and what have you -- some of the sounds might be better named but it was not particularly opaque before or anything. mario_step.c has some more comments I guess, though they are mostly concerned with the unknown leftover code that might well have been dealing with the Mario 64 beta's trampoline. paintings.c was quite a bit different.
The leaked version for mario_action_airborne has #if VERSION_US around the place where the github version opts for #ifndef VERSION_JP which might well confuse some simpler source management tools. Be sure what you versions you are all using if doing a collaborative effort (I would suggest the github)


----------



## CrashOveride (Aug 25, 2019)

>No dates in the leaked version and github says all today

Most likely to hide contributors against ninty


----------



## CrashOveride (Aug 28, 2019)

@Ecchi95 We created an unofficial decompilation server. We'd love to have you come on and talk about your upcoming projects: https://discord.gg/27JtCWs That compiler would be very useful for windows users


----------



## Ecchi95 (Aug 28, 2019)

CrashOveride said:


> @Ecchi95 We created an unofficial decompilation server. We'd love to have you come on and talk about your upcoming projects: https://discord.gg/27JtCWs That compiler would be very useful for windows users


I don't use Discord except for sex servers.

I'm making a new thread about my projects next month.


----------



## Onceset (Sep 5, 2019)

Erokaution said:


> Made a account real quick to jump in on this conversation.
> I find it unfortunate that I live in the universe where SM64 got decompiled before OOT, I would be all over a OOT decompilation and already thinking of large projects to start. Still, this is absolutely amazing. It's really easy and fun to work with.
> I've had the displeasure of spending years hacking various games, and I've spent too much time looking at and trying to write assembly. Really not fun stuff, but it opens up a ton of doors.
> But now, with this, SM64 hacks will be far easier to create, and you can do so much more with it in a fraction of the time.
> ...


 


Ecchi95 said:


> Files containing particular strings:
> 
> *    spawn_*
> 
> ...


  Is it possible to download this code?


----------



## CrashOveride (Sep 6, 2019)

https://github.com/n64decomp/sm64


----------



## Ecchi95 (Sep 26, 2019)

N/A


----------



## Deleted User (Jan 29, 2020)

http://www.romhacking.net/hacks/4905/
Thanks to decompiling Super Mario 64 back into its source code, there is now a patch available that enables O2 compression.
This completly erases lag, including the one caused by the Bowder submarine!
Confirmed to work on real hardware.


----------



## vagab0nd94 (Jan 29, 2020)

Nice work


----------



## orangy57 (Jan 29, 2020)

With this more efficient O2 compile, does this mean that romhacks made using that version of the rom would theoretically run faster since it's using more optimized code?


----------



## FAST6191 (Jan 29, 2020)

I did wonder what became of this project.

Hopefully this is the start of a snowball, though I imagine we will be waiting for easy Windows or whatever compile for that one.


----------



## Coto (Feb 2, 2020)

Orangy57 said:


> With this more efficient O2 compile, does this mean that romhacks made using that version of the rom would theoretically run faster since it's using more optimized code?


If the rom hacks have PIC code (relocatable, shared library), yes. Otherwise you'll get a nice crash.

I think early N64 games were compiled with very little optimization because that way these'd have been easier to debug. It is easier to debug barely optimized code (as it is simpler), than it is optimized. Maybe the SDK was made out of Mario N64? Not to mention optimized code always end up breaking code not supposed to be optimized at all (such as older system's IO port read/writes, which required drain write buffer + invalidate cache + read/write primitive opcodes (ie, single, the most basic opcodes) and not subsequential read/write opcodes (sequential), such as ldr/str vs ldm/stm, because these would cause unexpected behaviour.


----------



## Deleted User (Feb 8, 2020)

More info from the modern vintage gamer:


Also an interessting reply from famous Super Mario 64 romhacker Kaze Emanuar:

"This is not entirely true. The CPU is almost never fully utilized. The mistake with the DDD lag is making the collision triangles dynamic rather than permanent. O2 compilation only mitigates this issue. It could be entirely solved by making the collision from the sub permanent (and I did that in SM64 Multiplayer, for example) Most of the lag in SM64 comes from GPU which this doesn't change so O2 compilation doesn't change anything for most of the game."


----------



## Deleted User (Mar 4, 2020)

A patch for Super Mario 64 called Super Mario 64: Arguably Better Edition has been released on Mario Fan Game Galaxy (MFGG).
Made by MFGG member *Mors *using the SM64 Decompilation project.

https://www.mfgg.net/?sess=6974d051c1924154716229e6525e45d9&act=resdb&param=02&c=7&id=36500


----------



## FAST6191 (Mar 5, 2020)

Nice to see things starting, I am still mostly hoping for a PC port or better but improvements (even if some of them are emulator only) is still good to see. I will have to play it to see what the changes do as far as balance (wall kick was already pretty powerful and allows you to cheese some stuff, more so would be more so. Also wall sliding I guess is fun but might change things again, still always up for more hacks.)

You might as well quote the readme at least



			
				The readme for the Super Mario 64: Arguably Better Edition - R3 download said:
			
		

> This is Super Mario 64, but with changes that would make it a better game overall, at least in my opinion. It also features a few additional bonus features if you're into that sort of thing.
> 
> The base hack is fully console compatible, however, the widescreen version is NOT tested on real hardware, so if your N64 ends up exploding and giving you 3rd-degree burns, I'm not the one to blame!
> 
> ...


----------



## eyeliner (Mar 5, 2020)

I want to see someone make an engine out of it.
So those awesomely intelligent people create new games based on it, not only derivative more Mario games.
Kind of like iD did with Quake.


----------



## FAST6191 (Mar 5, 2020)

Surely there are better engines already out there, likely with far less legal headaches for releasing the end result too. Mario 64's engine does not do all that much special these days, and has a massive list of quirks and limitations to deal with that are a complete non factor in more modern stuff.


----------



## Deleted User (Apr 19, 2020)

https://github.com/DavidSM64/SM64-Fast3D-AA-Reducer

This simple tool will overwrite the Fast3D 2.0D microcode within a SM64 ROM, and replace it with a slightly modified version that disables full anti-aliasing. It does this by blocking any attempt to write the IM_RD render mode flag into the RDP's othermode variable. This should improve performance on real N64 hardware by 3-4 fps (~10%).

*How to use:*

Just simply open up a Super Mario 64 ROM file, and then you can click the "Reduce the AA!" button if the ROM is compatible.

*What Super Mario 64 Rom are compatible?:*

Any SM64 ROM that uses the Fast3D 2.0D microcode is compatible. This includes the Japanese and North American versions of SM64 and any ROM hacks made with those versions.

*Benchmark:*

The beginning area of Jolly Roger Bay does lag a significant amount. Going down to a 22 fps minimum in my testing. Injecting the modified microcode makes a significant difference in the feel of the game, with the minimum increased to 25 fps.

My jolly roger bay benchmark starts at the beginning of the level and has Mario swim into the underwater cave. The framerate is bad in the beginning, but gets a lot better when you are deep underwater.


----------



## GizmoTheGreen (May 5, 2020)

trying to compile SDL ver on Manjaro (archlinux based) on raspberry pi 4 (aarch64) and get



Spoiler: code





```
as -I include -I build/us_pc --defsym VERSION_US=1 -MD build/us_pc/sound/sequences/00_sound_player.d -o build/us_pc/sound/sequences/00_sound_player.o sound/sequences/00_sound_player.s
sound/sequences/00_sound_player.s: Assembler messages:
sound/sequences/00_sound_player.s:87: Error: too many positional arguments
sound/sequences/00_sound_player.s:88: Error: too many positional arguments
sound/sequences/00_sound_player.s:89: Error: too many positional arguments
sound/sequences/00_sound_player.s:92: Error: too many positional arguments
sound/sequences/00_sound_player.s:93: Error: too many positional arguments
sound/sequences/00_sound_player.s:194: Error: too many positional arguments
sound/sequences/00_sound_player.s:195: Error: too many positional arguments
sound/sequences/00_sound_player.s:197: Error: too many positional arguments
sound/sequences/00_sound_player.s:200: Error: too many positional arguments
sound/sequences/00_sound_player.s:202: Error: too many positional arguments
sound/sequences/00_sound_player.s:225: Error: too many positional arguments
sound/sequences/00_sound_player.s:225: Error: unknown mnemonic `restore' -- `restore the value'
sound/sequences/00_sound_player.s:227: Error: too many positional arguments
sound/sequences/00_sound_player.s:228: Error: too many positional arguments
make: *** [Makefile:677: build/us_pc/sound/sequences/00_sound_player.o] Error 1
```




Anyone have any ideas?


----------



## ital (Nov 17, 2020)

Something old, something new:



RT works amazingly well in this game, well on this stage at least because the rest of them would have reflective carpets and glow in the dark walls.


----------



## VinsCool (Nov 17, 2020)

replicashooter said:


> Something old, something new:
> 
> 
> 
> RT works amazingly well in this game, well on this stage at least because the rest of them would have reflective carpets and glow in the dark walls.



That looks seriously incredible.

Combining this to SM64 EX and Render96 models and this will become a really serious remaster project.


----------



## ital (Nov 17, 2020)

There have been quite a few high effort remasters:



But generally the overly reflective ray tracing and effects don't match the rest of the game as well as they do in the originally linked video:



Shiny reflective grass for the lulz! 

The n3DS version of this is the ultimate remaster. Playing it in real 3D makes it feel brand new and the 800px mode when the effect is turned off on the small screen makes it look really crisp and authentic in a way the remasters don't.


----------



## ital (Nov 23, 2020)

Fans do what Nintendont:



Looks really good and was what I was expecting them to do with a full remake, even if they kept the engine the same underneath with a new skin on top.


----------

