The Metroid Prime franchise is celebrating its 20th anniversary and game developers have shared stories about their time creating the GameCube masterpiece. One of these developers is former Retro Studios
Senior Engineer, Zoid Kirsch, who recalled having to put a GameCube development kit in the break room freezer in order to solve a frustrating issue with the game. Nintendo had distributed a batch of bad GameCube CPUs and they didn’t perform correctly and Retro’s code was running too fast for the aforementioned GameCube CPU to handle. To get it to work correctly it needed to be very cold so they had to put the kit into a freezer and then they could test the game correctly for 15 minutes max then restart the process again. The team had to run the kit between the Retro Studios break room freezer to the TV, and loading save games as fast as possible to as many places as possible in just 15 minutes, then trying new code, re-freezing, and back. Kirsch says it was an experience they will never forget. Here’s what was said:
“Shortly after Prime shipped, Nintendo told us that a “bad batch” of GameCube CPU’s shipped, and apparently Prime was the only game that misbehaved on them. We saw videos and it was clear what was going on.
All animated objects were freaking out. I’ll get into the techy reasons later, but the point was 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.
Techy stuff: 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.
In case you were wondering, when someone called support about this animation problem, Nintendo actually sent them a new game disc with this updated code! That’s how we did “patches” back in the old days!”
