Condividi tramite

Risoluzione dei problemi (Direct3D 9)

  • Articolo

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

Creazione del dispositivo

Se la tua applicazione si blocca durante la creazione del dispositivo, verifica la presenza dei seguenti errori comuni.

  • Assicurarsi di controllare le funzionalità del dispositivo, in particolare le profondità di rendering.
  • Esaminare il codice di errore. D3DERR_OUTOFVIDEOMEMORY può sempre verificarsi.
  • Usare le librerie di collegamento dinamico DirectX di debug (DLL) ed esaminare i messaggi di output nel debugger.

Uso dei vertici illuminati

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 lit-vertices, per loro natura, non contengono una normale del vertice, tutte le informazioni sul colore passate a Direct3D vengono perse durante il rendering se il motore di illuminazione è abilitato.

Ovviamente, il colore dei vertici è 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 vengano degenerati.
  • Assicurarsi che i triangoli non vengano rimossi.
  • Assicurarsi che le trasformazioni siano coerenti internamente.
  • Controllare le impostazioni del riquadro di visualizzazione per assicurarsi che consentano la visualizzazione dei triangoli.

Debug

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

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

Le seconde e le terze opzioni in questo elenco possono aiutarti a evitare il blocco Win16 che altrimenti può 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 incompatibile con Direct3D. Per risolvere questo problema, includere un gestore di eccezioni _matherr simile al seguente:

// 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 definitiva, che a volte non esegue alcuna convalida. Ciò consente alle applicazioni di eseguire un debug robusto con il componente di runtime di debug più lento prima di usare la versione commerciale più veloce per l'ottimizzazione delle prestazioni e il rilascio finale.

Anche se diversi metodi della modalità immediata Direct3D impongono limiti ai valori che possono accettare, questi limiti vengono spesso controllati e applicati solo dalla versione di debug della modalità immediata Direct3D. Le applicazioni devono essere conformi a questi limiti o risultati imprevedibili e indesiderati possono verificarsi durante l'esecuzione nella versione definitiva di Direct3D. Ad esempio, il metodo IDirect3DDevice9::D rawPrimitive accetta un parametro (PrimitiveCount) che indica il numero di primitive di cui verrà eseguito il rendering. Il metodo può accettare solo valori compresi tra 0 e D3DMAXNUMPRIMITIVES. Nella versione di debug di Direct3D, se si passano più di D3DMAXNUMPRIMITIVES primitive, il metodo fallisce in modo controllato, stampando un messaggio di errore nel registro degli errori e restituendo un valore di errore alla tua applicazione. Viceversa, se l'applicazione genera lo stesso errore quando è in esecuzione con la versione definitiva del runtime, il comportamento non è definito. Per motivi di prestazioni, il metodo non convalida i parametri, causando un comportamento imprevedibile e completamente situazionale 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 particolare configurazione hardware e una versione DirectX, non esiste alcuna garanzia che continui a funzionare su altri hardware o con versioni successive di DirectX.

Se l'applicazione rileva errori inspiegabili durante l'esecuzione con il file di runtime Direct3D retail, eseguire il test sulla versione di debug e cercare attentamente i casi in cui l'applicazione passa parametri non validi. Usare l'applet del pannello di controllo DirectX, passare al runtime di debug, se necessario, e selezionare l'opzione "Interrompi in 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