Trip Hawkins era proprio innamorato dell'Amiga: oltre a supportare la piattaforma con giochi e programmi, avrebbe voluto fare molto di più... E come lui anche i programmatori Amiga erano abituati a fare molto di più, per far sì che i giochi girassero fluidi e senza scatti, con decine di colori e un sacco di oggetti sullo schermo.

Jeremy Reimer di Ars Technica ci parla di tutto ciò in questo post della serie A History of the Amiga, il terzultimo!

Qui di seguito o, come al solito, anche in originale qui.

Una volta che i giochi erano stati sviluppati e recensiti dalle riviste, il passo successivo nella strada che li avrebbe portati nelle mani dei giocatori erano i punti vendita. A quei tempi la maggior parte dei posti che vendevano giochi per computer erano negozi indipendenti, ognuno con una propria personalità. Kevin Hollingshead era a capo di una branca di Program Store, una delle prime catene nate da questo calderone. Vendevano giochi per Amiga, Atari ST ed altre piattaforme. Un pomeriggio Trip Hawkins (il fondatore della Electronic Arts) si presentò al negozio di Kevin, dato che i registri mostravano che lì si vendevano più giochi EA che in qualsiasi altro posto. Trip parlò a Kevin dei suoi giochi preferiti, e anche del suo piano di rendere l'Amiga un successo ancora più grande per giustificare così tutti gli investimenti e l'entusiasmo che aveva dedicato alla piattaforma. Gli disse anche che aveva degli accordi preliminari con delle compagnie giapponesi per produrre delle console basate sul chipset Amiga, e che stava lavorando ad una "scheda Amiga" per gli IBM PC. È difficile dire cosa sarebbe successo alla scena videoludica amighista se questi piani si fossero realizzati, ma in ogni caso la Commodore si premurò di rigettare entrambe le idee.

Ad ogni modo l'industria dei giochi per Amiga prosperò fino alla fine degli anni 80. Man mano che gli sviluppatori svisceravano sempre di più i segreti della piattaforma, l'Amiga cominciò ad acquisire la fama di essere il computer con i giochi migliori. I publisher spesso mettevano gli screenshot della versione Amiga dei giochi sul retro delle scatole, anche di quelle delle versioni per Atari, Commodore 64, e IBM PC, accompagnandole con un "foto della versione Amiga" in piccolo.

I trucchi e le tecniche necessari a realizzare i grandi giochi che si vedevano sull'Amiga non venivano insegnati in nessuna scuola. Per imparare a programmare una macchina, i programmatori spesso iniziavano smanettando con il BASIC integrato (come ad esempio quello del Commodore 64) e gradualmente passavano all'assembly. Quando l'Amiga venne immesso nel mercato, c'erano riviste come Commodore Gazette e MC MicroComputer che al loro interno avevano articoli che ne dettagliavano il funzionamento a livello hardware.

In ogni caso, per capire davvero le potenzialità del chipset dell'Amiga, era una sola la guida di riferimento che davvero contava: l'Amiga Hardware Reference Manual della Commodore stessa. Questo manuale era una vera e propria Bibbia per gli sviluppatori di giochi Amiga. Chi s'impegnava a esplorarlo avrebbe scoperto come il chip Blitter sparasse la grafica direttamente dalla memoria allo schermo, come il Copper desse la possibilità di cambiare il funzionamento del display al volo, come il chip audio liberasse la CPU dall'elaborazione del sonoro, e come la CPU stessa fosse in grado di mettere tutto ciò in sincrono.

Testi sacri

La prima cosa che gli sviluppatori facevano, quando cominciavano a scrivere un gioco, era di disattivare il sistema operativo per ottenere il controllo completo dell'hardware e della memoria. Ciò veniva fatto per risparmiare un po' di memoria e per far sì che i giochi potessero spremere fino all'ultima goccia la potenza dei chip custom. Ciò significava però anche che quando il gioco era in esecuzione non c'era nessuna "rete di sicurezza". Dato che il sistema operativo era disattivato e con esso il multitasking, non era possibile eseguire in contemporanea al gioco dei debugger o degli ambienti di sviluppo integrati. Gli sviluppatori più ingegnosi usavano l'hardware stesso come monitor, facendo cambiare il colore dello sfondo al Copper nei punti chiave del codice.

Quando le cose andavano male, andavano DAVVERO male. Dato che l'Amiga non aveva memoria protetta, se un programma cominciava a scrivere dati al di fuori del suo spazio di memoria, lo schermo cominciava a riempirsi di "fuochi d'artificio" virtuali prima che il sistema si bloccasse. L'unico modo per assicurarsi che tutto funzionasse consisteva nel creare e testare poco alla volta tutte le piccole parti di codice che avrebbero fatto parte del programma definitivo.

Gli sviluppatori di giochi Amiga usavano molti strumenti per il loro lavoro. Per risparmiare tempo, molti usavano anche linguaggi di alto livello, il più diffuso dei quali era il C, per il quale erano disponibili compilatori molto popolari come il Lattice C della SAS, il Manx C ed il DICE.

Ovviamente per avere il massimo in termini di pura velocità e potenza niente era meglio dell'assembly del 68000. Nei primi Amiga la memoria era un lusso: il mercato era popolato da macchine come l'Amiga 500 con i suoi 512 KB (kilobyte, non megabyte!) di RAM, e la RAM a sua volta era divisa tra RAM "chip" (dedicata al display ed ai chip custom) e "fast" (esclusiva per la CPU). Far girare tutto fluidamente, senza sfarfallii e a frame rate alti, richiedeva un'eccezionale destrezza da parte degli sviluppatori.

Considerate ciò che realizzò Cesare Di Mauro, sviluppatore di USA Racing. Voleva che il gioco girasse a 50 frame al secondo perché l'esperienza fosse fluida, ma ciò, a causa della scarsità di RAM, significava che non sarebbe stato possibile usare il double buffering (una tecnica che consiste nel disegnare un secondo fotogramma, successivo a quello corrente, "di nascosto", in modo da averlo già pronto prima di visualizzarlo). Non usare il secondo fotogramma permetteva di risparmiare memoria e tempo d'esecuzione, ma rendeva molto più difficile lo scorrimento dello sfondo e l'aggiornamento dei BOB (Blitter OBjects, gli "sprite" del blitter).

La soluzione di Cesare fu di usare una schermata virtuale di 352x272 pixel, dei quali ne venivano visualizzati solo 320x240. L'area era divisa in due strisce verticali, combinate assieme per mostrare un'unica visuale. Lo sfondo consisteva di tasselli di 32x32 pixel, disposti su un'ampia mappa di 4096x65536 pixel (qualsiasi sviluppatore può facilmente riconoscere questi numeri).

Gestire il numero dei tasselli, i BOB visualizzati sopra di essi, la musica, gli effetti sonori ed il rilevamento delle collisioni con le pareti e le altre auto era un'enorme sfida. Cesare finì per scrivere un programma in assembly che faceva tutto ciò a 50 fotogrammi al secondo, ordinando gli oggetti da disegnare sullo schermo in una display list per massimizzare le performance. Il programma mostrava anzitutto i BOB secondo l'ordine della lista, e quindi aggiornava le aree nascoste ai fini dello scorrimento (per quello orizzontale era sufficiente impostare un valore in un registro perché se ne occupasse il chipset, mentre quello verticale funzionava in maniera simile, ma leggermente più complicata). A questo punto il programma seguiva il pennello elettronico che tracciava lo schermo e, ogni volta che il pennello superava il limite inferiore di uno dei BOB, ripristinava l'area dello sfondo che era stata "sporcata" dal BOB stesso. Cesare scrisse anche delle routine custom per il sonoro e persino per l'accesso al disco, per massimizzare la velocità e minimizzare l'uso di memoria RAM.

Questo delicato bilanciamento nella programmazione era tipico tra gli sviluppatori che volevano creare giochi che spingessero al limite la macchina. Molti dei concetti che emersero dal lavoro di questi sviluppatori finirono, molto tempo dopo, in librerie standard come le DirectX - le display list, ad esempio, sono un elemento cruciale delle Direct3D.

Post precedente | Post successivo