Nei precedenti tre articoli su s.o. & applicazioni, videogiochi 2D e videogiochi 3D mi sono focalizzato sull’Amiga originale (OCS), tralasciando l’ECS (cambia veramente pochissimo e assolutamente nulla rispetto all’argomento grafica planare vs packed), perché ho deciso di trattare separatamente i casi d’uso per l’AGA.
Il motivo principale è che, per quanto l’AGA abbia apportato degli innegabili miglioramenti (d’altra parte erano ben 7 anni che il chipset non veniva cambiato: l’ECS è pochissima roba che ha inciso per niente nei videogiochi e quasi nulla nel s.o. e le applicazioni dotate di interfaccia utente), è arrivato molto tardi su un mercato che ormai era orientato verso la grafica packed e, in particolare, si stava ormai muovendo verso quella cosiddetta High color (15 e 16 bit) e True color (24 e 32 bit).
La grafica planare, insomma, era già in declino, e l’AGA ha rappresentato il classico canto del cigno per le macchine di casa Commodore, con in primis l’abbordabilissimo Amiga 1200 (che costava veramente poco!), il quale ha rappresentato il punto di riferimento per sviluppatori e utenti, per concludersi con la sfortunata CD32 (bloccata negli USA da problemi con un brevetto).
D’altra parte non era nemmeno un mistero che Commodore stesse lavorando a un chipset molto più avanzato e moderno (chiamato internamente AAA), che non era nemmeno pienamente compatibile con l’AGA (dalle informazioni che girano sembra che fosse compatibile, a livello di registri, esclusivamente con l’ECS), con l’obiettivo dichiarato di distaccarsi dall’accesso diretto all’hardware (croce e delizia dell’Amiga e delle macchine che l’hanno preceduto) e forzando, quindi, applicazioni e giochi all’uso delle API del s.o. in qualità di “intermediari” (sancendo la definitiva astrazione dall’hardware).
Sistema operativo e applicazioni dotate di GUI
L’introduzione dell’AGA ha portato con sé la versione 3.0 del sistema operativo dell’Amiga che, e per quanto qui sopra riportato, ha ovviamente visto l’aggiunta di numerose API atte a gestire meglio la grafica, con qualche aggiunta di più basso livello per aiutare i programmatori che avessero voluto utilizzare il s.o. per realizzare giochi e applicazioni, anziché affidarsi nuovamente alla programmazione diretta dell’hardware.
Il problema principale, però, è che questo nuovo chipset non ha consegnato alcun miglioramento nella gestione della grafica planare, col Blitter che è rimasto esattamente lo stesso della versione ECS (la quale, comunque, aveva introdotto soltanto un paio di caratteristiche non molto importanti), e sappiamo bene come questo coprocessore sia stato il vero protagonista dell’Amiga in ambito puramente prestazionale.
Gli aggiornamenti, infatti, hanno riguardato esclusivamente il controllore video e gli sprite, i quali hanno entrambi beneficiato della possibilità di leggere fino a 4 volte più dati dalla memoria, a parità di clock, di fatto quadruplicando la banda di memoria a disposizione, ma esclusivamente per visualizzare la grafica di entrambi (che ha portato a supportare risoluzioni più elevate e sprite larghi fino a 64 pixel).
Fortunatamente ciò ha avuto, indirettamente, un riflesso positivo anche sul lavoro del Blitter, che per lo meno s’è ritrovato con più banda di memoria a disposizione per portare a termine le sue operazioni, con benefici in termini prestazionali che si traducono in una maggior fluidità o con possibilità di supportare/sopportare carichi di lavoro più pesanti.
Cosa comporti, in soldoni, quest’ultima affermazione è che avrebbe potuto, ad esempio, muovere la stessa grafica (in termini di dimensioni e numero degli oggetti spostati) a 128 colori anziché a 32 colori (com’è possibile prendere atto dai calcoli che ho riportato giusto qualche tempo fa nel più famoso forum amighista internazionale).
Quindi e contrariamente a quanto si potrebbe pensare nonché leggere in giro (ancora una volta, leggende metropolitane), con l’AGA non sarebbe stato possibile gestire grafica a 256 colori paragonato a OCS/ECS, ma soltanto a 128 colori (un buon risultato, comunque). A meno di non dover ridurre un po’ la grafica da muovere, ovviamente, per poter utilizzare gli agognati 256 colori.
Dal punto di vista del confronto fra grafica planare e packed non cambia molto rispetto a quanto è stato già ampiamente trattato nei precedenti articoli, che si sintetizza con: la capacità di leggere 64 bit anziché i canonici 16 bit dal bus dati non fa che esacerbare ancora una volta la situazione per la grafica planare, forzando allineamenti ancora più pesanti per la grafica da visualizzare, e riducendo il numero di sprite visualizzati in caso di scroll (soltanto uno a 4 colori!).
Videogiochi 2D
Inutile dire che, e per quanto scritto sopra, dei miglioramenti apportati dall’AGA ne abbiano beneficiato principalmente i giochi, a cominciare da quelli che utilizzano la modalità Dual Playfield, che con OCS/ECS era mortificata dalla possibilità di utilizzare soltanto 8 colori per il primo schermo (il fondale) e solamente 7 per il secondo (per i personaggi e altra grafica accessoria), mentre adesso si passa a 16 e 15 rispettivamente, com’è possibile notare in un altro capolavoro, Shadow Fighter:
I cambiamenti dovrebbero essere ben evidenti, specialmente per i fondali (in particolare la grande stella in basso), ma anche i personaggi ne hanno beneficiato (sebbene sia necessario prestare più attenzione in questo caso).
Dal punto di vista del confronto fra grafica planare e packed la principale differenza che emerge è che adesso, ma solo con quest’ultima, è possibile utilizzare le tile 8×8 di cui abbiamo parlato nel precedente articolo sui videogiochi 2D, ovviamente senza alcuna penalizzazione. Infatti e con 16 colori per schermo un pixel necessita di 4 bit per il suo indice colore e, quindi, 8 pixel richiedono (orizzontalmente) 4 x 8 = 32 bit = 2 word (16 bit) e, pertanto, nessun problema di allineamento!
Utilizzando tile 8×8 sarebbe stato possibile, dunque, dare una mano ai giochi che usano due schermi e che soffrissero di problemi prestazionali, impiegando metà della banda nel caso di scroll orizzontale rispetto alle tile 16×16. Inoltre tile così piccole consentono di risparmiare anche spazio, poiché tante parti del fondale che si ripetono ciclicamente usualmente necessitano di una sola tile 8×8 per riprodurre tutto il motivo.
Altra cosa importante da sottolineare è che in questo caso la CPU potrebbe essere utilizzata allo scopo, in quanto e per questo specifico compito (copiare dati 32 bit alla volta, perfettamente allineati a 32 bit) è veloce almeno quanto il Blitter, con la differenza che non serve programmare i registri di quest’ultimo prima di far partire l’operazione. E’ più facile, quindi, pensare di suddividere i compiti fra processore e coprocessore, in modo da sfruttare meglio l’intero sistema.
Adesso veniamo al piatto forte dell’AGA, ossia la possibilità di poter utilizzare più colori. Si possono utilizzare i famigerati 256 colori, ma con un occhio alla dimensione e numero di oggetti da muovere a schermo, perché la situazione è migliorata rispetto a OCS/ECS, ma non quanto sarebbe necessario per garantire un passaggio di questo tipo, come già riportato in precedenza parlando di s.o. e applicazioni.
Da questo punto di vista l’Amiga si rimette in pari con altre piattaforme, come DOS/Windows in primis, che già da parecchi anni (ben cinque: dall’87 con la VGA per il PC. Anche l’Archimedes, commercializzato sempre nell’87, poteva contare su modalità a 256 colori, ma usando una tavolozza di soli 16 colori, a ognuno dei quali venivano poi applicate 16 gradazioni). Quindi realizzare avventure grafiche, ad esempio, o giochi più colorati, in generale, non era più un grosso problema.
Ciò che, però, risulta più interessante è che era finalmente possibile realizzare molto di più, grazie alla grafica planare e agli 8 bitplane, senza richiedere hardware particolare come per le console. Chiarisco subito che mi riferisco specificamente a giochetti di transparenze o alla simulazione di uno schermo addizionale sovrapposto a quello principale senza ricadere nei limiti del Dual Playfield (massimo 16 colori per schermo).
L’esempio per eccellenza in questo caso caso è rappresentato da quella sublime gioia (almeno per Amiga) che è rappresentata da Banshee, il quale non abbisogna anch’esso di presentazioni:
Come si può vedere da questa schermata, la torretta a destra emana una raggio che tinge di blu tutto ciò che rientra nel suo cono. Quest’effetto di trasparenza si ottiene selezionando accuratamente i colori della tavolozza, ad esempio i primi 64 coi colori che vengono utilizzati per disegnare tutta la grafica (sia il fondale sia i personaggi), mentre i successivi 64 saranno costituiti dai primi 64 ma in tonalità bluastra, per un totale di 128 colori (7 bitplane).
Nel gioco tutto ciò viene implementato avendo cura di disegnare la grafica, ma soltanto nei primi 6 bitplane, mentre e soltanto il raggio verrà disegnato esclusivamente nel settimo bitplane, i cui dati in esso contenuti consentono di decidere se visualizzare la normale grafica dov’è presente un valore 0 in tale bitplane, mentre il valore 1 produrrà la medesima grafica ma in tonalità blu.
Un effetto molto suggestivo e appagante graficamente, col vantaggio addizionale di richiedere pochissimo spazio in memoria (il raggio occupa un solo bitplane!) come pure pochissima banda di memoria (per lo stesso motivo), consentendo anche di risparmiare spazio per la grafica regolare (fondali, oggetti, personaggi) e banda allo stesso tempo. In buona sostanza, si tratta dello stesso effetto che abbiamo utilizzato in Fightin’ Spirit, come abbiamo visto nell’articolo sui giochi 2D, ma che adesso risulta generalizzato (non si è forzati a utilizzare soltanto colori con gradazione dimezzata).
Il rovescio della medaglia è che la grafica vera e propria potrà usare meno colori (64 anziché 128, in questo caso), perché metà della tavolozza risulta necessariamente impiegata per la simulazione di quest’effetto di trasparenza.
La cosa più interessante è che, potendo contare su ben 8 bitplane e la relativa tavolozza da 256 colori, sarebbe possibile implementare effetti di trasparenza più complessi, ad esempio utilizzando tre livelli di gradazione per lo stesso colore oppure semplicemente trasparenze basate su tre colori diversi (rosso, verde e blu, ad esempio), o ancora tre colori opachi (niente trasparenze) o, infine, un misto (una trasparenze e due colori opachi. Due trasparenze e un colore opaco).
In questo caso servirebbero due bitplane utilizzati esclusivamente allo scopo, per consentire di specificare se utilizzare i normali colori oppure una delle tre trasparenze (applicata al colore “base”) e/o colori opachi (che sostituirebbero completamente i colori opachi).
Esempi di questi effetti si trovano nei livelli in cui appare la pioggia (di cui, purtroppo, non ho trovato alcuna schermata a disposizione che non sia protetta da diritto di copia) oppure dov’è presente la neve:
Dunque Banshee sembra utilizzare almeno due bitplane per le trasparenze (tre più i normali colori) quando sono presenti armi laser (non soltanto per il raggio della torretta: ci sono anche altri nemici che sparano laser e che vengono resi, a video, con segmenti di colore trasparente) e sei bitplane (64 colori) per la grafica regolare, sfruttando, quindi, tutti e gli 8 bitplane che l’AGA mette a disposizione.
Tutto ciò non è normalmente possibile con la grafica packed, la quale avrebbe comunque la possibilità di modulare a piacimento la profondità di colore di ogni singolo schermo con un’ipotetica versione AGA. Infatti e come abbiamo visto quando abbiamo parlato della modalità Dual Playfied, i due schermi sono in grado di leggere e gestire la rispettiva grafica in maniera totalmente indipendente anche in termini di profondità di colore (numero di bit impiegati per singolo pixel), mentre il chipset dell’Amiga è forzato a utilizzare i bitplane dispari per il primo schermo e quelli pari per il secondo (quindi sono possibili schermi con al massimo 16 colori = 4 bitplane ciascuno).
L’implementazione di ciò è abbastanza semplice, poiché è sufficiente utilizzare tre bit fra quelli inutilizzati in uno dei diversi registri del controllore video per specificare il numero di bit per pixel per il secondo schermo. Tutto il resto (e come già spiegato in precedenza parlando in dettaglio del nuovo algoritmo alla base del controllore video) funziona già così e non necessita di alcuna modifica.
Questo significa che sarebbe possibile, quindi, specificare di voler utilizzare 6 bit per pixel per il primo schermo e 2 per pixel per il secondo schermo (tanto per fare un esempio di una modalità impossibile con la grafica planare dell’Amiga), e il gioco è fatto (perché con l’AGA è possibile anche specificare quale parte della tavolozza dei colori utilizzare per ogni schermo).
Il limite di questa soluzione è, però, rappresentato dal fatto che i colori del secondo schermo possono essere esclusivamente opachi (niente trasparenze, quindi), perché è esattamente così che funziona la modalità Dual Playfield (si visualizza o la grafica del secondo schermo, oppure quella del primo se l’indice colore del secondo schermo vale zero).
Ottenere le trasparenze è possibile a patto, però, di operare un’altra modifica, che questa volta impatta leggermente il controllore video. Infatti è necessario utilizzare un bit (fra quelli liberi) in uno dei registri del controllore video per abilitare la possibilità di shiftare a sinistra (fino a sette posizioni. Usando, in questo caso, il campo che indica il numero di bit per pixel del primo schermo) l’indice colore del secondo schermo per poi combinarlo (con un’operazione di or binario) con l’indice colore del primo schermo. Il valore risultante rappresenta il colore da andare a prelevare dalla tavolozza dei colori, che è organizzata come spiegato in precedenza.
Quindi, e per fare un esempio, se il primo schermo usa 64 colori (6 bit per pixel) mentre il secondo 4 (2 bit per pixel) e un pixel visualizzato nel primo ha valore %101101 (in binario) mentre quello del secondo schermo ha valore %01 (sempre in binario), se il nuovo bit di cui sopra è impostato (a 1, ovviamente) allora il controllore video prenderà l’indice del secondo schermo (%01), lo shifterà a sinistra di 6 posizioni (perché il primo schermo utilizza 6 bit per ogni pixel) e ne farà l’or binario con l’indice del pixel del primo schermo (%101101) ottenendo, infine, il valore %01101101 (che sarà l’indice del colore da prelevare dalla tavolozza).
Il costo implementativo è consistente, in quanto serve utilizzare un barrel shifter di 8 bit fino a 8 posizioni, ma abbiamo visto che il controllore video packed in versione AGA consente di risparmiare talmente tanti transistor che c’è l’imbarazzo della scelta sul come impiegarli (si potrebbe anche pensare di implementare il meccanismo di “espansione” della grafica di cui ho già discusso, ma non ne vale la pena), e l’implementazione di questa nuova modalità Dual Playfield ne richiederebbe soltanto una piccola parte.
Un’altra cosa da sottolineare è che il trucchetto delle trasparenze per la versione planare deve per forza fare i conti con le impostazioni dello scroll, che devono coincidere per i due pseudo-schermi che sono simulati. Quindi tale scroll non può più essere indipendente, come avviene con la modalità Dual Playfield, ma entrambi gli “schermi” dovranno usare lo stesso valore (scrolleranno sempre nella stessa direzione) per cui i programmatori ne dovranno tenere conto (a parte la complessità di programmazione, si tratta anche di una questione di efficienza: se lo schermo principale scrolla, anche il secondo dovrà farlo, con annesso spreco di risorse).
La versione packed, invece, fa proprio uso del Dual Playfield, per cui i due schermi sono realmente e totalmente indipendenti, con i vantaggi che ne derivano (vedi sopra).
Videogiochi 3D
Per i giochi 3D non è stato apportato alcun contributo specifico dal chipset AGA, perché le modifiche sono relative esclusivamente al controllore video e servono soltanto per visualizzare più colori anche a risoluzioni elevate, come già detto. Non v’è assolutamente nulla, insomma, che possa avvantaggiare i giochi 3D, fatta eccezione per il fatto che il Blitter ottiene più slot liberi per accedere in memoria (a parità di risoluzione e numero di colori visualizzati), come già ampiamente trattato.
Per contro, invece, il solo fatto di poter avere una versione packed del chipset AGA consentirebbe di poter implementare giochi 3D più moderni, facenti uso di tecniche di texture mapping, come già anticipato da Wolfenstein 3D:
e successivamente esploso con Doom:
Ora, non è che un Amiga con AGA non possa realizzare giochi del genere. Infatti ne esistono diversi 3D che usano texture mapping e alcuni che girano anche su un Amiga 1200 base/originale (inespanso: “nudo” come mamma Commodore l’ha fatto).
Il problema aggiuntivo che, però, hanno queste macchine è che la CPU non soltanto deve elaborare tutta la scena da sola (senza aiuto da parte del Blitter) in un framebuffer con grafica packed (chiamata anche chunky, in gergo, quando si usa una tavolozza dei colori. In particolare questo temine è diventato famoso con 256 colori), ma si deve far carico della conversione in grafica planare (l’unica che il controllore video dell’Amiga riesce a visualizzare).
Come si può immaginare, questo processo di conversione da packed/chunky a bitplane è abbastanza oneroso, portando via un bel po’ di capacità di elaborazione della CPU e, quindi, influendo sulla fluidità della grafica del gioco (il numero di fotogrammi al secondo che si possono generare).
Per far capire l’impatto che può avere, riporto qualche numero di un utente di un forum amighista che ha misurato questo tempo di calcolo usando una routine di un gioco 3D molto famoso per Amiga, Gloom: 61.6ms sono richiesti per un Amiga 1200 liscio per convertire un intero frame (320×200 a 256 colori), che equivalgono a circa 3.7 frame (su 60 al secondo, per un sistema NTSC. Un frame in questo caso richiede 16.67ms). Quindi quasi 4 frame sono richiesti soltanto per quest’operazione: un valore enorme (che sarebbe nullo semplicemente usando grafica packed)!
Molto probabilmente questo è il motivo per cui gli ingegni Commodore decisero di metterci una pezza, aggiungendo a un chip (Akiko) della CD32 un circuito che aiutasse allo scopo, ma l’idea era timida (anche perché non hanno perso molto tempo per pensarci: pare sia stata elaborata durante un pasto dei due ingegneri che se ne stavano occupando) e l’implementazione abbastanza scarsa (considerato che era in ogni caso la CPU a doversi occupare di passare i dati chunky ad Akiko, per poi estrarne i risultati, e infine copiarli sullo schermo da visualizzare).
Nonostante tutto, il risultato era in ogni caso buono, considerato che tale operazione richiedeva molto meno tempo: soltanto 24.2ms sono richiesti in questo caso, equivalenti a circa 1.45 fotogrammi (sempre considerando 60 frame al secondo per NTSC). Questa circuiteria presente in Akiko, quindi, richiede soltanto il 40% del tempo rispetto alla CPU (o, viceversa, si può anche dire che è una volta e mezza più veloce).
Poi c’è comunque da aggiungere che giochi come Doom erano decisamente impegnativi per un 68020 a soli 14Mhz, anche senza tener conto della suddetta conversione che era aggiuntiva al mero tempo di calcolo della scena. Purtroppo non ci sono benchmark per un 1200 base, poiché Doom richiedeva più di 2MB di memoria per funzionare, per cui i benchmark che ho trovato hanno tutti i sistemi testati dotati di espansione di memoria.
Dai numeri si può vedere che la CD32 (espansa con 8MB di memoria Fast) genera 3.9 FPS utilizzando esclusivamente tale CPU, mentre arriva a 5.8 FPS sfruttando la circuiteria di Akiko per la conversione di cui sopra: quasi il 50% più veloce! Questo a ulteriore dimostrazione di quanto comodo avrebbe fatto la grafica packed in questo caso (perché avrebbe consentito di generare ancora più fotogrammi al secondo rispetto alla miglior soluzione che usa Akiko).
Sintesi Finale
Con ciò si chiude anche la carrellata dei casi d’uso per gli Amiga basati sul chipset AGA, confrontati con un equivalente packed. E direi che ci sia ben poco da sintetizzare, perché con l’AGA i vantaggi di una soluzione packed non potevano che aumentare, specialmente tenendo conto del peso che il 3D aveva ormai assunto in quel periodo.
Il prossimo numero porterà a compimento questa lunghissima serie dedicata a un’ipotetica versione “packed” dell’Amiga (confrontata con l’originale), le cui conclusioni anticipo non saranno affatto scontate: c’è ancora un po’ di succulenta carne da mettere al fuoco…
