트러블 슈팅

여기에서는, Microsoft® Direct3D® 애플리케이션의 개발중에 발생할 가능성이 있는 문제를 일반적인 카테고리별로 나타내, 그 회피 방법에 대해 설명한다.

장치의 생성

장치의 생성중에 애플리케이션이 이상종료(ABEND) 했을 경우, 다음의 공통의 에러를 조사한다.

장치 능력, 특히 렌더링 깊이를 조사한다.
에러 코드를 조사한다. 항상 D3DERR_OUTOFVIDEOMEMORY 가 생각된다.
디버그 Microsoft DirectX® 동적 링크 라이브러리 (DLL)를 사용해, 디버거에 표시되는 출력 메시지를 확인한다.

조명이 끝난 정점의 사용법

조명이 끝난 정점을 사용하는 애플리케이션의 경우, D3DRS_LIGHTING 렌더링 스테이트를 FALSE 로 설정해, Direct3D 조명 엔진을 무효로 할 필요가 있다. 디폴트에서는, 조명은 유효하게 되어 있어 입력 정점에 제로 이외의 색값이 포함되어 있어도, 시스템은 법선 벡터를 포함하지 않은 정점의 색을 0 (흑)으로 설정한다. 본래, 조명이 끝난 정점에는 정점 법선이 포함되지 않기 때문에, 조명 엔진이 유효하게 되어 있으면 Direct3D 에게 건네지는 색정보는 렌더링 시에 모두 없어진다.

독자적인 라인 팅을 실행하는 애플리케이션에 있어, 정점색이 중요하다 (일)것은 말할 필요도 없다. 시스템에 의한 디폴트값의 사용을 회피하기 위해서, D3DRS_LIGHTING 를 FALSE 로 설정하는 것.

애플리케이션을 실행해도 아무것도 표시되지 않는 경우, 다음의 공통의 에러를 조사한다.

삼각형이 없어지지 않은 것을 확인한다.
삼각형이 컬링(Culling)되지 않은 것을 확인한다.
변환이 내부적으로 일관하고 있는 것을 확인한다.
뷰포트의 설정을 조사해, 삼각형의 표시가 가능하게 되어 있는 것을 확인한다.

디버그

Direct3D 애플리케이션의 디버그는 곤란을 따르는 일이 있다. 모든 반환값 (Direct3D 프로그래밍에 대해 특히 중요한 요소이지만, 하드웨어의 처리에 의해 크게 다르다)을 조사하는 것 외에 다음의 방법을 시험해 본다.

디버그 DLL 로 전환한다.
소프트웨어 전용 장치를 강제적으로 사용해, 하드웨어 가속화가 사용 가능해도 오프로 한다.
표면을 강제적으로 시스템 메모리에 배치한다.
윈도우로 실행하는 옵션을 생성 해, 통합 디버거를 사용할 수 있도록(듯이) 한다.

Win16 잠금에 의해 디버거가 헹 하는 경우가 있지만, 이 일람의 2 번째와 3 번째의 옵션은, Win16 잠금을 방지한다.

또, 다음의 엔트리를 Win.ini 에 추가해 본다.

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

볼랜드 부동 소수점 초기화

볼랜드의 컴파일러는, Direct3D 와의 호환성이 없는 방법으로 부동 소수점 예외를 보고한다. 이 문제를 해결하려면 , 다음과 같이 _matherr 예외 핸들러를 포함한다.

// Borland floating point initialization 
#include 
#include 

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

파라미터의 타당성 검사

퍼포먼스 위에의 이유로부터, Direct3D 런타임의 디버그 버전에서는, 리테일 버전의 경우보다 많은 파라미터의 타당성 검사를 실시한다. 리테일 버전에서는, 타당성 검사가 전혀 행해지지 않는 것도 있다. 이것을 사용하는 것으로, 애플리케이션에서는 저속인 디버그 런타임 구성 요소에 의해 안정된 디버깅을 실행할 수 있어 그 후로 고속의 리테일 버전을 사용해 퍼포먼스를 조정해, 최종적인 릴리스에 대비할 수가 있다.

Direct3D 의 몇개의 메서드에서는, 사용 가능한 값에 제한이 있지만, 이 제한은 Direct3D 런타임의 디버그 버전만이 체크해 실시하는 것이 많다. 애플리케이션은 이 제한에 따를 필요가 있다. 이것에 따르지 않으면 Direct3D 의 리테일 버전으로 실행했을 때에, 예상외의 바람직하지 않은 결과가 생길 가능성이 있다. 예를 들어,IDirect3DDevice9::DrawPrimitive 메서드에서는, 이 메서드로 렌더링 하는 기본도형의 개수를 나타내는 파라미터 (PrimitiveCount)를 사용한다. 이 메서드로 사용할 수 있는 값의 범위는 0 ~ D3DMAXNUMPRIMITIVES 이다. Direct3D 의 디버그 버전으로, D3DMAXNUMPRIMITIVES 개보다 많은 기본도형를 건네주었을 경우, 메서드는 이상종료(ABEND) 해, 에러 로그에 에러 메시지를 출력해, 애플리케이션에 에러값을 돌려준다. 반대로, 런타임의 리테일 버전으로 실행하고 있는 경우에 애플리케이션으로 같은 에러가 발생했을 때는, 동작은 부정이다. 퍼포먼스 위에의 이유로부터, 메서드는 파라미터의 타당성 검사를 실시하지 않는다. 따라서, 파라미터가 유효하지 않은 경우에는, 그 상황에 의존한 예상외의 동작이 생긴다. 경우에 따라서는, 호출을 하는 일도 있다. 또, 경우에 따라서는, 그 호출해에 기인해 Direct3D 로 메모리 장해가 발생하는 일도 있다. 무효인 호출이 특정의 하드웨어 구성과 DirectX 의 버전으로 일관해 기능했다고 해도, 다른 하드웨어나 DirectX 의 향후의 릴리스로 기능하는 것은 보증되지 않는다.

리테일 Direct3D 런타임 파일로 애플리케이션을 실행하고 있는 경우에, 설명할 수 없는 장해가 발생했을 때는, 디버그 버전에 대해서 테스트를 실시해, 애플리케이션으로 무효인 파라미터를 건네주고 있는 개소가 있는지 없는지를 신중하게 조사하는 것. DirectX 컨트롤 패널 애플릿을 사용해 필요한 경우는 디버그 런타임으로 전환해[Break on D3DError] 옵션을 온으로 한다. 이 옵션에 의해, 애플리케이션의 버그를 검출했을 때에 애플리케이션을 강제적으로 정지하기 위해서, 런타임은 Windows DebugBreak 메서드를 사용한다.