sm64 | Super Mario 64 decompilation , brought to you by a bunch

GCC can build 32bit or 64bit executables (on most systems). It all depends on what arguments you give it. If you look at the compile invocation that make is running you'll likely see that it passes the -m32 (or some similar) option, which tells the compiler and linker to create 32bit objects and binaries.

If you want to build 64bit instead you'll have to find the arguments in your makefile or other configuration that select 32bit, and remove them (or change them to explicitly choose 64bit).

I should warn you, this almost certainly won't work!! It's not the case that any old C program can be compiled as either 32bit or 64bit and continue to work identically. It is possible, but doing this requires that the programmer write their code carefully and with forethought. In my experience video game programs are almost always coded specifically for a given hardware target and little thought is given to making it portable to other hardware, and that includes 64bit versions of the "same" vendor.

Instead of trying to make the code build for 64bit, a better use of your time is to investigate why your system is not able to run a 32bit executable and fix that. It's odd to me that you can compile for 32bit but not run 32bit: usually if you can build it then you have the proper libraries, etc. installed to run.

Before I go into anything, let me first recommend using the Discord link attached to that repo, discord.gg/27JtCWs . I will do the best to answer this, but am definitely not the most knowledgeable of standards and typical behavior for coding in-general. My experience is only relevant since I work closely with some individuals involved with the decompilation.

1 & 2. I don't believe that this is a sane thing to generally do, however it is important to remember the point of the repo- allow modifications easily to the codebase while preserving its ability to compile a 1:1 ROM of SM64. Having the file split up makes finding the relevant locations of things easier, although this particular one is not well named yet.

1. So the inc.c files are glorified header files, just inserting their code in that location. It's named a .c file because it is sort of C, just not a legitimate C file itself. That's why it's .inc.c, since it is INCluded>

2. It is a standard unsigned char, that is correct. This can be found in types.h. This is done because really its just importing a bunch of data that can be read separately. This particular file isn't in the repo, but if you extract assets you can see that is is an image being inserted there. The image's data is just split up into u8's and put there, allowing it be both be extracted/inserted and more easily edited.

3. ALIGNED8 is for the compiler. The IDO 5.7 compiler that the repository uses often aligns things within the ROM output, and the ALIGN8 directive is telling it to pad out to 8 bytes. If the ALIGNED8 was not there, it would potentially insert that data too soon, shifting the ROM.

Hope I didn't make any mistakes and this helps. It's just important to remember that the whole GitHub isn't really a typical one, since its less about worrying about internal consistency and more worrying about external (ROM) consistency, often meaning that sometimes solutions have to be sort-of hacked together to allow functionality. If you have further questions I will again recommend asking in the Discord, as those guys are much more informed than I am.