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 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.
struct SColor
{
int r;
int g;
int b;
};
SColor make_rgb( int r, int g, int b )
{
SColor ret;
ret.r = r;
ret.g = g;
ret.b = b;
return ret;
}
typedef unsigned int rgb_color;
#define MAKE_RGB(r,g,b) ( ((r) << 16) | ((g) << 8) | (b) )
Memoria dello schermo:
+--------------------------+-------------+
| | |
| -- Larg. dello schermo - | |
| | |
| -- pitch/stride ---------------------- |
| | |
| | |
| | |
| | |
+--------------------------+-------------+
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