[holmium]

> The level of snark here is outstanding. [...] 'smelling the grass'

I thought his snark wasn't too off the charts in this video. I'd bet it's more a cultural thing. If you were working on the N64, you're probably like two decades above Kaze's target audience for his youtube videos haha. Like, he said that you can either be a weirdo who spends all day optimizing nearly 30 year old source code, or someone who "touches grass"[1]. He, of course, was referencing his own lack of life, not Nintendo's programmers. But, you'd have to pretty familiar with current online memes and insults to get his joke.

> I have not seen the Mario 64 source but I imagine some of the lowest level code was written in mips assembly but has been decompiled into C.

No, we only decompiled C code back into C code. The decompilation matches 1 to 1 with the released ROM images.[2] iirc, the only, non-libultra ASM code was the decompressor[3]. The C code was pretty obvious due to "wonders" of IDO -O0 optimization. We were forced to get surprisingly close to what Nintendo wrote. We were stuck with an `f32 [3]` 3-vec instead of a `struct`...

> I suspect the debug flags in gameplay code were to avoid compiler bugs.

As far as we could tell, this wasn't an issue. IDO 5.3 had no issues that we could find when compiling at -O2, but then again it was decompiled code. I personally subscribe to the '-O2 -g' IDO meme, but Giles Goddard thought it was out of fear of the unknown. So, I'd trust him.

We had the `mulmul` patch for IDO. I don't know the chronology for the release of that patch to devs, though. We also haven't been able to find any N64s that have the mulmul issue.

> An NTSC tv runs at 60Hz, you either hit 60fps or 30fps, anything in-between results in horrible tearing of the screen or your frames bounce between 60 and 30 and movement feels horrific.

I wonder what Kaze is doing. I know that there was work on a variable framerate mod/revamp for SM64. I'd guess it'd be outputting at the N64's 60 fps mode with duplicated frames, but you'd have much better luck asking one of the modders/coders who were working on that a couple years ago.

----------

[1] which is Twitter's insult du jour: https://knowyourmeme.com/memes/touch-grass

[2] https://github.com/n64decomp/sm64

[3] https://github.com/n64decomp/sm64/blob/master/asm/decompress...

[midnightclubbed]

One tidbit that may be of interest (or not) is that if you see doubles being used in N64 C code it is almost certainly accidental. Doubles were slow on the N64 mips CPU but the mips C compiler would happily output them and promote surrounding floats to keep the precision it assumed you wanted.

float myValue = x_float + y_float * y_float * 3.0;

Looks ok, except the constant is a double. Performance killer.

You'd get pretty good at seeing the missing f (and we eventually wrote some simple tooling to find functions using doubles) but I'm sure a number of games shipped with accidental double calculations.

[holmium]

hahah yes the "0.0f" is different from "0.f" is different from "0.0" is different from "0" is a great IDO meme as well. One of the changes we had to make when we started to support the PAL release, which was compiled at -O2, was to go back and change some constants from explicit "1.0f" to "1" to get the code-gen to match. IDO -O0 didn't care so long as you got the f32 vs f64 constant correct. But, IDO -O2 has different codegen.

The wonders of C constants. Sometimes IDO can do the conversion at compile time, and sometimes it can't. But, the compiler will treat things "0.0f" and a compile-time "(f32)0.0" as different constants for code-gen purposes.

We have a kinda outdated document of weird IDO behavior which is worth a read if you want to trigger some PTSD: https://hackmd.io/vPmcgdaFSlq4R2mfkq4bJg#Compiler-behavior

Also, since SGI/MIPS/IDO was from Stanford (I think...?), there is actually a surprising amount of published papers on IDO's compilation model. Which comes in handy if you are trying for the ultimate joke of decompiling the written-in-pascal compiler into C: https://github.com/n64decomp/ido

[midnightclubbed]

Thanks for filling in the details on the disassembly, I'm surprised the matrix functions weren't in asm but I believe you. If I remember correctly NOA did the CPU/lib side and NCL did the RSP code (definitely in asm) and hardware side.

The back to back multiplies definitely could cause hangs on real hardware (actually I'll back up and say it certainly could hang a dev-board and I think the hardware was the same as production). I don't know if there were particular registers or data that caused the hang but I remember QA picked up hangs with builds that had them in there.

Adding extra frame buffers lets you output at 60Hz without tearing but you'll bounce between duplicated frames and single frames. You technically get 40fps (or whatever) but smooth camera movements feel 'off'. That extra frame eats pretty badly into the remaining space in the 2Mb base memory (at 640x480 you could have just one frame buffer and render interlaced, so long as your frame rate always hit 60Hz).