[wodenokoto]

So there is a rumor that Nintendo forgot to switch an optimization flag when compiling Mario 64 and that is why we have lag in the water levels.

Since we are talking about the source code, I’m sure someone much more knowledgeable than me might be reading and could maybe confirm or deny the rumor.

[someone2639]

The lag in Dire Dire Docks is because the collision for the submarine (which is either 200 or 700 triangles, i can't remember) is recalculated every single frame. O2 is like a bandage to the overarching issue.

The only real cause for lag in SM64 is that the RDP graphics chip has a fixed rate for how many pixels it can draw per frame, and that's quickly filled up by large triangles, transparency, any 2-cycle effects like fog, overdraw, etc. (and that's not even taking texture loading latency into account)

[emsy]

I read somewhere that SM64 collisions have no fancy optimization but are just brute force and a first glance at the source seemed to confirm this. Which shows that 1) you really don’t need to optimize prematurely 2) something is very wrong with engines used in modern (indie) games of similar complexity when they perform badly on modern hardware

[edflsafoiewq]

I don't know how fancy these optimizations are, but it is optimized.

* Tris are sorted by whether they are static (level geometry) or dynamic (moving platforms). So only dynamic tris need to be reinitialized every frame.

* Tris are further sorted into which cells they touch. A cell is a spatial partition of a level. So collision detection only needs to check against tris in your current cell.

* Tris are further sorted into walls, floors, and ceilings (depending on their normal). The find_wall_collisions, find_floor_collisions, etc. functions are each optimized for that particular kind of tri.

* Tris extend their hitbox along a coordinate axis (the up axis for floors/ceilings, the one closest to their normal for walls), instead of along the normal itself. This is cheaper to test, since you can just project down along that axis and it becomes a point-in-tri test in 2D.

[danbolt]

Ding ding ding! RDP fillrate is the name of the game when it comes to N64 performance.

Even with the strange FPU/ALU combo that NEC did, you can get away with a lot on the CPU side.

[muterad_murilax]

That Nintendo forgot it is debunked by Modern Vintage Gamer here: https://www.youtube.com/watch?v=NKlbE2eROC0

[delroth]

MVG regularly gets key technical information wrong and barely cites any sources, so I'd take this with a grain of salt.

Example: he claimed in [1] that a Nintendo leak contained "the entire source code of IOS" (IOS being the Wii operating system) and "the Verilog for the entire Nintendo Wii". Both of these claims are completely wrong and have been refuted by both console hackers and emulator developers for the Wii. I told MVG on Twitter, he replied saying approx. "oh it's not my fault I just read what was written online and haven't looked at the details myself" [2]. To this day the video is still up, there is no errata either in the description or in comments. This is not the only example, just the freshest one in mind and one I was directly involved with.

[1] https://www.youtube.com/watch?v=n8G7eq0GlQs [2] https://twitter.com/ModernVintageG/status/125820871313715200...

[audunw]

> so I'd take this with a grain of salt.

Well, in this video it's not like he's stating it as absolute fact that they didn't forget to use -O2. He just presents another much more plausible (IMO) explanation. And he backs it up with direct references to original documentation and a tweet from a developer experienced with early N64 development.

I think his claims here looks pretty solid, if you have reason to doubt them based on the content of the video, it'd be nice if you shared that.

More examples would be interesting too if you can remember other cases. To me, getting a fact like that wrong on a breaking news kind of video and not taking the time to correct it later isn't that big of a deal to be honest. If it was really important to me what the content of the leak was I'd check myself.

[delroth]

Looking at the SM64 video, he: 1. misrepresents the work from the SM64 decomp project (some of the decomp developers even commented in the video comments); 2. misreads and/or misunderstands the toolchain errata, what he describes in his audio track doesn't match at all what he shows on screen. But there isn't much of a claim to debunk, because it's all hypothesis that "Nintendo wouldn't make such a basic mistake, it's deliberate".

Anyone who has experience working on emulation and reverse engineering of Nintendo games can tell you that Nintendo keeps doing basic technical mistakes when shipping production games. Dolphin's wiki has a whole category for "games that shipped with debug symbols". Pikmin has a freakin' mostly-working PC port of an early version of the game on the GameCube disc. There's also no evidence that other N64 launch titles had the same idiosyncrasy of compiling in -O0, and the whole SDK is compiled in -O2 as he even mentions in his video. How does that fit with the "early toolchain" line of reasoning?

TL;DR: Actually forgetting to build with optimizations enabled is completely in line with what emulation developers and game reverse engineers have seen from Nintendo in the past 20 years. MVG just states his own theory as fact, without the Nintendo console hacking / RE / emulation experience, and with very little evidence which doesn't even match his own claims.

EDIT: See also [1] hidden in the 2nd page of YT comments on that SM64 video, from someone who was involved with the SM64 decompilation project.

[1] https://imgur.com/XZ45IZH

[Narann]

Doesn't looks like a "debunking", but more a "here is why".

TL;DW: O2 was causing problems in the first version of the SDK, but all other libraries (libUltra) were compiled with O2.

Nintendo didn't "forgot" anything, they just have to. Same as other stories (DK64 bug that force Rare to ship DK64 with expansion pak).

[quietbritishjim]

The first comment said Nintendo just forgot to switch on optimisations. If they didn't forget, but instead did it deliberately, then that is indeed a debunking.

[numlock86]

AFAIR the DK64 thing was about a memory leak that couldn't be fixed before launch date and the quick-hack workaround was to just make the game require the expansion pak, which made the memory leak take a few days instead of hours to happen.

[CodeArtisan]

Nintendo's source code got leaked last year and the makefile has -O2

    CC_FLAGS  = -fno-pic -mcpu=4300 -nostdinc -I$(ROOT)/usr/include -I$(ROOT)/usr/include/PR -c -O2 -G 0