Share via


Risoluzione dei problemi (Direct3D 9)

Questo argomento elenca le categorie comuni di problemi che potrebbero verificarsi durante la scrittura di applicazioni Direct3D e come impedirle.

Creazione del dispositivo

Se l'applicazione ha esito negativo durante la creazione del dispositivo, verificare la presenza degli errori comuni seguenti.

  • Assicurarsi di controllare le funzionalità del dispositivo, in particolare le profondità di rendering.
  • Esaminare il codice di errore. D3DERR_OUTOFVIDEOMEMORY è sempre possibile.
  • Usare le librerie di collegamento dinamico DirectX di debug e esaminare i messaggi di output nel debugger.

Uso dei vertici lit

Le applicazioni che usano vertici illuminati devono disabilitare il motore di illuminazione Direct3D impostando lo stato di rendering D3DRS_LIGHTING su FALSE. Per impostazione predefinita, quando l'illuminazione è abilitata, il sistema imposta il colore per qualsiasi vertice che non contiene un vettore normale su 0 (nero), anche se il vertice di input contiene un valore di colore diverso da zero. Poiché i vertici illuminati non, in base alla loro natura, contengono un vertice normale, tutte le informazioni sul colore passate a Direct3D vengono perse durante il rendering se il motore di illuminazione è abilitato.

Ovviamente, il colore del vertice è importante per qualsiasi applicazione che esegue la propria illuminazione. Per impedire al sistema di imporre i valori predefiniti, assicurarsi di impostare D3DRS_LIGHTING su FALSE.

Se l'applicazione viene eseguita ma non è visibile nulla, verificare la presenza degli errori comuni seguenti.

  • Assicurarsi che i triangoli non siano degenerati.
  • Assicurarsi che i triangoli non vengano eliminati.
  • Assicurarsi che le trasformazioni siano coerenti internamente.
  • Controllare le impostazioni del riquadro di visualizzazione per assicurarsi che i triangoli vengano visualizzati.

Debug

Il debug di un'applicazione Direct3D può essere difficile. Provare le tecniche seguenti, oltre a controllare tutti i valori restituiti, un elemento particolarmente importante della programmazione Direct3D, che dipende da implementazioni hardware molto diverse.

  • Passare a DLL di debug.
  • Forzare un dispositivo solo software, disattivando l'accelerazione hardware anche quando è disponibile.
  • Forzare le superfici nella memoria di sistema.
  • Creare un'opzione per l'esecuzione in una finestra, in modo che sia possibile usare un debugger integrato.

La seconda e la terza opzioni di questo elenco consentono di evitare il blocco Win16 che può altrimenti causare il blocco del debugger.

Provare anche ad aggiungere le voci seguenti a Win.ini.

[Direct3D] 
debug=3 
[DirectDraw] 
debug=3 

Inizializzazione di Borland Floating-Point

I compilatori di borland segnalano eccezioni a virgola mobile in modo non compatibile con Direct3D. Per risolvere questo problema, includere un gestore di eccezioni di _matherr come illustrato di seguito:

// Borland floating point initialization 
#include <math.h>
#include <float.h>

void initfp(void)
{
    // Disable floating point exceptions
    _control87(MCW_EM,MCW_EM);
}

int _matherr(struct _exception  *e)
{
    e;               // Dummy reference to catch the warning
    return 1;        // Error has been handled
}

Convalida dei parametri

Per motivi di prestazioni, la versione di debug della modalità immediata Direct3D esegue più convalida dei parametri rispetto alla versione retail, che a volte non esegue alcuna convalida. Ciò consente alle applicazioni di eseguire il debug affidabile con il componente di runtime di debug più lento prima di usare la versione più veloce per l'ottimizzazione delle prestazioni e la versione finale.

Anche se diversi metodi di modalità immediata Direct3D impongono limiti ai valori che possono accettare, questi limiti vengono spesso controllati e applicati dalla versione di debug dell'ora di esecuzione della modalità immediata Direct3D. Le applicazioni devono essere conformi a questi limiti o risultati imprevedibili e indesiderati possono verificarsi durante l'esecuzione nella versione retail di Direct3D. Ad esempio, il metodo IDirect3DDevice9::D rawPrimitive accetta un parametro (PrimitiveCount) che indica il numero di primitive che il metodo eseguirà il rendering. Il metodo può accettare solo valori compresi tra 0 e D3DMAXNUMPRIMITIVES. Nella versione di debug di Direct3D, se si passano più di primitive D3DMAXNUMPRIMITIVES, il metodo non riesce correttamente, stampando un messaggio di errore nel log degli errori e restituendo un valore di errore all'applicazione. Al contrario, se l'applicazione esegue lo stesso errore quando viene eseguita con la versione retail del tempo di esecuzione, il comportamento non è definito. Per motivi di prestazioni, il metodo non convalida i parametri, causando comportamenti imprevedibili e completamente situazioniali quando non sono validi. In alcuni casi la chiamata potrebbe funzionare e in altri casi potrebbe causare un errore di memoria in Direct3D. Se una chiamata non valida funziona in modo coerente con una determinata configurazione hardware e versione DirectX, non esiste alcuna garanzia che continuerà a funzionare su altri hardware o con versioni successive di DirectX.

Se l'applicazione riscontra errori inspiegabili durante l'esecuzione con il file di run-time Direct3D al dettaglio, testare la versione di debug e cercare strettamente i casi in cui l'applicazione supera parametri non validi. Usare l'applet del pannello di controllo DirectX, passare al runtime di debug se necessario e controllare l'opzione "Break on D3DError". Questa opzione forza il runtime a usare il metodo DebugBreak di Windows per forzare l'arresto dell'applicazione quando viene rilevato un bug dell'applicazione.

Suggerimenti per la programmazione