November 17, 2002

Franchises

Metroid

Platforms

Nintendo GameCube

Companies

Nintendo Retro Studios

Genres

Adventure Platform Puzzle Shooter

Add Trivia

Viewing Single Trivia

View All (25)

▲

▼

According to one of the game's tech leads Jack Mathews, shortly after Metroid Prime shipped, Nintendo told Retro Studios that a "bad batch" of GameCube CPUs shipped, and apparently this game was the only game that misbehaved on them. Upon seeing videos of the issue, it became clear to them what was going on:

"All animated objects were freaking out... we needed to actually slow down some of our code, because it was running too fast for these CPUs to handle! We needed to be able to test this, but Nintendo only had one dev kit with this CPU. We couldn't detect the CPU, and if we slowed it down too much, the game's framerate would tank. If we didn't slow it down enough, it would glitch. Even worse, we had to burn disks for this kit. So each test was hours. Even weirder was to see the problem, the kit had to be cold. Like, freezer cold. So we literally had to put the kit in the freezer, test the game for 15 minutes tops, then start all over. It was crazy. We literally were running the kit from the break room freezer to the TV, and loading save games as fast as possible to as many places as possible in 15 minutes, then trying new code, re-freezing, and back. I'll never forget it."

In retrospect, he wondered if it was possible to instead rig up the GameCube so it stayed in the freezer and let the wires run out to connect to the TV to save time running back and forth.

On the more technical side, Mathews explained:

"Our skinning used the locked cache DMA to read in data and the write gather pipeline to write it out. Most of the Nintendo samples used the locked cache for both read and write, so my method was a bit faster. But it also hit memory bandwidth limits. As I recall, the issue was that the write gather pipe on these broken CPU's wouldn't stall when it was full or properly report its status, so we had to keep inserting NOPs in the code to slow it down just enough to stop stalls from happening, but not so much to slow down the game."

When a player called Nintendo of America's support hotline about this animation problem, they would send them a new copy of the game disc with this updated code.

When this story was posted to Twitter in 2022, one user posted an older video of a graphics glitch positing that the issue is "caused by the ANCS file using the wrong CSKR for the suit model", and that it might be possible to simulate the issue outside of the hardware and software conditions it originally happened in. Mathews replied:

"I don't know if it was writing out less than we were putting in the write-gather, or throwing away and reusing from the buffer, but sort of along these lines, with more jittering and triangles all over the place. This example has coherent skinning, just a bad mapping... I think the WG pipe was a 96 byte circular buffer. So when it wouldn't stall, it would write bytes over earlier entries in the buffer before they could flush to main memory. These would still be four-byte aligned writes, so I think the way to emulate it would be to take blocks of anywhere from 4-32 bytes (a multiple of four) and move them back by 96 bytes in the skinning buffer."

Mathews also talked about how it would have been a bigger hassle to rewrite the skinning pipeline to use the locked cache, because it would have been a rewrite by taking the risk of adding new code and may have net slowed things down. Adding the NOPs wouldn't break anything and just moved the stalls from the memory controller to the PPC chip.

sell