Problembehandlung (Direct3D 9)

In diesem Thema werden allgemeine Kategorien von Problemen aufgeführt, die beim Schreiben von Direct3D-Anwendungen auftreten können, und wie sie verhindert werden können.

Geräteerstellung

Wenn ihre Anwendung während der Geräteerstellung fehlschlägt, überprüfen Sie die folgenden häufigen Fehler.

• Überprüfen Sie die Gerätefunktionen, insbesondere die Rendertiefen.
• Untersuchen Sie den Fehlercode. D3DERR_OUTOFVIDEOMEMORY ist immer möglich.
• Verwenden Sie die DirectX-DLLs (Dynamic Link Libraries), und überprüfen Sie die Ausgabemeldungen unter dem Debugger.

Verwenden von Lit Sctices

Anwendungen, die beleuchtete Scheitelpunkte verwenden, sollten die Direct3D-Beleuchtungs-Engine deaktivieren, indem sie den D3DRS_LIGHTING Renderzustand auf FALSE festlegen. Standardmäßig legt das System bei aktivierter Beleuchtung die Farbe für jeden Scheitelpunkt, der keinen normalen Vektor enthält, auf 0 (schwarz) fest, auch wenn der Eingabevertex einen ungleichen Farbwert enthielt. Da lit-Sctices naturbedingt keinen Scheitelpunkt normal enthalten, gehen alle an Direct3D übergebenen Farbinformationen beim Rendern verloren, wenn die Beleuchtungs-Engine aktiviert ist.

Natürlich ist die Scheitelpunktfarbe für jede Anwendung wichtig, die eine eigene Beleuchtung durchführt. Um zu verhindern, dass das System die Standardwerte aufzwingt, stellen Sie sicher, dass Sie D3DRS_LIGHTING auf FALSE festlegen.

Wenn Ihre Anwendung ausgeführt wird, aber nichts sichtbar ist, überprüfen Sie, ob die folgenden häufigen Fehler auftreten.

• Stellen Sie sicher, dass Ihre Dreiecke nicht entartet sind.
• Stellen Sie sicher, dass Ihre Dreiecke nicht gekrüppt werden.
• Stellen Sie sicher, dass Ihre Transformationen intern konsistent sind.
• Überprüfen Sie die Viewporteinstellungen, um sicherzustellen, dass Ihre Dreiecke sichtbar sind.

Debuggen

Das Debuggen einer Direct3D-Anwendung kann eine Herausforderung darstellen. Probieren Sie die folgenden Techniken aus, und überprüfen Sie zusätzlich alle Rückgabewerte - ein besonders wichtiger Rat bei der Direct3D-Programmierung, die von sehr unterschiedlichen Hardwareimplementierungen abhängig ist.

• Wechseln Sie zum Debuggen von DLLs.
• Erzwingen Sie ein reines Softwaregerät, und deaktivieren Sie die Hardwarebeschleunigung, auch wenn es verfügbar ist.
• Erzwingen von Oberflächen in den Systemspeicher.
• Erstellen Sie eine Option zum Ausführen in einem Fenster, damit Sie einen integrierten Debugger verwenden können.

Die zweite und dritte Option in dieser Liste kann Ihnen helfen, die Win16-Sperre zu vermeiden, die andernfalls dazu führen kann, dass Ihr Debugger hängen bleibt.

Versuchen Sie außerdem, die folgenden Einträge Win.ini hinzuzufügen.

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

Borland Floating-Point Initialisierung

Compiler von Borland melden Gleitkommaausnahmen in einer Weise, die mit Direct3D nicht kompatibel ist. Um dieses Problem zu beheben, fügen Sie einen _matherr Ausnahmehandler wie folgt ein:

// 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
}

Parameterüberprüfung

Aus Leistungsgründen führt die Debugversion der Direct3D-Direktmodus-Laufzeit eine größere Parameterüberprüfung als die Einzelhandelsversion durch, die manchmal überhaupt keine Überprüfung durchführt. Dadurch können Anwendungen robustes Debuggen mit der langsameren Debuglaufzeitkomponente ausführen, bevor sie die schnellere Einzelhandelsversion für die Leistungsoptimierung und die endgültige Version verwenden.

Obwohl mehrere Direct3D-Direktmodusmethoden Grenzwerte für die Werte festlegen, die sie akzeptieren können, werden diese Grenzwerte häufig nur von der Debugversion der Direct3D-Direktmoduslaufzeit überprüft und erzwungen. Anwendungen müssen diesen Grenzwerten entsprechen, andernfalls können unvorhersehbare und unerwünschte Ergebnisse auftreten, wenn sie in der Einzelhandelsversion von Direct3D ausgeführt werden. Beispielsweise akzeptiert die IDirect3DDevice9::D rawPrimitive-Methode einen Parameter (PrimitiveCount), der die Anzahl von Primitiven angibt, die von der Methode gerendert werden. Die -Methode kann nur Werte zwischen 0 und D3DMAXNUMPRIMITIVES akzeptieren. Wenn Sie in der Debugversion von Direct3D mehr als D3DMAXNUMPRIMITIVES-Grundtypen übergeben, schlägt die Methode ordnungsgemäß fehl, indem sie eine Fehlermeldung in das Fehlerprotokoll ausgibt und einen Fehlerwert an Ihre Anwendung zurückgibt. Wenn Ihre Anwendung hingegen denselben Fehler macht, wenn sie mit der Einzelhandelsversion der Laufzeit ausgeführt wird, ist das Verhalten nicht definiert. Aus Leistungsgründen überprüft die Methode die Parameter nicht, was zu einem unvorhersehbaren und vollständig situationsbedingten Verhalten führt, wenn sie ungültig sind. In einigen Fällen kann der Aufruf funktionieren, und in anderen Fällen kann er einen Speicherfehler in Direct3D verursachen. Wenn ein ungültiger Aufruf konsistent mit einer bestimmten Hardwarekonfiguration und DirectX-Version funktioniert, gibt es keine Garantie, dass er weiterhin auf anderer Hardware oder mit späteren Versionen von DirectX funktioniert.

Wenn ihre Anwendung bei der Ausführung mit der Retail-Direct3D-Laufzeitdatei auf unerklärliche Fehler stößt, testen Sie mit der Debugversion, und suchen Sie genau nach Fällen, in denen Ihre Anwendung ungültige Parameter übergibt. Verwenden Sie das DirectX-Systemsteuerungs-Applet, wechseln Sie bei Bedarf zur Debuglaufzeit, und aktivieren Sie die Option "Break on D3DError". Diese Option erzwingt, dass die Runtime die Windows DebugBreak-Methode verwendet, um zu erzwingen, dass die Anwendung beendet wird, wenn ein Anwendungsfehler erkannt wird.

Zugehörige Themen

Programmiertipps