Metroid Prime: il lead engineer racconta della curiosa vicenda del dev kit nel freezer
1
0
Nelle scorse ore sono emerse delle curiosità in merito allo sviluppo del primissimo Metroid Prime, rilasciato nel 2003 su Nintendo Game Cube.
Gli sviluppatori di Metroid Prime hanno infatti messo il kit di sviluppo Game Cube in un freezer per risolvere un problema creatosi nel post-lancio.
A rivelarlo è Jack Mathews, un ingegnere capo tecnico che ha lavorato al progetto, ha condiviso questa curiosità in un’intervista mentre rifletteva sul 20° anniversario di Metroid Prime.
Nintendo aveva spedito un “batch difettoso” di Game Cube che influiva sulla CPU, scoprendo poi che Metroid Prime fu l’unico gioco che non funzionava correttamente.
Infatti gli oggetti animati non si comportavano come avrebbero fatto normalmente su qualsiasi altra console. Per risolvere il tutto, Retro Studios utilizzò un singolo kit di sviluppo con la CPU irregolare, ma lo stesso per funzionare doveva essere freddo. Per far ciò, si decise letteralmente di introdurre il dev kit in un congelatore, testare il gioco per 15 minuti al massimo, per poi ricominciare il procedimento da capo.
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!
Average Rating