Super Mario 64 Decompilation

There were definitely issues with Rare during the development of Perfect Dark. Nintendo probably wasn't that interested in a game that would compete with their IP(Tomorrow Never Dies). A bunch of key people left Rare out of dissatisfaction during the middle of development.

This wasn't entirely a bad thing. According to Mark Emmonds:

> Although the story and ideas for the game were kept intact, the new team contributed so much to the development that it was seen as a fresh start. The team worked in a very isolated and free environment and did not have a production manager, a schedule, meetings, commercial pressure, or any sort of deadlines. According to artist Brett Jones, "People would just do things they thought were cool and would work"

It sounds like half the original team were looking for a more organized process, but the new developers thrived. The problem, however, was that the Nintendo 64 could barely handle all the features they'd packed into the cartridge, which is why the game suffers a bad frame rate even with the Expansion Pack.

To summarize, I think a lack of top-down enthusiasm for this game from both Rare and Nintendo lead to a lack of marketing effort, and problems with development actually lead to more creativity, but that creativity caused the game's performance to suffer. Back in those days, I remember some kids not even wanting to play multiplayer because of the frame rate. Multiplayer was a big deal for Goldeneye, and Perfect Dark's multiplayer performance was objectively inferior.(despite being better from a feature standpoint)

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.

* 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.

Again, I honestly don’t know for sure, sorry for the confusion.