Lezione 03: SGDK ed il VDP (Parte 1)
Cosa ha fatto l'SGDK alle nostre spalle?
Nonostante abbiamo scritto solo poche righe, l'SGDK si è occupato per noi di molti aspetti non evidenti dal sorgente che abbiamo scritto. Ad esempio, prima ancora che fosse seguito il main(), l'SGDK ha:
- Impostato i valori predefiniti per ciascun registro del VDP (il processore grafico del Mega Drive)
- Ripulito la video RAM
- Settato le 4 palette con, in default: grigio, rosso, verde e blu
- Caricato un font predefinito (che noi abbiamo utilizzato per scrivere il messaggio)
- Inizializzato la gestione degli input
- Inizializzato la gestione suono e musica
- Caricato un driver audio predefinito
Per capire ancor più la comodità dell'uso dell'SGDK dobbiamo innanzitutto partire dal conoscere un pò di più l'hardware del Mega Drive e, sicuramente, il VDP è il punto di partenza migliore perchè le capacità e le limitazioni grafiche sono quelle che più caratterizzarono le console a 16-bit.
Conosciamo il VDP
L'obiettivo di questa lezione è quella di fornire una rapida panoramica del VDP in ca. 15 minuti sufficienti a consentirvi di manipolare i layer di tile, gli sprite, e creare dei primi giochi, indicarvi come poterne capire maggiormente come sono realizzati i migliori titoli per Mega Drive e fornirvi i riferimenti a documentazione di dettaglio qualora siate intenzionati a saperne ogni dettaglio.
1) Nazionalità, risoluzioni e tile
Partiamo dal conoscere un minimo di storia. VDP sta per Video Display Processor ed è il principale processore grafico del Mega Drive, costruito sul modello precedente, il VDP del Master System che, a sua volta, era costruito sul modello del Texas Instruments TMS9918. Per questo motivo abbiamo che il processore espone differenti modalità grafiche:
- Mode 0,1,2,3 - Specifici del TMS9918
- Mode 4 - Modalità Sega Master System
- Mode 5 - Modalità Mega Drive
Chiaramente ci occuperemo di quest'ultima modalità. Nel "Mode 5" il Mega Drive offre due principali risoluzioni che vanno distinte a seconda della nazionalità della macchina.
- Se parliamo di una macchina NTSC (Nord America o Giappone), abbiamo una macchina a 60hz e risoluzioni che possono essere 320x224 (Modo H40) o 256x224 (Modo H32, usato pochissimo).
- Se parliamo di una macchina PAL (Europa), abbiamo una macchina a 50hz e risoluzioni che possono essere 320x240 (Modo H40) o 256x240 (Modo H32, usato pochissimo).
Visto che il VDP tratta tutta la grafica come tiles, ovvero pezzetti di immagine grandi 8x8, queste risoluzioni si traducono in:
- 320x224 px (40x28 tile) (H40 NTSC)
- 256x224 px (32x28 tiles) (H32 NTSC)
- 320x240 px (40x30 tiles) (H40 PAL)
- 256x240 (32x30 tiles) (H32 PAL)
Siccome la console era Giapponese ed il mercato principale quello Americano, sono pochi i giochi che hanno sfruttato le modalità PAL e spesso, un gioco NTSC portato sul mercato PAL aveva due bande nere alte 8 pixel per "riempire" l'immagine ed andava ca. un 10% più lento per via dei 50hz contro i 60hz.
Direi che se progettiamo un gioco oggi, l'ideale è attenersi al modo H40 NTSC.
2) I layer del fondale ed il layer per gli sprite
Il VDP è in grado di visualizzare tre piani grafici:
- Un piano che opera come sfondo (Piano B)
- Un primo piano (Piano A) con capacità di definire una finestra (window)
- Un piano dedicato agli sprite
Entrambi i piani A e B possono scrollare in maniera indipendente e la window è in grado di definire una zona del Piano A che non seguirà lo scrolling del resto del piano. Palesemente utile quando vogliamo avere indicatori sullo schermo di punti/livello/arma/etc...
Tutti i piani possono avere impostazioni di priorità cosi da poter avere sprite che sono magari coperti dal piano A ma non da quello B e dare un senso di profondità.
Il piano sprite consente fino ad 80 sprite con massimo 20 su una stessa linea (rasterline).
Attaccati al VDP ci sono 64KB di RAM (VRAM) la quale deve contenere i dati di tutti i tile, il fondale da scrollare e la tabella sprite. Ci sono poi 128 byte di CRAM (Color RAM), utilizzato per memorizzare i 64 colori contemporanei (scelti da una palette di 512) che è il numero standard di colori visualizzati dal Mega Drive (ma esistono molti trucchi per incrementarlo).
In realtà i 64 colori derivano dal fatto che si possono definire 4 palette di 16 colori ciascuna, in pratica questo equivale però solo a 61 colori diversi poiché il primo colore in ogni tavolozza è "trasparente" e uno di questi viene utilizzato come colore di sfondo.
Per ogni tile ed ogni sprite possiamo associare una palette. E' possibile quindi visualizzare la stessa tile legandola di volta in volta a palette diverse. E' inoltre possibile alterare i colori della palette durante il refresh, questo consente effetti come l'acqua in movimento e finte semi-trasparenze, così come visto in molti dei livelli di Sonic ed in tanti altri giochi.
Analizziamo quindi proprio Sonic con tutte le informazioni che ora abbiamo sul VDP.
- Sonic quindi utilizza entrambi i piani B ed A. Per entrambi definisce un'area di 64x32 tile (ricordandoci che solo 40x28 tile sono visualizzate nella modalià H40 NTSC) ed usa questa mappa maggiore fuori schermo come buffer, aggiornandola in base alla direzione verso cui si sta correndo.
- Questa area più larga può essere composta al massimo da 4096 tiles per ognuno dei due piani e può avere una delle seguenti dimensioni: 32x32, 32x64 (o 64x32), 64x64, 32x128 (o 128x32).
- Dalla prima foto con tutti i layer attivi è possibile vedere che alcune tile sono speculari, ribaltate orizzontalmente.
Questo tipo di operazione può essere compiuta dal VDP senza dover memorizzare due tile diverse.
- Il piano B si occupa dello sfondo distante come nuvole, montagne, rovine lontane e bosco.
- Il piano A si occupa dello sfondo più vicino al giocatore, col terreno dove si corre ed elementi del fondale in primo piano.
- Non sfrutta la window per definire un'area no-scroll per punteggio, vite, etc... ma opta per l'uso di sprite anche per questi contatori.
- Usa tutte e 4 le palette con la prima dedicata a Sonic ed ai contatori di punteggio, vite, etc... in questo modo è una palette che non cambia mai.
- La seconda palette è usata per i nemici e per gli anelli, cosi da poter aggiornare la palette in base alle sfumature colori necessarie per i nemici di ogni livello.
- La terza e quarta palette sono dedicate al fondale e, come vedremo più avanti, parti di questa palette a volte cambiano durante il livello per simulare alcune animazioni.
- Infine possiamo anche notare che Piano A e Piano B sono sovrapposti ma non facendo combaciare l'origine di entrambi. Questo è chiaramente possibile e consente di decentrare, ad esempio, il Piano A che si muoverà anche ad una velocità differente rispetto lo sfondo che scorrerà più lentamente per dare un senso di maggiore profondità.
- Come colore si sfondo è settato il blu che nei Piani A, B e sprite agisce anche da colore trasparente.
Vediamo come siamo riusciti a sezionare Sonic in tutte queste sue componenti.
3) Come analizzare l'utilizzo del VDP di un titolo
Il motivo per cui ho suggerito l'uso del Gens come emulatore è stato principalmente con la finalità di utilizzo degli strumenti di debug.
Iniziamo con visualizzare l'uso dei differenti Piani.
Per visualizzarli è sufficiente aprire il menu CPU, selezionare voce Debug e poi Layers. Questo aprirà una finestra che consente di selezionare quale Piano abilitare o disabilitare nell'emulatore.
Aperto questo menu è ora di vedere il contenuto dei singoli Piani, e quello può essere facilmente ottenuto dal menu CPU, selezionare voce Debug e poi Plane Explorer.
Questo aprirà una maschera aggiuntiva che consente di selezionare il piano e vedere anche le sue dimensioni.
Infine, per analizzare le palette usate in un determinato momento, bisogna selezionare la seguente voce CPU, selezionare Debug, selezionare Genesis ed infine VDP :
Comprese le prime specifiche del VDP del Mega Drive, e visto come si può vedere l'uso del VDP grazie all'emulatore, è ora il momento ideale per tornare al nostro codice ed analizzare la ROM che abbiamo prodotto con la prima compilazione.