-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> 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. 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...
PD will definitely be the next game to be fully (or near enough) decompiled. The dev behind that one is great.
If you're bored, his write up on the "Challenge 7 Bug" is great read: https://gitlab.com/ryandwyer/perfect-dark/-/blob/master/docs...
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 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.
I think that that is a C thing, though: an unpostfixed 0. is a double. 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...
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