Ecco qui una lista degli errori più comuni commessi quando si inizia a programmare in DirectX. Vi consiglio vivamente di leggerli e seguire i consigli proposti, perché essi sono (aimè) dettati dall’esperienza personale del sottoscritto dopo davvero tante ore di duro lavoro…

Regola numero 0
In realtà questa è una regola generale della programmazione: prima fate funzionare le cose, POI OTTIMIZZATE. Se tentate di ottimizzare da subito in dx, vi assicuro che non vedrete nient’altro oltre lo schermo nero per un bel po’ di tempo, senza capire “cosa c’e’ che non funziona” nel vostro programma. Ci sono troppe cose da tenere a bada,non si puo’ pensare di ottimizzarle da subito. E ricordate che vige sempre FMIWTMIF (First make it work,than make it Fast)

Regola numero 1
Controllare SEMPRE gli HRESULT restituiti da una chiamata di metodo durante lo sviluppo. Magari usato delle macro, in modo da escludere i controlli nelle chiamate più “importanti” (ad esempio le varie DrawPrimitive) durante la compilazione della Release Version. Esiste una funzione chiamata DXGetErrorString8 che dato un HRESULT restituisce una stringa contenente una descrizione più o meno significativa dell’errore. Nel nostro codice utilizzeremo delle macro che controllano l’HRESULT e interrompono l’esecuzione del programma, nel caso qualcosa sia andato storto (tipo CHECKHR e CHECKHR_VOID).

Regola numero 2
Utilizzare la versione di Debug delle DirectX. Come è stato già detto nell’installazione del DXSDK viene chiesto se installare DirectX in versione Retail o Debug. La versione Debug è un po’ più lenta di quella Retail poichè effettua un meticoloso controllo degli errori sui parametri passati a tutti i metodi degli oggetti DirectXGraphics. Ovviamente questo è uno dei più preziosi strumenti che abbiamo a disposizione e dobbiamo approfittarne. Quando trova errori o anomalie scrive dei messaggi sul terminale di debug dell’applicazione. Se state usando Visual C++ questi messaggi li potete vedere alla fine del programma quando effettuate il Debug dell’applicazione.



In questo shot ho passato apposta 1 parametro sbagliato alla IDirect3Ddevice8::CreateDevice(…) (l’adapter) e vedete come nella finestra di log del VisualC++ viene indicata la causa esatta dell’errore. Se vedete messaggi d’errore particolarmente criptici segnalateli alla http://discuss.microsoft.com/archives/DIRECTXDEV.html ">Mailing List Ufficiale delle DirectX.

Potete anche cambiare il numero e il tipo di messaggi che volete vi siano segnalati attraverso uno slider posto nel pannello di controllo directx. Spostando lo slider le potete passare dalla modalità di segnalazione di “Solo Errori” a modalità dove vi segnala anche consigli x migliorare le performance etc etc. Se mettete lo slider al massimo (more) probabilmente riceverete una CATERVA di messaggi (molti dei quali poco utili)



Regola numero 3
Controllare il comportamento del Reference Rasterizer. Programmare videogiochi 3D per PC non è semplice perché bisogna spesso tener conto che il nostro gioco dovrà girare su altri PC, che potrebbero avere altri acceleratori video, altri processori etc. Oltre a questo i drivers, ovverosia quei componenti software che fanno da tramite tra DirectX e la vostra scheda video, potrebbero presentare dei bug e causare anomalie nei risultati a schermo che non dipendono da nostri errori. Proprio per questo motivo Microsoft ha creato un driver “virtuale” chiamato Reference Rasterizer che è il riferimento assoluto per la programmazione 3D in DXG. Se il nostro programma si comporta differentemente usando il Reference Rasterizer e rispetto a quando sfruttiamo l’accelerazione, allora possiamo essere più che certi che il driver del nostro acceleratore ha un bug. Quando succede questo, è bene fare una segnalazione alla casa di produzione e attendere il rilascio nuove versioni corrette dei drivers.

Il Reference Rasterizer non è stato programmato pensando all’ottimizzazione ma esclusivamente alla correttezza dell’output a schermo per il debugging delle applicazioni. Non è pensabile utilizzare il RefRast come modulo software da usare quando non è presente l’accelerazione hardware.

Per usare il reference rasterizer basta passare D3DDEVTYPE_REF nella CreateDevice al posto di D3DDEVTYPE_HAL che indica l’accelerazione hardware.


HRESULT hr;
hr = g_d3d->CreateDevice( D3DADAPTER_DEFAULT,D3DDEVTYPE_REF,
g_hwnd,D3DCREATE_SOFTWARE_VERTEXPROCESSING,
¶ms,&g_device.p);



Regola numero 4
Debuggate il vostro programma in finestra, in questo modo se impostate dei break durante il rendering nel debugger non si pianta il sistema…Usate la modalita’ fullscreen solo x il rilascio del prodotto finale.