Avevamo già parlato in maniera dettagliata della modalità HAM dell’Amiga in un articolo di un po’ di mesi fa, sviscerando (specialmente sul piano tecnico) tutte le problematiche che l’attanagliano e, quindi, per quali motivi sia stata utilizzata raramente, relegandola per lo più a visualizzare immagine statiche o filmati/animazioni.
Gli animi si sono, però, riaccesi nuovamente quando, in un thread del più grande portale dedicato all’Amiga, è stato pubblicato il video di una demo in HAM, dallo stesso autore del gioco Hamulet (che è stato oggetto del precedente articolo sull’argomento), il quale ha mostrato altre meraviglie visive:
La demo è sicuramente spettacolare, perché c’è parecchia roba in movimento sullo schermo (con una notevole fluidità!) e il tutto risulta estremamente carico di colori (come ci si aspetta dall’HAM, che consente di visualizzare fino a 4096 colori rispetto ai massimo 64 consentiti da un Amiga OCS/ECS).
Lecito chiedersi, a questo punto, se sia cambiato qualcosa rispetto al precedente articolo che parlava proprio del motore grafico di Hamulet e del suggestivo impatto che la sua grafica ha stampato nelle menti di chi s’è gustato il video con la demo del gioco in azione.
Tante animazioni… “statiche”!
La cosa che salta subito all’occhio è, per l’appunto, la quantità di oggetti che si muovono: tanti, anche di grandi dimensioni, e ovviamente pieni di colore. Tecnicamente, però, non è cambiato nulla: i limiti dell’HAM che sono stati meticolosamente analizzati in precedenza sono tutti lì.
Infatti ciò che non deve far ingannare è proprio la presenza della moltitudine di roba che si muove in diverse parti dello schermo, che può far pensare diversamente, mentre e in realtà si tratta pur sempre di parti “statiche”, e più precisamente di animazioni dello sfondo.
Non sono, quindi, oggetti in grado di muoversi liberamente come un qualunque sprite o BOB (Blitter OBject: simili agli sprite, ma realizzati adoperando il coprocessore grafico per eccellenza dell’Amiga: il Blitter!), ma sono vincolati a precise posizioni (orizzontali che sono multipli di 16, per essere ancora più precisi, in quanto i dati della grafica su Amiga OCS/ECS sono sempre allineati a 16 bit/pixel).
Un esempio che chiarisce il concetto è rappresentato dal “mostro verde” che rimane ben fermo nella stessa posizione dello schermo, pur essendo lanciato verso una corsa sfrenata:
Dovrebbe scorrere orizzontalmente, se si muovesse in maniera naturale, anziché rimanere fisso nello stesso posto. Invece occupa sempre la stessa posizione, sebbene i suoi movimenti indichino che dovrebbe fare diversamente.
Per cui si tratta, come già detto, di un’animazione dello sfondo, e queste non hanno particolari problemi (ma se dovessero occupare troppo spazio per essere conservati nella memoria “Chip“ si dovrebbe far ricorso alla cosiddetta memoria “Fast“, costringendo la CPU a farsi carico della loro visualizzazione), a parte, ovviamente, gli artefatti grafici che compaiono quando si utilizza questa particolare modalità video dell’Amiga.
I difetti dell’HAM
Un esempio in merito lo si può vedere dalla camionetta (van) che è stata presa direttamente dagli asset di Metal Slug 3:
All’apparenza risulta molto colorato, ma ciò è dovuto anche e soprattutto ai summenzionati artefatti. Lo si può notare meglio prendendo l’originale che è stato estratto dalle ROM del gioco:
Al di là del fatto che la grafica dello schermata presa dalla demo risulti molto più smussata (causa compressione operata da YouTube), confrontando i due soggetti salta subito all’occhio come il primo sia infestato da copiose variazioni sul verde (inesistenti nell’originale), accompagnate da sporadiche macchioline tendenti all’arancione, e infine con la classica “striatura” che è possibile ammirare nella seconda fiamma (a destra, con diverse linee in verde. Alcune visibili anche sul frontale del mezzo).
Si tratta, chiaramente, degli effetti delle transizioni dei colori che avvengono in modalità HAM quando, passando da un pixel al successivo, il colore necessario non è disponibile fra i 16 della palette base / fissa e bisogna, quindi, cambiare una delle tre componenti cromatiche (rosso, verde, o blu) per cercare di avvicinarvisi.
Roba nota per chi conosce il funzionamento di questa modalità, ma che è necessario precisare per i non addetti ai lavori, i quali possono pensare che effettivamente nello schermo si possano utilizzare liberamente i 4096 dell’intera tavolozza cromatica messa a disposizione dall’Amiga.
In realtà i colori base sono 16, per l’appunto, e tutti gli altri vengono “ricavati” cambiando una componente cromatica alla volta. Per cui se un certo colore non è disponibile, per ottenerlo saranno necessari fino a tre passaggi successivi (uno per componente da cambiare) in tre pixel adiacenti orizzontalmente.
Dovendo condividere i 16 colori base con tutti i pixel della schermata, si può capire bene da dove arrivino gli artefatti grafici di questa modalità: non si possono accontentare le esigenze tutti i pixel, ma bisogna “mediare” per ottenere il miglio compromesso possibile (il che significa scegliere i 16 colori fissi in modo da ridurre al minimo le transizioni cromatiche).
L’esempio della camionetta calza a pennello anche perché l’originale non è affatto ricco di colori: tutt’altro! Infatti ne vengono usati soltanto 15 (uno, il magenta, è impiegato per “forare” la grafica e visualizzare quella dello sfondo), com’è tipico dei giochi del Neo Geo (e di tante altre console dell’epoca).
Pochi colori dunque, e molti abbastanza omogenei (verde militare per il mezzo e arancio/giallo delle fiamme), ma che sono sufficienti a mostrare gli artefatti visivi che vengono introdotti dalla modalità HAM quando deve rendere la grafica del van.
L’altro/alto prezzo da pagare: lo spazio
Il risultato, comunque, non è affatto male, sia chiaro, ma proprio perché parliamo di animazioni fisse (oggetti che in realtà non hanno piena libertà di movimento, come già ampiamente illustrato), le quali si possono (e si devono!) precalcolare in modo da ridurre il più possibile gli artefatti (che, invece, sarebbero di gran lunga più visibili se si tracciasse grafica arbitrariamente sullo schermo, come avviene usualmente nei giochi che non usano l’HAM).
Ed è proprio perché abbiamo a che fare con roba precalcolata che viene fuori un altro grosso difetto / limite derivante dall’utilizzo della modalità HAM: lo spazio. Ne serve, infatti, parecchio per contenere quello di queste animazioni, poiché è necessario memorizzare tutta l’area rettangolare (sempre in multipli orizzontali di 16 pixel/bit) che racchiude la parte animata.
Questo non è abbastanza chiaro a primo acchito, perché bisogna riflettere sugli elementi fondamentali su cui è basata la grafica di un gioco: le tile e gli sprite (e anche i BOB per l’Amiga). Il concetto che li accomuna è quello del riutilizzo della grafica, proprio in ottica di risparmiare preziosa (specialmente per quell’epoca: anni ’80-’90) memoria, usando le tile per “comporre” la grafica dello sfondo e gli sprite per gli oggetti che si spostano liberamente (in genere).
Adesso provate a immaginare il “mostro verde” di cui sopra che, anziché rimanere in posizione fissa, si muova orizzontalmente. Mettiamo che la sua animazione sia costituita da 8 fotogrammi che si ripetono ciclicamente e che si sposti di un certo numero di pixel orizzontalmente.
Se per renderlo a video fosse utilizzato un BOB (non è possibile usare sprite perché sono impegnati per altri oggetti), lo spazio richiesto in memoria per la sua grafica sarebbe sempre lo stesso (per semplificare: 8 volte lo spazio occupato dalla regione rettangolare che lo racchiude). Questo perché ogni volta basta tracciare la grafica del fotogramma attuale alla nuova posizione dello schermo.
In modalità HAM, però, questo genererebbe parecchi artefatti visivi, per cui per emulare quanto è stato realizzato nella demo bisognerebbe precalcolare tutta la grafica in questione in modo da incastrare la grafica del mostro con lo sfondo, provvedendo a smussare i punti di passaggio dalla grafica del mostro a quello dello sfondo, e viceversa (operazione che è stata fatta per tutte le animazioni della nuova demo).
Una volta ottenuti i blocchi rettangolari con la grafica mostro + sfondo fusi assieme basterebbe, infine, copiarli nell’apposita posizione sullo schermo (sempre a multipli orizzontali di 16 pixel/bit) dove devono essere visualizzati, e il gioco è fatto!
Tutto molto semplice, ma il problema dello spazio si presenta se l’oggetto dev’essere spostato, ad esempio, in 32 posizioni diverse nello schermo. In questo caso bisognerà ripetere l’operazione di “fusione” degli 8 fotogrammi del mostro con la grafica delle 32 diverse posizioni in cui dovranno essere visualizzati. Richiedendo, quindi, ben 32 volte lo spazio di un fotogramma contro gli 8 che sarebbero normalmente necessari con un BOB.
Si tratta, in sostanza, di generare e poi utilizzare nuova grafica ogni volta che c’è una posizione da ricoprire sullo schermo da parte di un determinato oggetto. Il che è ancora gestibile finché gli oggetti non sono molti e poche sono pure le posizioni che ricoprono (perché i loro movimenti sono molto veloci, ad esempio), ma diversamente lo spazio richiesto sale troppo velocemente, come si può intuire.
Sovrapposizione della grafica e libertà di movimento
La situazione viene esacerbata nel caso in cui si dovessero fare i conti con oggetti che possono anche sovrapporsi fra di loro. Anche qui, farli coincidere con precise posizioni dello schermo non sarebbe un grosso problema, perché rientrerebbe nel discorso fatto in precedenza.
Se, però, i movimenti dei due oggetti non sono perfettamente cadenzati / sincronizzati e, quindi, si possono incontrare occasionalmente, allora bisognerebbe generare la grafica per ogni combinazione fra loro possibile, facendo letteralmente esplodere il consumo di memoria.
Il che porta, infine, a intuire il motivo per cui è letteralmente impossibile pensare di poter impiegare BOB per oggetti in grado di muoversi liberamente sullo schermo (ad esempio dei personaggi): servirebbe memorizzare la grafica risultante dalla combinazione di ogni animazione dell’oggetto con ogni posizione in cui è possibile visualizzarlo!
Basta prendere uno dei boss di Metal Slug 3 che ha più libertà di movimento per rendersene conto:
Immaginate di dover “fondere” la sua grafica con quella dello sfondo in tutte le posizioni in cui si può trovare, combinate con tutti i fotogrammi delle animazioni di cui è stato dotato, e si può già vedere come lo spazio richiesto esploderebbe, richiedendo l’impiego di un disco rigido o un CD-ROM per il gioco!
Conclusioni
Tornando nuovamente coi piedi per terra, non c’è dubbio che il lavoro fatto con la nuova demo sia pregevole e degno di ammirazione, ma rimane un caso abbastanza isolato nonché adatto al tipo di gioco per il quale il suo motore grafico è stato realizzato.
Niente di generalizzabile, insomma, anche se è certamente possibile impiegarlo in altri giochi in modalità HAM in cui i seguenti requisiti possano (e debbano) essere soddisfatti:
- utilizzo di sprite per tutti gli oggetti che si muovano (abbastanza) liberamente;
- utilizzo di grafica precalcolata per simulare oggetti in movimento in posizioni specifiche sullo schermo (le classiche animazioni predefinite) — compatibilmente con lo spazio a disposizione.
Diversamente è bene spegnere subito gli animi, poiché la modalità HAM porta con sé delle intrinseche problematiche che non è possibile superare, ed è bene che i sognatori a occhi aperti se ne facciano una ragione una volta per tutte…
