Sì, fu messo letteralmente in un congelatore
Retro Studios, la casa sviluppatrice dell’apprezzata serie Metroid Prime, tentò di risolvere un particolare problema alla CPU di Nintendo GameCube, all’epoca in fase in pubblicazione, provando a congelarlo in un surgelatore per 15 minuti.
Jack Mathews, un ingegnere tecnico coinvolto nello sviluppo del primo Metroid Prime, ha raccontato questo particolare evento sul suo profilo Twitter. Egli evidenzia che il bug di Nintendo GameCube si manifestava solo su Metroid Prime e non gli permetteva di funzionare correttamente. Il modo più rapido per testare l’errore era congelare l’unico dev kit che avevano a disposizione. Ecco la storia completa, tradotta in italiano:
Metroid Prime Game Dev Story – Quella volta in cui refrigerammo un GameCube. Poco dopo la spedizione di Prime, Nintendo ci disse che ci fu spedito un “batch difettoso” di CPU GameCube e apparentemente Prime era l’unico gioco che si comportava male su di loro. Controllammo dei video e fu subito chiaro cosa stesse succedendo.
Tutti gli oggetti animati stavano impazzendo. Entrerò nelle ragioni tecniche più avanti, ma il punto era che dovevamo effettivamente rallentare parte del nostro codice, perché era troppo veloce per essere gestito da queste CPU! Dovevamo testarlo, ma…
Nintendo aveva solo un kit di sviluppo con questa CPU. Non siamo stati in grado di rilevare la CPU e, se l’avessimo rallentata troppo, il framerate del gioco sarebbe diminuito. Se non lo avessimo rallentato abbastanza, si sarebbe verificato un problema tecnico. Peggio ancora, avremmo dovuto masterizzare i dischi per questo kit. Quindi ogni test durava ore. Ancora più strano era vedere il problema, il kit doveva essere freddo. Tipo, congelato. Quindi abbiamo letteralmente dovuto mettere il kit nel congelatore, testare il gioco per 15 minuti al massimo, quindi ricominciare da capo. È stato pazzesco.
Stavamo letteralmente facendo lavorare il kit dal congelatore della sala pranzo alla TV e caricando i salvataggi il più velocemente possibile in più posti possibili in 15 minuti, quindi provando un nuovo codice, ricongelando e viceversa. Non lo dimenticherò mai.
Cose tecniche: il nostro skinning ha utilizzato il DMA della cache bloccata per leggere i dati e la pipeline di raccolta di scrittura per scriverli. La maggior parte dei campioni Nintendo utilizzava la cache bloccata sia per la lettura che per la scrittura, quindi il mio metodo era un po’ più veloce. Ma ha anche raggiunto i limiti di larghezza di banda della memoria. Se ricordo bene, il problema era che la pipe di raccolta e di scrittura su queste CPU rotte non si bloccava quando era piena o segnalava correttamente il suo stato, quindi dovevamo continuare a inserire NOP (No OPeration) nel codice per rallentarlo quel tanto che basta per fermare abbastanza gli stalli, ma non tanto da rallentare il gioco.
Nel caso ve lo stiate chiedendo, quando qualcuno ha chiamato il supporto per questo problema di animazione, Nintendo ha effettivamente inviato loro un nuovo disco di gioco con il codice aggiornato! È così che abbiamo fatto le “patch” ai vecchi tempi!
A volte i metodi più bizzarri sanno essere quelli più efficaci. Voi cosa ne pensate di questa particolare curiosità?
