[ Home | Capitolo 1 | Capitolo 2 | Capitolo 3 | Capitolo 4 | Capitolo 5 ]

Guida alla Programmazione di Giochi con le DirectX di David Joffe

Capitolo 2: Palettes, concetti di Gioco, double buffering etc

2.1 Modalità Video

Esistono diversi tipi di modalità schermo, basate su quanti bits vengono usati per memorizzare il colore si ogni pixel sullo schermo. Naturalmente, più bits si usano per pixel, più colori si possono mostrare in una volta; ma esistono altri dati da muovere nella memoria grafica per aggiornare lo schermo.

Queste modalità sono disponibili, tipicamente, nelle seguenti risoluzioni:

La 640x480 è probabilmente il modo più comune al momento per l'esecuzione di giochi.

I monitor generalmente hanno una larghezza che è pari a 4/3 dell'altezza (chiamata aspect ratio); quindi con modalità dove il numero dei pixels della lunghezza è i 4/3 dei pixel dell'altezza, i pixels hanno un aspect ratio di 1, e così sono fisicamente quadrati. Vale a dire, 100 pixels in una direzione dovranno avere la stessa lunghezza fisica nella direzione perpendicolare. Notare che 320/200 non ha questa proprietà; quindi in 320x200 i pixels sono attualmente stirati per essere alti quanto sono larghi.

2.2 Teoria del colore

Esistono diversi modi per rappresentare i colori, conosciuti come "color models". Il più comune è probabilmente l'RGB (Red,Green,Blue). Quasi tutti i colori visibili possibili possono essere prodotti con la combinazione, in varie proporzioni, dei tre colori primari, rosso, verde e blu. Questi vengono immagazzinati come tre bytes - ogni byte rappresenta la relativa intensità di ogni colore primario come un valore da 0 a 255 estremi inclusi. Il rosso puro, per esempio, sarà RGB(255,0,0). Il porpora sarà RGB(255,0,255), il grigio RGB(150,150,150), e così via.

Qui c'è un esempio di codice C che potete usare per rappresentare i colori RGB.

E' piuttosto brutto. In alternativa potreste memorizzare i colori RGB in un unsigned integer:

Ad ogni modo, ora sto divagando.

Esistono altri modelli di colore, come HSV (Hue, Saturation, Luminance), ma non lo spiegherò ora. Il libro "Computer Graphics, principles and practise" di Foley & van Dam (spesso chiamato The Computer Graphics Bible) spiega i modelli di colore in dettaglio, e come effettuare la conversione tra modelli diversi.

2.2.1 Modalità high-color e true-color

Nelle modalità high-color e true-color, i pixels sullo schermo vengono memorizzati nella memoria video come il loro corrispondente valore RGB. per esempio, se il pixel in alto a sinistra dello schermo è verde, allora (in modalità true-color) i primi tre bytes della memoria video saranno 0, 255 e 0.

Nella modalità high-color i valori RGB vengono specificati utilizzando (se ricordo bene) 5, 6 e 5 bits per rosso, verde e blu rispettivamente, così nell'esempio sopra i primi due bytes nella memoria video saranno, in codice binario: 00000111 11100000.

2.2.2 Modalità Palette-based, o "indexed"

Urgh.

L'indexed mode più comune è l'8-bit, meglio conosciuto come modalità a 256 colori. In questa modalità, il programmatore ha una scelta di 28 = 256 differenti colori che possono essere mostrati sullo schermo contemporaneamente. I valori RGBper ognuno dei 256 colori sono immagazzinati in una tavola di records RGB, ognuno lungo 3 bytes. Così, ogni pixel prende un byte della memoria video, e il valore di questo byte specifica un indice nella tavola (chiamata "palette") che è usato per vedere i valori RGBper generare il pixel sullo schermo.

Ceare una applicazione attorno a questa palette è una sofferenza. Ma utilizzare una palette offre diversi vantaggi, che includono:

2.2.3 ModeX

ModeX è una modalità speciale nella quale i contenuti della memoria grafica (es. ciò che appare sullo schermo) viene memorizzato in un formato piano piuttosto complesso. Le DirectDraw sa come disegnare superfici in ModeX, ma la GDI di Windows no, quindi state attenti quando provate a mischiare GDI e superfici DirectDraw in ModeX. Quando si setta la modalità a tutto schermo delle DirectDraw, è possibile scegliere se alle DirectDraw sia permesso di creare superfici in ModeX. In questi giorni cercate di evitare il ModeX.

2.2.4 Pitch

Anche se la risoluzione dello schermo è, diciamo, 640x480x8, questo non significa che ogni riga di pixels occupa 640 bytes in memoria. Per ottimizzare il codice che va nella scheda grafica, le modalità video vengono spesso immagazzinate in memoria come se fossero molto più grandi della risoluzione effettiva. Una modalità 640x480, per esempio, potrebbe essere immagazzinata in memoria come 1024x480 - quindi solo i 640 pixels più a sinistra di ogni riga vengono mappati sullo schermo. La larghezza "reale" che un modo occupa è conosciuta come pitch o stride della superficie, e deve essere ottenuta dalle DirectDraw. Questo è importante per sapere quando si scrive nella memoria che rappresenta una superficie.

 Memoria dello schermo:
+--------------------------+-------------+
|                          |             |
| -- Larg. dello schermo - |             |
|                          |             |
| -- pitch/stride ---------------------- |
|                          |             |
|                          |             |
|                          |             |
|                          |             |
+--------------------------+-------------+

2.3 Alcuni concetti di gioco che dovete conoscere per scrivere giochi

2.3.1 Bitmaps e sprites

Un bitmap è un'immagine nel computer che è memorizzara come un array di valori di pixel. Questa è una descrizione abbastanza buttata lì. Fondamentalmente, un bitmap è qualsiasi immagine nel computer, normalmente un blocco rettangoalre di 'pixels'. Uno sprite è uguale al bitmap, eccetto che normalmente si riferisce ad un bitmap che ha aree trasparenti. Gli sprites sono una componente estremamente importante dei giochi. Esistono milioni di utilizzi. Per esempio, il cursore del vostro mouse contiene uno sprite. I mostri in DOOM sono anche sprites. Si tratta di immagini piatte con aree trasparenti che sono programmate per starvi sempre di fronte. Notate che lo sprite è sempre di fronte a voi - questo non vuol dire che il mostro è davanti a voi. Comunque, mi sembra di aver detto abbastanza sui bitmaps e sugli sprites.

2.3.2 Double buffering e page flipping

Il Double-buffering è una tecnica abbastanza elegante veramente importante per ottenere velocità, animazioni fluide nelle vostre applicazioni. Non è la sola cosa di cui avete bisogno per raggiungere questi obiettivi, ma è certamente una delle più importanti. Fondamentalmente, funziona così. Il vostro gioco disegna quello che l'utente ha intenzione di vedere sullo schermo in una superficie off-screen. Il risultato è che l'utente non deve vedere gli elementi dello schermo mentre vengono disegnati, cosa che provoca tutti i tipi di effetti sgradevoli, come il flickering. Ora, solo quando l'immagine è pronta per essere visualizzata (o "finito il rendering", se vogliamo utilizzare termini un po' più tecnici) viene mostrata all'utente. Generalmente esistono due modi per ottenere questo:

Un problema che può derivare da questa tecnica è il "tearing". Il vostro monitor ridisegna l'immagine sullo schermo abbastanza frequentemente, normalmente circa 70 volte al secondo (o 70 Hertz). Normalmente disegna dall'alto verso il basso. Ora, può succedere che sullo schermo venga tracciata solo metà immagine, quando decidete di istruirlo per iniziare a disegnare qualche altra cosa, utilizzando una delle tecniche summenzionate. Quando fate questo, la parte inferiore dello schermo viene disegnata utilizzando la nuova immagine, mentre la metà superiore ha ancora la vecchia immagine. L'effetto visivo prodotto viene chiamato tearing, o shearing. Esiste una soluzione, comunque. E' possibile sincronizzare il vostro page flipping in modo che coincida con la fine del refresh dello schermo. Comunque mi fermerò qui, avendovi fatto conoscere il possibile. (penso che le DirectDraw controllino tutto questo al posto vostro, controllate)

2.4 Clipping e clippers DirectDraw

Clipping è il nome dato alla tecnica di impedire alle routines di disegno dal disegnare oltre i limiti dello schermo o di un'altra superficie rettangolare, come una finestra. Se non viene eseguita, il risultato comune potrebbe essere descritto meglio dalla parola confusione. Nelle DirectDraw, per esempio, quando si usa il windowed mode; Windows sostanzialmente da alle DirectDraw il diritto di disegnare ovunque sullo schermo. Comunque, una applicazione DirectDraw ben addestrata normalmente disegnerà solo nella propria finestra. Le DirectX hanno un oggetto chiamato "clipper" che può essere collegato ad una superficie DirectDraw per prevenire che disegni al di fuori della finestra.

2.5 Superfici DirectDraw

Le DirectDraw usano le "superfici" per accedere a qualsiasi sezione della memoria, sia video che di sistema, che viene usata per memorizzare (di norma) bitmaps, texture maps, sprites, e il corrente contenuto dello schermo o di una finestra.

Le DirectDraw forniscono anche il supporto per gli "overlays", uno speciale tipo di sprite. Un overlay è di solito una superficie contenente un bitmap con sezioni trasparenti che "ricopriranno" l'intero schermo. Per esempio, un gioco di corsa di macchine potrebbe usare un overlay per l'immagine dei controlli dell'abitacolo e per il riquadro del vetro.

La memoria che una superficie DirectDraw utilizza, può venire persa in alcune circostanze, perche le DirectDraw si dividono le risorse con la GDI. E' necessario per le vostre applicazioni di controllare regolarmente che questo non accada, e di ripristinare le superfici se accade.

2.6 valori restituiti dalle DirectX e controlli di errore

Tutte le funzioni DirectX restituiscono un HRESULT come codice di errore. Siccome gli oggetti DirectX sono basati sull'architettura COM, il modo corretto di controllare se una funzione DirectX ha dato un errore è di utilizzare le macros SUCCEEDED() e FAILED(), con HRESULT come parametro. Non è sufficiente controllare se, per esempio, l' HRESULT della vostra DirectDraw è uguale a DD_OK, dato che per gli oggetti COM è possibile restituire diversi valori come valori di successo. Il vostro codice probabilmente funzionerà lo stesso, ma tecnicamente è una cosa sbagliata da fare.

2.6 Il debugging delle DirectX

Quando installate l'SDK DirectX fate la scelta di installare o la versione retail delle librerie, o quella debug. La versione debug scriverà il messaggio diagnostico OutputDebugString nel vostro debugger. Questo può essere veramente utile. Comunque, rallenta TANTISSIMO le cose - se possedete una macchina inferiore ad un Pentium 166, scegliete piuttosto le librerie di release. Inoltre, se volete soprattutto giocare giochi DirectX, installate la versione retail version. Se volete principalmente sviluppare con le DirectX, e il vostro computer è piuttosto veloce, installate la versione debug. Se volete fare entrambe le cose, allora dovete probabilmente usare le librerie di release, a patto di avere un computer davvero veloce che le possa reggere.


Articolo di David Joffe (http://www.geocities.com/SoHo/Lofts/2018/); Ultimo aggiornamento: 17 Aprile 1999

---
Traduzione: Papero - IPG 1999
Eng?Ita! Team
http://www.ItaProGaming.com