Rozwiązywanie problemów (Direct3D 9)
W tym temacie wymieniono typowe kategorie problemów, które mogą wystąpić podczas pisania aplikacji Direct3D oraz sposoby ich zapobiegania.
Tworzenie urządzenia
Jeśli aplikacja nie powiedzie się podczas tworzenia urządzenia, sprawdź następujące typowe błędy.
- Upewnij się, że sprawdzasz możliwości urządzenia, szczególnie głębie renderowania.
- Sprawdź kod błędu. D3DERR_OUTOFVIDEOMEMORY zawsze jest możliwe.
- Użyj bibliotek dynamicznych linków DirectX (DLL) i przejrzyj komunikaty wyjściowe w debugerze.
Używanie litych wierzchołków
Aplikacje używające oświetlonych wierzchołków powinny wyłączyć moduł oświetlenia Direct3D, ustawiając parametr renderowania D3DRS_LIGHTING na FALSE. Domyślnie, po włączeniu oświetlenia system ustawia kolor dla każdego wierzchołka, który nie zawiera wektora normalnego, na 0 (czarny), nawet jeśli wierzchołek wejściowy zawierał niezerową wartość koloru. Ze względu na to, że wierzchołki oświetlone z natury nie zawierają normalnych wierzchołków, wszelkie informacje o kolorze przekazywane do Direct3D są tracone podczas renderowania, jeśli włączony jest silnik oświetleniowy.
Oczywiście kolor wierzchołka jest ważny dla każdej aplikacji, która wykonuje własne oświetlenie. Aby uniemożliwić systemowi nakładanie wartości domyślnych, upewnij się, że ustawiono D3DRS_LIGHTING na wartość FALSE.
Jeśli aplikacja działa, ale nic nie jest widoczne, sprawdź następujące typowe błędy.
- Upewnij się, że trójkąty nie są degenerowane.
- Upewnij się, że trójkąty nie są odrzucane.
- Upewnij się, że przekształcenia są spójne wewnętrznie.
- Sprawdź ustawienia widoku, aby upewnić się, że umożliwiają one wyświetlanie trójkątów.
Debugowanie
Debugowanie aplikacji Direct3D może być trudne. Wypróbuj następujące techniki, oprócz sprawdzania wszystkich wartości zwracanych — szczególnie ważnej porady w programowaniu Direct3D, który jest zależny od bardzo różnych implementacji sprzętu.
- Przejdź do debugowania bibliotek DLL.
- Wymuś urządzenie tylko do oprogramowania, wyłączając przyspieszanie sprzętowe nawet wtedy, gdy jest dostępne.
- Wymuś powierzchnie w pamięci systemowej.
- Utwórz opcję uruchamiania w oknie, aby można było użyć zintegrowanego debugera.
Druga i trzecia opcja na tej liście może pomóc uniknąć blokady Win16, która w przeciwnym razie może spowodować zawieszenie debugera.
Spróbuj również dodać następujące wpisy do Win.ini.
[Direct3D]
debug=3
[DirectDraw]
debug=3
Inicjalizacja Borland Floating-Point
Kompilatory Borland raportują wyjątki zmiennoprzecinkowe w sposób niezgodny z Direct3D. Aby rozwiązać ten problem, dołącz program obsługi wyjątków _matherr podobny do następującego:
// 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
}
Walidacja parametru
Ze względów wydajnościowych wersja debugowa trybu natychmiastowego działania Direct3D wykonuje więcej weryfikacji parametrów niż wersja produkcyjna, która czasami nie przeprowadza żadnej walidacji. Dzięki temu aplikacje mogą przeprowadzać niezawodne debugowanie przy użyciu wolniejszego składnika czasu wykonywania debugowania przed użyciem szybszej wersji detalicznej na potrzeby dostrajania wydajności i końcowej wersji.
Chociaż kilka metod trybu bezpośredniego Direct3D nakłada limity na wartości, które mogą zaakceptować, limity te są często sprawdzane i egzekwowane tylko przez wersję debugowania środowiska uruchomieniowego trybu bezpośredniego Direct3D. Aplikacje muszą być zgodne z tymi limitami lub nieprzewidywalne i niepożądane wyniki mogą wystąpić podczas uruchamiania w wersji detalicznej Direct3D. Na przykład metoda IDirect3DDevice9::DrawPrimitive akceptuje parametr (PrimitiveCount), który wskazuje liczbę prymitywów renderowanych przez metodę. Metoda może akceptować tylko wartości z zakresu od 0 do D3DMAXNUMPRIMITIVES. W wersji debugowania Direct3D, jeśli przekażesz więcej niż D3DMAXNUMPRIMITIVES prymitywów, metoda zakończy się niepowodzeniem w kontrolowany sposób, drukując komunikat o błędzie w dzienniku błędów, po czym zwracając wartość błędu do aplikacji. Z drugiej strony, jeśli aplikacja popełnia ten sam błąd, gdy jest uruchomiona z wersją handlową czasu wykonywania, jego zachowanie jest nieokreślone. Ze względu na wydajność metoda nie weryfikuje parametrów, co powoduje nieprzewidywalne i całkowicie sytuacyjne zachowanie, gdy są nieprawidłowe. W niektórych przypadkach wywołanie może działać, a w innych przypadkach może to spowodować błąd pamięci w trybie Direct3D. Jeśli nieprawidłowe wywołanie stale działa z określoną konfiguracją sprzętową i wersją DirectX, nie ma gwarancji, że będzie nadal działać na innym sprzęcie lub w nowszych wersjach DirectX.
Jeśli aplikacja napotka niewyjaśnione błędy podczas uruchamiania z plikiem wykonawczym wersji retail Direct3D, przetestuj w wersji debug i dokładnie przyjrzyj się sytuacjom, w których aplikacja przekazuje nieprawidłowe parametry. W razie potrzeby użyj apletu panelu sterowania DirectX, przełącz na środowisko uruchomieniowe debugowania i zaznacz opcję "Przerwij na D3DError". Ta opcja wymusi użycie metody Windows DebugBreak przez środowisko uruchomieniowe w celu wymuszenia zatrzymania aplikacji po wykryciu usterki aplikacji.
Tematy pokrewne