glankk / n64 Goto Github PK

I can't install the toolchain because of a number of problems.

1. If you append the --enable-vc and --enable-static-executables, the binutils version fails to be set causing wget to fail.

2. wget fails saying the certificate is self signed, mentions its kaspersky one (my antivirus), had to disable encrypted connection scanning in its options to fix that one, don't know whats up with all that.

3. Why does the installation take 2 hours? do we really need all this stuff? and right at the end I was greeted by a nice error and a kaspersky blocking a file xgcc.exe saying its a trojan bitcoin miner. Kaspersky never gave me false positives before, its always been great at finding actual viruses so I don't really know what to do about this situation.

Is there any way to install a slim version of this whole toolchain? do we really need 3+ gb of stuff and 2 hours wait every time we install this on a new machine?

The following gfx data produces no output on gfxdis.f3dex

0xBA000018 0x0000ECF0
0xB9000003 0x00504244

Example:

$ gfxdis.f3dex -d BA0000180000ECF0B900000300504244
{
}

Passing the -i flag produces macros that are not part of the official gbi.h

$ gfxdis.f3dex -i -d BA0000180000ECF0B900000300504244
{
    gsSPSetOtherModeHi(0, 24, G_AD_DISABLE | G_CD_DISABLE | G_CK_NONE | G_TC_FILT | G_TF_BILERP | G_TT_IA16 | G_TL_TILE | G_TD_CLAMP | G_TP_NONE | G_CYC_1CYCLE | G_PM_NPRIMITIVE),
    gsSPSetOtherModeLo(G_MDSFT_ALPHACOMPARE, 3, G_AC_NONE | G_ZS_PRIM | G_RM_XLU_SURF | G_RM_XLU_SURF2),
}

Tharo explained to me those are custom helper macros.

Since gfxdis is used heavily on decomp projects it would be very nice if it could output the corresponding gsSPSetOtherMode(G_SETOTHERMODE_H, ... and gsSPSetOtherMode(G_SETOTHERMODE_L, ..., even if it was behind a flag and the helper macros were preserved.

Tested on gfxdis-0.6

Hi,
Attempting to build with sudo make -j4 install-toolchain on Ubuntu 18.04.2 LTS, getting this:

checking for mips64-gcc... /home/lucas/n64-master/build-gcc/./gcc/xgcc -B/home/lucas/n64-master/build-gcc/./gcc/ -B/opt/n64/mips64/bin/ -B/opt/n64/mips64/lib/ -isystem /opt/n64/mips64/include -isystem /opt/n64/mips64/sys-include checking for suffix of object files... configure: error: in /home/lucas/n64-master/build-gcc/mips64/libgcc: configure: error: cannot compute suffix of object files: cannot compile See config.log for more details Makefile:13448: recipe for target configure-target-libgcc failed make[2]: *** [configure-target-libgcc] Error 1 make[2]: Leaving directory /home/lucas/n64-master/build-gcc Makefile:957: recipe for target all failed make[1]: *** [all] Error 2 make[1]: Leaving directory /home/lucas/n64-master/build-gcc makefile:117: recipe for target all-gcc failed make: *** [all-gcc] Error 2
I attached my config.log from root and config.log from build-gcc for more detail. How can I fix this? I have also attached a screenshot of my error.

config (root).log
config (build-gcc).log

Tested against 9ed2a74f3190d223aab88ceef0f896e04c559890:

./n64/src/gfxdis/gfxdis.f3dex -d BF 00 00 00 00 2C 3A 3E
{
    gsSP1Triangle(0, 0, 0, 0),
}

but it should be

{
    gsSP1Triangle(30, 28, 31, 0),
}

currently compiling latest master, will close the issue if this is already fixed :)

mk64 uses gsSPLine3D (0xB5):

00002b00: 0400 81ff 0600 0000 b500 0000 0600 0204  ................
00002b10: b500 0000 0008 0a02 b500 0000 0e06 040c  ................
00002b20: b500 0000 0810 120a b500 0000 1014 1612  ................
00002b30: b500 0000 1418 1a16 b500 0000 1e0e 0c1c  ................
00002b40: b500 0000 2620 2224 b500 0000 2028 2a22  ....& "$.... (*"
00002b50: b500 0000 2e26 242c b500 0000 3630 3234  .....&$,....6024
00002b60: b500 0000 3038 3a32 b500 0000 381e 1c3a  ....08:2....8..:

but these are parsed out as (0, 0, 0)

$HOME/github/n64/src/gfxdis/gfxdis.f3dex -d 0400 81ff 0600 0000 b500 0000 0600 0204 b500 0000 0008 0a02 b500 0000 0e06 040c
{
    gsSPVertex(0x06000000, 32, 0),
    gsSPLine3D(0, 0, 0),
    gsSPLine3D(0, 0, 0),
    gsSPLine3D(0, 0, 0),
}

Is there a way to coerce them into their correct values via gfxdis?

Lua 5.4 introduced an API incompatibility (http://www.lua.org/manual/5.4/manual.html#8.3) that renders gru unable to build. lua_newuserdata() was replaced with lua_newuserdatauv().

The new function is defined as:
void *lua_newuserdatauv (lua_State *L, size_t size, int nuvalue);

It adds a third argument, int nuvalue, to the end of the function. Apparently setting this to 0 provides best performance, but sometimes it is necessary to set it to 1 for compatibility. Searching for this issue yields a few GitHub repos that have already made this change. See: ThePhD/sol2#1052 and cloudwu/lua-bgfx@40c404c

I imagine most major distros are still on Lua 5.3 or below, but some of the more leading-edge distros like Fedora are already on Lua 5.4, and all distros will eventually follow suit. Maybe it would be possible to allow compatibility with both Lua verisons using an ifdef on Lua 5.4 to define a macro (ThePhD/sol2#1047 (comment)) such as this one #define lua_newuserdata(L, sz) lua_newuserdatauv((L), (sz), 0)?

Thanks so much! I'd submit a PR myself but Lua is not my strong suit.

Hi Glankk,

Would you be willing to create an update to interpret B1 op codes like the following:

as gsSP2Triangles?

gfxdis.f3dex output swaps between quadrangle and triangle sort of arbitrarily. mk64's quadrangle macro will be reserved for the B5 op code. This means the most suitable macro for B1 commands is a 2tri macro such as gSP2Triangles. These changes may work well for any alleged beta f3dex game (mk64 is likely the only game with these shenanigans though).

It would be nice if gfxdis had an argument for outputting B5 op code as a quadrangle.

static Gfx trophy_dl[] = {
    gsSPVertex(0x0B000340, 31, 0),
    gsSP1Quadrangle(0, 1, 2, 3, 0),
    gsSP1Quadrangle(1, 4, 5, 2, 0),
    gsSP2Triangles(3, 2, 6, 0, 2, 5, 6, 0),
    gsSP1Quadrangle(4, 7, 8, 5, 0),
    gsSP2Triangles(5, 8, 6, 0, 9, 3, 6, 0),
    gsSP2Triangles(8, 10, 6, 0, 10, 11, 6, 0),
    gsSP2Triangles(11, 12, 6, 0, 12, 13, 6, 0),
    gsSP2Triangles(13, 14, 6, 0, 14, 9, 6, 0),
    gsSP1Quadrangle(15, 16, 17, 18, 0),
    gsSP1Quadrangle(16, 19, 0, 17, 0),
    gsSP1Quadrangle(18, 17, 9, 14, 0),
    gsSP1Quadrangle(17, 0, 3, 9, 0),
    gsSP1Quadrangle(20, 15, 18, 21, 0),
    gsSP1Quadrangle(21, 18, 14, 13, 0),
    gsSP1Quadrangle(22, 20, 21, 23, 0),
    gsSP1Quadrangle(23, 21, 13, 12, 0),
    gsSP1Quadrangle(24, 22, 23, 25, 0),
    gsSP1Quadrangle(25, 23, 12, 11, 0),
    gsSP1Quadrangle(7, 26, 10, 8, 0),
    gsSP1Quadrangle(26, 25, 11, 10, 0),
    gsSP1Quadrangle(27, 24, 25, 26, 0),
    gsSP1Quadrangle(28, 27, 26, 7, 0),
    gsSP1Quadrangle(29, 28, 7, 4, 0),
    gsSP1Quadrangle(30, 29, 4, 1, 0),
    gsSP1Quadrangle(19, 30, 1, 0, 0),
    gsSPEndDisplayList(),

};

F3DEX1
Issue 1

Machine code: BC00000800000000

From hack64:

G_MW_FOG | 0x08 | Specifies the multiplier and offset for fog effects.

Byte-matching C code:

gSPFogPosition(gDisplayListHead++, (s16)0-1000, (s16)0-1000);

In mk64 the args match as two s16s. iirc they are minimum and maximum values for fog thickness.
Dunno if it actually asks for s16. That's just what mk64 does.

Issue 2
Mips to C output:

    temp_v0_11->unk4 = -0x7C8;
    temp_v0_11->unk0 = 0xFC127FFF;

gfxdis: FC127FFF00000000
output:

gDPSetCombineLERP(gDisplayListHead++, TEXEL0, COMBINED, SHADE, COMBINED, 0, COMBINED, 0, COMBINED, 0, COMBINED, 0, COMBINED, COMBINED, COMBINED, LOD_FRACTION, COMBINED);

Matching C:

gDPSetCombineMode(gDisplayListHead++, G_CC_MODULATERGB, G_CC_PASS2);

Note that G_CC_MODULATEIA appears to be the default flag that gfxdis outputs. This case required G_CC_MODULATERGB dunno if that's a thing that gfxdis can realize (I'm assuming not, so we can ignore that. Just wanted to point that out in-case that's important)

It seems that the install_dep script does not properly install gcc, lua, jansson, and libusb but instead installs mingw-w64-i686 version instead which the configure script is unable to find.

I imagine the workaround for this is to install the packages manually or add the /mingw32/bin directory to path. What are your thoughts?

F3DEX1

0xB6000000 0xFFFFFFFF
0xB7000000 0x00800204

outputs as:

gsSPLoadGeometryMode(G_SHADE | G_SHADING_SMOOTH | G_CLIPPING),

Instead of:

gSPClearGeometryMode(gDisplayListHead++, 0xFFFFFFFF);
gSPSetGeometryMode(gDisplayListHead++, G_SHADE | G_SHADING_SMOOTH | G_CLIPPING);

LoadGeometryMode is only supported in f3dex2
Tested using mk64
(SSSV apparently had the same issue)