Abbiamo lasciato Ken e Roberta dopo che avevano preso l'importantissima decisione di mettere a frutto le capacità grafiche in bitmap dell'Apple II per creare un gioco d'avventura che, oltre al testo, avesse delle immagini. Roberta era ben consapevole di non essere un'artista, ma era anche determinata a creare dei disegni che facessero al caso loro: in un mondo in cui non si era mai vista un'avventura grafica, la gente non si sarebbe certo soffermata troppo a criticare l'aspetto estetico della prima, no?

Per riuscirci però i due dovevano prima superare almeno due sfide: trovare un modo per importare le immagini nell'Apple II e trovare un modo immagazzinarle in maniera tale che non occupassero troppo spazio sul disco. Quest'ultimo problema sorgeva perché Ken e Roberta intendevano fornire immagini per tutte le location del gioco, per un totale di circa 30 illustrazioni.

Creare delle immagini sull'Apple II era un'impresa non da poco agli inizi del 1980, non solo a causa della penuria di programmi di disegno utilizzabili allo scopo, ma anche per la mancanza di uno strumento di input adeguato: i mouse sarebbero arrivati solo molti anni dopo, e disegnare con un  joystick, una trackball, o con la tastiera era inevitabilmente approssimativo e frustrante. Ken e Roberta finirono quindi con l'acquistare un goffo aggeggio chiamato VersaWriter.

Il VersaWriter era troppo impreciso per poterlo usare per il disegno a mano libera. Presupponeva invece che l'utente inserisse un bozzetto sotto la superficie trasparente dell'area di disegno, per poi ricalcarlo utilizzando l'apposito pennino. Tale prodotto era commercializzato come uno strumento per inserire diagrammi (diagrammi di flusso, circuiti, planimetrie, ecc.) nell'Apple II; anche per questo il software incluso nel pacchetto non gestiva bene le linee irregolari e gli schemi tipici delle illustrazioni vere e proprie. A dire il vero l'anno prima la stessa Apple aveva commercializzato una tavolozza da disegno molto più adatta per le illustrazioni. Tuttavia la tavolozza della Apple costava 650 dollari, mentre il  VersaWriter ne costava meno di 200. Ancora incerto sul destino della loro impresa e intenzionato a risparmiare quanto più possibile, Ken scelse il VersaWriter. Ora però doveva trovare un modo di farlo funzionare per lo scopo che avevano in mente. Come ogni buon hacker, si mise prontamente al lavoro, scrivendo un suo software che lo facesse funzionare. Nel farlo, risolse anche la seconda sfida, seppur in modo quasi del tutto accidentale.

Immagazzinare 30 o più immagini su disco come una semplice griglia di pixel avrebbe consumato molto più spazio di quanto Ken ne avesse a disposizione su un singolo disco. Quindi, se voleva evitare la scocciatura di far uscire un gioco su molti dischi (chiedendo all'utente di scambiarli nel lettore all'occorrenza), doveva trovare un metodo più efficiente. Poiché all'epoca non si parlava nemmeno di standard di compressione grafica (e, se anche lo si fosse fatto, probabilmente sarebbero comunque stati superiori alle capacità di elaborazione del piccolo 6502 della Apple), a Ken venne l'idea di immagazzinare ogni singola immagine non come dati (che tutti insieme andavano a comporre il prodotto finale), ma piuttosto come una serie di comandi di disegno, che potevano essere usati per ricreare l'immagine finale da zero. In altre parole, invece che essere prese direttamente dal disco, le immagini di Mystery House venivano “dipinte” da zero dal computer ogni volta che dovevano essere visualizzate (o, per chi preferisce un linguaggio più tecnico: venivano immagazzinate come grafica vettoriale e non come grafica raster). L'aspetto veramente elegante del tutto è che i comandi di disegno utilizzati per crearle corrispondevano esattamente ai movimenti del pennino che li aveva tracciati sul VersaWriter. E quindi, per immagazzinare la grafica, Ken doveva solo “registrare” i movimenti del pennino mentre questo ricalcava i semplici disegni di Roberta, per poi “riprodurre” tali movimenti sullo schermo ogni volta che il gioco ne aveva bisogno. Un piccolo trucco da maestro, che ci mostra però quanta strada avesse fatto Ken come programmatore dai tempi in cui era solo un giovane allievo del Control Data Institute.

Con l'aggiunta di un semplice parser e di un “world model” più o meno equivalente a quello dei giochi di Scott Adams, il gioco finale aveva questo aspetto:No, la  grafica non è particolarmente attraente. Se mi si permette di scendere un attimo nel tecnico, andare a indagare il perché abbiano questo aspetto è indubbiamente un ottimo esercizio di “storia delle piattaforme informatiche”.

La normale modalità “Hi-Res” dell'Apple II forniva una modalità di visualizzazione bitmap a 280X192 pixel. Tuttavia il programma può opzionalmente scegliere di riservare i 32 pixel in basso dello schermo per visualizzare la parte finale del normale schermo testuale dell'Apple II, che vive infatti di vita propria in un altro punto della memoria. Quest'ultima modalità si dimostrò perfetta per un gioco come Mystery House, oltre che per molti altri che sarebbero arrivati di lì a poco da parte della On-Line Systems e di altri. Poiché lo schermo testuale resta in essere, anche se nascosto altrove, c'era una caratteristica assai comoda che era particolarmente facile da programmare: il giocatore poteva, semplicemente premendo invio su una linea vuota, fa sparire l'immagine, rivelando così tutte le sue ultime mosse.Bastava premere di nuovo il tasto invio per riportare immediatamente l'immagine hi-res in sovrimpressione, essa infatti era stata a sua volta “nascosta” in memoria. Nel 1980 questa era roba da esperti, ma l'Apple II la rendeva banale. Ed era praticamente perfetta per un gioco come Mystery House, quasi come se Wozniak avesse previsto proprio questo specifico utilizzo quando l'aveva progettata.

Ma ora forse vi chiederete il perché di quegli strani colori nelle illustrazioni. Per potervi rispondere dobbiamo analizzare più in profondità il funzionamento della modalità hi-res.

Un display di grafica bitmap è normalmente contenuto in memoria sotto forma di una lunga stringa di bit, che vengono costantemente presi e stampati a schermo. L'esatta quantità di memoria necessaria per far questo dipende, in modo del tutto evidente, dalla risoluzione del display. Ma, in modo leggermente meno evidente, dipende anche dal numero di colori della palette utilizzata. Se utilizziamo solo 2 colori (di solito il bianco e il nero), ci servirà un solo bit per ogni pixel. Se invece vogliamo utilizzare più colori, avremo bisogno di più memoria. Una palette a 256 colori, per esempio, richiede 8 bit (o 1 byte) per immagazzinare ogni singolo pixel. Voi probabilmente oggi starete leggendo queste parole su un monitor a colori a 24-bit con una palette di ben più di 16 milioni di colori, che richiede ben 3 byte per rappresentare ogni singolo pixel (e pensate che questa modalità è spesso inaccuratamente definita a 32-bit perché l'hardware moderno è ben felice di sprecare un intero byte per ogni pixel per tenere tutto allineato in modo ordinato).

Numeri come questi erano ovviamente inconcepibili nel 1980. L'Apple II Plus in modalità hi-res offriva solo 6 colori. Applicando le nozioni apprese al primo anno di informatica, potete facilmente dedurre che servirebbero 3 bit per ogni pixel per immagazzinare i bitmap dell'Apple II secondo il metodo convenzionale (a dire il vero, usando 3 bit avremmo un range di numeri possibili compreso fra 0 e 7, che sono anche troppi; 2 bit però risulterebbero invece troppo pochi). Facciamo un rapido calcolo: 3 bit per pixel * 280 pixel orizzontali * 192 pixel verticali = 161,280 bit, ovvero (dividendo per 8) 20,160 byte (cioè un po' meno di 20 kB). Ora, considerate che in totale abbiamo 48 kB di memoria disponibile sull'Apple II; questo significa che dedicare quasi metà di tale memoria al display grafico sarebbe assolutamente insostenibile, se vogliamo al contempo usare dei programmi con quel minimo di complessità che permetta loro di trarre un qualche vantaggio dalla modalità hi-res stessa.

Wozniak era ben consapevole di questo e -come in molte altre aree dell'Apple II- trovò un modo per fare di più con meno. Piuttosto che dedicare 3 bit a ogni colore, ve ne dedicò solo 1, riservando però anche un bit di ogni byte a uno scopo speciale, di cui vi parlerò fra un attimo. Poi definì una serie di semplici regole per determinare di quale colore sarebbe potuto essere ogni pixel. Se un bit non è impostato, anche il pixel corrispondente sullo schermo sarebbe stato “spento”, cioè nero. Se un bit è acceso, e anche il bit alla sua sinistra e/o quello alla sua destra è acceso, allora quel pixel apparirà bianco. Se un bit è acceso, è su una coordinata pari dell'asse x, e i bit adiacenti sono entrambi spenti, allora quel pixel apparirà viola o blu, in base al fatto che l'ottavo bit riservato sia accesso o spento. Un bit su una coordinata dell'asse x dispari nella medesima situazione seguirà le stesse regole, ma sarà di colore verde o arancione. Una tale impostazione ci permette di immagazzinare una schermata 280X192 a 6 colori usando solo 7680 byte. Tuttavia ciò implica tutta una serie di restrizioni:

• - Un pixel bianco deve avere almeno un altro pixel bianco a sinistra o a destra (in altre parole, una linea bianca verticale a schermo deve essere larga almeno 2 pixel)
• - Un pixel su una coordinata orizzontale pari può essere bianco, nero, viola, o blu, ma non verde o arancione. Tuttavia, se il bit in questione è spento e se c'è un pixel colorato adiacente, il suo colore “stinge” andando a colorare anche tale pixel (che altrimenti sarebbe stato nero).
• - In modo del tutto simile, un pixel su una coordinata orizzontale dispari può essere bianco, nero, verde, o arancione, ma non viola o blu, ed è a sua volta soggetto all'effetto di cui sopra.
• - Ogni linea orizzontale è composta da 280 pixel, che però sono divisi in 40 gruppi di 7. I pixel all'interno di un gruppo possono essere viola o verdi, oppure blue o arancioni, ma non sono concesse combinazioni (in altre parole, un singolo gruppo di 7 non può contenere contemporaneamente pixel viola e blu, oppure verdi e arancioni, ecc.)
• - Perché un singolo pixel sia colorato di nero a schermo, almeno un bit adiacente al bit in memoria che lo rappresenta deve essere nero (in altre parole una linea nera verticale -esattamente come una linea bianca verticale- deve essere larga almeno 2 pixel).

Tenendo tutto questo a mente (ed è alquanto faticoso...), si capisce che sarebbe più accurato affermare che l'Apple II ha una risoluzione orizzontale di soli 140 pixel, visto che il colore di ogni pixel viene completamente controllato dal pixel a esso adiacente.  Considerato tutto questo, unito alla difficoltà estrema di lavorare in modalità hi-res, c'è da chiedersi se tutti questi barocchismi valessero davvero il mal di testa necessario a comprenderli. La tendenza di Woz a produrre roba del genere in nome dell'efficienza è uno degli aspetti più problematici di colui che altrimenti sarebbe un ingegnere generalmente brillante (pensate a come l'Atari dovette rifare da capo il progetto del Breakout di Woz, perché nessuno riusciva a comprenderlo; un fatto che -per quanto sia diventato una leggendaria dimostrazione del genio di Woz- in realtà, da un certo punto di vista, lo mette in una luce peggiore di quanto non faccia con gli ingegneri dell'Atari...). Date di nuovo un'occhiata all'immagine sopra. Notato come le linee verticali siano tutte verdi e viola, mentre le orizzontali siano tutte bianche? Ken poteva realizzare quelle linee verticali bianche solo raddoppiandone lo spessore e rinunciando ad ogni proporzione. L'Apple II non consente -letteralmente!- quei semplici tratti bianchi e neri che lui voleva mostrare. Pazzesco, eh?

Questi strani schemi di colori (per non parlare dei toni pastello dei colori stessi) rendono -ieri come oggi- il display dell'Apple II istantaneamente riconoscibile a chiunque ci abbia passato del tempo davanti. E se il suo display è insolitamente caratteristico, in questo campo l'Apple II è in buona compagnia: tutte le immagini prese dai primi microcomputer sono caratterizzate da indizi che ne rivelano la loro origine. È una di quelle cose che rendono queste vecchie macchine così attraenti per chi vive nel nostro moderno mondo di anonima perfezione tecnologica. Chiamatela personalità o, se preferite, chiamatela... anima.

Il che non significa, ovviamente, che gli utenti dell'epoca non abbiamo compiuto ogni sforzo possibile per trovare dei modi per superare tali basiche limitazioni. Ma di questo parleremo più a fondo in seguito. Nel prossimo post invece vedremo com'è giocare a Mystery House e indagheremo il ruolo che ha avuto nel suo contesto storico. 

The Digital Antiquarian è un blog, scritto da Jimmy Maher, che si occupa di storia e di cultura del videogioco partendo dall'analisi di singoli videogiochi. OldGamesItalia è lieta di presentarvi la traduzione italiana, autorizzata dall'autore!
Se anche voi apprezzerete questo interessantissimo blog, non mancate di visitare la pagina ufficiale (in lingua inglese) e di sostenerlo tramite Patreon.

Traduzione a cura di: The Ancient One
Editing a cura di: Festuceto

Articoli precedenti:

- Sulle tracce di The Oregon Trail
- In difesa del BASIC
- A Caccia del Wumpus
- L'Avventura di Crowther
- TOPS-10 in a Box
- L'Avventura completata
- Tutto il TRaSh del TRS-80
- Eliza
- Adventureland
- Dog Star Adventure
- Qualche domanda per Lance Micklus
- Un 1979 indaffarato
- The Count
- Due diverse culture di avventurieri
- Microsoft Adventure
- La Narrativa Ludica già nota come Storygame
- L'Ascesa dei Giochi Esperienziali
- Dungeons And Dragons
- Una Definizione per i Giochi di Ruolo per Computer
- Dal Tavolo al Computer
- I Primi Giochi di Ruolo per Computer
- Temple of Apshai
- Un 1980 Indaffarato
- L'Interactive Fiction di Robert Lafore
- Cestinando il Trash del TRS-80
- Jobs e Woz
- L'Apple II
- Eamon, Parte 1
- Un Viaggio nel Fantastico Mondo di Eamon
- Eamon, Parte 2
- Il mio Problema con Eamon
- Ken e Roberta


Visita il sito ufficiale di The Digital Antiquarian
Discutiamone insieme sul forum di OldGamesItalia!