DirectX 질문과 대답

물론 그렇습니다. x64 기술은 시장에서 널리 사용할 수 있습니다. 지난 몇 년 동안 판매 된 새로운 CPU의 대부분, AMD와 인텔에서 개발의 거의 모든 프로세서 라인, x64 지원. Windows XP Professional x64 Edition은 2005년 4월에 출시된 x64용 OS 지원 기술을 도입했습니다. x64 버전에는 새로운 세대의 64비트 네이티브 드라이버가 필요하기 때문에 이 첫 번째 릴리스는 OEM 배포로 제한되었습니다.

Windows Vista를 사용하면 고객은 Windows 기반 컴퓨터를 구매할 때 32비트 또는 64비트 버전을 자유롭게 선택할 수 있으며 Windows Vista용 라이선스는 OS의 32비트 또는 64비트 버전 모두에 유효합니다. 또한 많은 64비트 드라이버를 상자에서 사용할 수 있으며 디바이스 제조업체는 Windows 인증 프로그램의 일부로 32비트 및 64비트 네이티브 드라이버를 모두 제공해야 합니다.

이러한 모든 요소는 64비트 버전의 Windows 배포를 크게 증가시킬 것입니다. 새 컴퓨터가 2GB 이상의 실제 RAM으로 배송을 시작하면 32비트 운영 체제를 사용하는 인센티브가 64비트 버전보다 크게 줄어듭니다. 64비트 기술은 32비트 네이티브 코드를 완벽하게 지원하지만 새로운 64비트 메모리 공간을 최대한 활용하려면 64비트 네이티브 구현이 필요합니다. 모든 32비트 애플리케이션에는 최소 배송 요구 사항으로 64비트 호환성이 있어야 하며, 이 요구 사항을 충족하는 것은 Windows Vista 호환성을 위한 기준 요구 사항입니다. 비호환성은 일반적으로 Windows 3.1 운영 체제용으로 설계된 16비트 코드를 사용하거나 32비트 및 64비트 네이티브 형식으로 제공되지 않은 드라이버를 설치할 때 발생합니다.

64비트 기술에 대한 자세한 내용은 게임 개발자를 위한 64비트 프로그래밍을 참조 하세요.

더 이상 두 가지 이유, 즉 성능 및 기능 집합이 없습니다.

게임에 필요한 최소 CPU 속도가 1.2GHz 이상인 경우(고성능 타이틀에 더 일반적임) 대부분의 적격 컴퓨터가 Windows XP를 실행합니다. CPU 속도가 1.2GHz를 초과하는 컴퓨터가 판매될 때까지 Windows XP는 거의 모든 제조업체에서 기본 운영 체제로 설치되었습니다. 즉, Windows XP에는 오늘날의 게임 개발자가 다음을 포함하여 활용해야 하는 많은 기능이 있습니다.

• 향상된 멀티태스킹 - 비디오, 오디오 및 게임에 대해 더 좋고 부드러운 환경을 제공합니다.
• 보다 안정적인 비디오 드라이버 모델 - 더 쉽게 디버깅하고, 부드러운 게임 플레이와 더 나은 성능을 제공합니다.
• 네트워킹에 대한 보다 쉬운 구성 - 멀티 플레이어 게임에 더 쉽게 액세스할 수 있습니다.
• 기본적으로 하드 드라이브에서 DMA 전송을 지원하므로 애플리케이션을 더 원활하고 빠르게 로드할 수 있습니다.
• Windows 오류 보고 - OS, 드라이버 및 애플리케이션을 보다 안정적으로 만듭니다.
• 유니코드 지원 - 지역화 문제를 크게 간소화합니다.
• 더 나은 보안 및 안정성 - 더 나은 소비자 경험을 초래합니다.
• 최신 하드웨어에 대한 더 나은 지원 - 대부분은 더 이상 Windows 98 드라이버를 사용하지 않습니다.
• 향상된 메모리 관리 - 안정성 및 보안을 향상합니다.
• 향상된 NTFS 파일 시스템 - 오류에 더 강하며 보안 기능으로 성능이 향상되었습니다.

더 이상은 그럴 필요가 없습니다. 게임 개발자가 여전히 Windows 95, Windows 98 또는 Windows ME용 게임을 게시해야 하는 이유 외에도 Windows 2000에는 다음 기능이 없습니다.

• Windows XP는 하이퍼 스레딩, 다중 코어 및 x64와 같은 고급 프로세서 기능을 지원합니다.
• Windows XP는 병렬 구성 요소를 지원하여 애플리케이션 버전 관리 충돌을 크게 줄입니다.
• Windows XP는 악성 프로그램을 방지하고 디버깅을 지원할 수 있는 실행되지 않는 메모리 보호를 지원합니다.
• Windows XP는 고급 AGP 및 PCI Express 기반 비디오 카드 대한 지원을 개선했습니다.
• Windows XP는 빠른 사용자 전환, 원격 데스크톱 및 원격 지원을 지원하여 제품 지원 비용을 절감할 수 있습니다.
• PIX(DirectX 개발자 SDK)와 같은 성능 도구는 더 이상 Windows 2000을 지원하지 않습니다.

즉, Windows 2000은 소비자 운영 체제로 설계되거나 판매되지 않았습니다.

Windows Vista 제품군에는 5개의 버전이 포함되어 있습니다.

• Windows Vista Home Basic
• Windows Vista Home Premium
• Windows Vista Business
• Windows Vista Enterprise
• Windows Vista Ultimate

Home Basic 및 Home Premium은 소비자 중심 버전이며 가족 금고ty(이전의 자녀 보호)와 같은 기능이 있으며 홈 프리미엄에는 미디어 센터가 포함되어 있습니다. 비즈니스 및 엔터프라이즈는 Do기본 조인 및 원격 데스크톱/터미널 서비스와 같은 기능을 갖춘 기업 중심 버전입니다. Ultimate Edition은 소비자 버전과 회사 버전의 모든 기능을 하나의 버전으로 결합합니다. 모든 버전은 32비트(x86) 및 64비트(x64) 버전으로 제공되며 사용자는 두 플랫폼에 대해 동일한 제품 식별자를 자유롭게 사용할 수 있습니다.

다양한 버전의 기본 기술은 동일하며 모두 동일한 버전의 DirectX 런타임 및 기타 구성 요소를 갖습니다. 그러나 버전에는 게임과 관련하여 몇 가지 사소한 차이점이 있습니다.

• 게임 탐색기는 모든 버전에 있지만 시작 메뉴 게임 바로 가기는 Home Basic, Home Premium 및 Ultimate에만 있습니다. 게임 탐색기는 시작을 클릭하고 모든 프로그램을 가리킨 다음 게임을 클릭하여 모든 버전에서 계속 찾을 수 있으며 모든 버전에서 IGameExplorer 인터페이스 함수를 사용할 수 있습니다.
• Windows에 포함된 게임은 기본적으로 Business 및 Enterprise에서 사용할 수 없지만 관리자가 사용하도록 설정할 수 있습니다.
• 가족 금고티 및 게임 등급은 비즈니스 또는 엔터프라이즈의 동작에 표시되거나 영향을 미치지 않으며, 할 일기본 참가할 때 Ultimate에서 비활성화됩니다.

사용자 계정 컨트롤 설정은 모든 버전에서 동일한 기본값을 갖지만 do기본 on Business, Enterprise 및 Ultimate에 대한 그룹 정책 설정으로 재정의할 수 있습니다. 예를 들어 정책 설정 사용자 계정 컨트롤: 표준 사용자에 대한 권한 상승 프롬프트의 동작은 보안을 강화하기 위해 많은 비즈니스 설정에서 권한 상승 요청을 자동으로 거부하도록 설정될 수 있으며, 이러한 환경의 많은 사용자는 항상 관리istrator로 실행하도록 선택할 수 없도록 표준 사용자로 실행됩니다. 레거시 설정 검색 또는 요청된 실행 수준을 "require관리istrator"로 지정하는 매니페스트로 인해 관리 권한이 필요한 모든 프로그램(예: 설치 관리자)은 이러한 상황에서 항상 시작되지 않습니다. 사용자 계정 컨트롤과 같은 다른 정책 설정: 서명되고 유효성이 검사된 실행 파일만 상승하면 Authenticode를 사용하여 실행 파일에 서명하지 않으면 설치 관리자가 작동하지 않을 수 있습니다.

이러한 유형의 정책 변경 내용은 모든 버전의 Windows Vista에 적용할 수 있지만 할 일기본 조인된 컴퓨터에서는 더 가능성이 높습니다.

Windows 7 사용자의 대부분은 가능성이 두 가지 버전 중 하나를 가질 것 이다: Windows 7 홈 프리미엄, 홈 사용자에 대 한, 또는 Windows 7 전문가, 비즈니스 사용자 및 개발자에 대 한. 대기업의 경우 모든 Windows 7 기능을 포함하는 볼륨 라이선스 Windows 7 Enterprise 버전이 있습니다. Windows 7 Ultimate는 해당 버전의 소매와 동일합니다.

Windows 7 Starter Edition은 OEM에서 전 세계적으로 사용할 수 있으며, 기본적으로 넷북, 초저전력 노트북 컴퓨터로 배포될 예정입니다. Windows 7 Home Basic은 신흥 시장에서만 사용할 수 있습니다.

Windows 7의 모든 버전(Starter Edition 제외)은 32비트(x86) 및 64비트(x64) 버전 모두에 사용할 수 있으며 Windows 7의 모든 소매 패키지에는 두 버전 모두에 대한 미디어가 포함되어 있습니다. Windows Vista와 마찬가지로 사용자는 두 플랫폼에서 동일한 소매 제품 식별자를 자유롭게 사용할 수 있습니다.

다양한 버전의 기본 기술은 동일하며 모든 버전은 동일한 버전의 DirectX 런타임 및 기타 구성 요소를 갖습니다. 게임 기능과 관련하여 몇 가지 차이점이 있습니다.

• 게임 탐색기는 모든 버전에 있지만 시작 메뉴 게임 바로 가기는 기본적으로 Windows 7 Professional 및 Enterprise에서 숨겨집니다. 모든 프로그램을 클릭한 다음 게임을 두 번 클릭하여 시작 메뉴 게임 탐색기를 계속 찾을 수 있으며 사용자가 직접 게임 바로 가기를 사용하도록 설정할 수 있습니다.
• Windows에 포함된 게임은 Windows 7 Professional 및 Enterprise에서 기본적으로 사용할 수 없지만 관리자가 사용하도록 설정할 수 있습니다.
• 가족 금고티 및 게임 등급은 모든 버전에서 사용할 수 있지만 운영 체제가 할 일기본 가입하면 Windows 7 Professional, Enterprise 및 Ultimate에서 사용할 수 없습니다. Windows Vista Ultimate와 마찬가지로 이 기능은 할 일기본 조인된 컴퓨터에서 다시 사용하도록 설정할 수 있습니다.

UAC(사용자 계정 제어) 설정은 Windows Vista와 마찬가지로 Windows 7 Professional, Enterprise 및 Ultimate 버전의 그룹 정책 설정에 의해 영향을 받을 수 있습니다. 자세한 내용은 Windows Vista의 다양한 버전 간의 차이점은 무엇인가요? DirectX 애플리케이션에 미치는 영향은 무엇인가요?

아니요. DirectX 10이 있는 Windows Vista에는 Windows XP SP2(DirectX 9.0c)의 런타임을 기반으로 하는 업데이트된 DirectX 런타임이 포함되어 있으며, 새 WDDM(Windows 디스플레이 드라이버 모델) 및 새 오디오 드라이버 스택과 운영 체제의 다른 업데이트와 함께 작동하도록 변경되었습니다. Direct3D 9 외에도 Windows Vista는 올바른 비디오 하드웨어와 드라이버가 있을 때 Direct3D9Ex 및 Direct3D10이라는 두 가지 새로운 인터페이스를 지원합니다.

이러한 새 인터페이스는 WDDM 기술을 사용하므로 이전 버전의 Windows에서는 사용할 수 없습니다. Windows Vista용 DirectX 기술에 대한 다른 모든 변경 내용은 새 버전의 Windows와도 관련이 있습니다. DirectX 10이라는 이름은 DirectX SDK(XACT, XINPUT, D3DX)에서 제공되는 많은 기술이 이 버전 번호로 포함되지 않는다는 사실에서 오해의 소지가 있습니다. 따라서 DirectX 런타임의 버전 번호를 전체적으로 언급하면 9.0c에서도 그 의미가 상당 부분 손실되었습니다. Windows Vista의 DirectX 진단 도구(DXdiag.exe)는 DirectX 10을 보고하지만 실제로는 Direct3D 10만 참조합니다.

DirectX 11은 Windows 7에 기본 제공되며 Windows Vista에 대한 업데이트로 사용할 수 있습니다(참조 https://go.microsoft.com/fwlink/p/?linkid=160189). 여기에는 Direct3D 11 API, DXGI(DirectX Graphics Infrastructure) 1.1, 10Level9 기능 수준, WARP(Windows Advanced Rasterization Platform) 10 소프트웨어 렌더링 디바이스, Direct2D, DirectWrite 및 10Level9 및 WARP 10을 지원하는 Direct3D 10.1 API 업데이트가 포함됩니다.

이전 질문에서 설명한 것과 동일한 이유(Windows XP에서 DirectX 10을 사용할 수 있나요? ) Direct3D 11 및 관련 API는 Windows XP에서 사용할 수 없습니다.

DirectShow는 2005년 4월 현재 DirectX SDK에서 제거되었습니다. Windows 소프트웨어 개발 키트(이전의 플랫폼 SDK)에서 DirectShow에 대한 헤더, 라이브러리, 도구 및 샘플을 가져올 수 있습니다. DirectX SDK의 DirectSetup은 DirectShow의 시스템 구성 요소 재배포를 계속 지원하며, 최신 구성 요소는 Microsoft Windows XP 서비스 팩 2, Windows XP Professional x64 Edition, Windows Server 2003 서비스 팩 1 및 Windows Vista 운영 체제에 이미 설치되어 있습니다.

새 WDDM을 지원하기 위해 기본 변경이 이루어졌습니다. 새 드라이버 모델, Direct3D 9에 미치는 영향 및 두 개의 새로운 그래픽 인터페이스인 Direct3D 9Ex 및 Direct3D 10에 대한 자세한 내용은 Windows의 그래픽 API를 검토하세요. Windows 7용 새 그래픽 API(Direct3D 11, Direct2D, DirectWrite, DXGI 1.1 및 업데이트된 Direct3D 10.1)는 Windows Vista에 대한 업데이트로 사용할 수 있습니다(참조 https://go.microsoft.com/fwlink/p/?linkid=160189).

Windows Vista 서비스 팩 1에는 업데이트된 버전의 DirectX 런타임이 포함되어 있습니다. 이 업데이트는 Direct3D 10.1을 포함하도록 Windows Vista의 지원을 확장하여 새로운 선택적 하드웨어 기능을 공개합니다. (Direct3D 10.1을 지원할 수 있는 모든 하드웨어는 Direct3D 10의 모든 기능을 완벽하게 지원합니다.)

DirectSound는 다중 채널 소프트웨어 버퍼를 지원하는 새로운 Windows Vista 오디오 드라이버 스택의 기능을 노출하도록 업데이트되었습니다. Direct3D 유지 모드 API가 Windows Vista에서 완전히 제거되었습니다. DirectPlay 음성도 제거되었으며 DirectPlay의 NAT 도우미 및 DirectInput의 Action-mapper UI도 제거되었습니다. Visual Basic 6.0용 DirectX 7 및 DirectX 8 인터페이스에 대한 지원은 Windows Vista에서 사용할 수 없습니다.

Windows 7에는 Windows Vista에 있는 모든 DirectX 런타임 구성 요소가 포함되어 있으며 Direct3D 11, DXGI 1.1, 10Level9 기능 수준, WARP10 소프트웨어 디바이스, Direct2D, DirectWrite 및 Direct3D 10.1 업데이트가 추가되어 10Level9 및 WARP10을 지원합니다. 자세한 내용은 Windows의 그래픽 API를 참조 하세요.

다른 모든 구성 요소는 Windows Vista와 동일하며, 타임스탬프가 적용된 MIDI와 관련된 핵심 Direct음악 API에 대한 64비트(x64) 네이티브 지원이 추가되었습니다. Direct음악의 성능 계층은기본 더 이상 사용되지 않으며, 애플리케이션 호환성을 위해 Windows 7의 32비트 애플리케이션에서만 사용할 수 있습니다. Direct음악 64비트 기본 지원은 Windows Vista에서 사용할 수 없습니다.

먼저 참조 래스터라이저를 사용하여 결과를 검사 확인합니다. 그런 다음, 최신 WHQL 인증 버전의 IHV 드라이버로 결과를 검사. D3DENUM_WHQL_LEVEL 플래그를 전달하는 IDirect3D9 인터페이스의 GetAdapterIdentifier() 메서드를 사용하여 WHQL 상태 프로그래밍 방식으로 검사 수 있습니다.

포함 경로가 올바르게 설정되지 않았을 수 있습니다. Microsoft Visual C++를 비롯한 많은 컴파일러에는 이전 버전의 SDK가 포함되어 있으므로 포함 경로가 표준 컴파일러 포함 디렉터리를 먼저 검색하는 경우 헤더 파일의 버전이 잘못됩니다. 이 문제를 해결하려면 포함 경로 및 라이브러리 경로가 Microsoft DirectX 포함 및 라이브러리 경로를 먼저 검색하도록 설정되어 있는지 확인합니다. SDK의 dxreadme.txt 파일도 참조하세요. DirectX SDK를 설치하고 Visual C++를 사용하는 경우 설치 관리자는 필요에 따라 포함 경로를 설정할 수 있습니다.

사용하는 다양한 GUID는 한 번만 정의해야 합니다. DirectX 헤더 파일을 포함하기 전에 INITGUID 기호를 #define 경우 GUID에 대한 정의가 삽입됩니다. 따라서 하나의 컴파일 단위에 대해서만 발생하는지 확인해야 합니다. 이 메서드의 대안은 모든 DirectX GUID에 대한 정의를 포함하는 dxguid.lib 라이브러리와 연결하는 것입니다. 권장되는 이 메서드를 사용하는 경우 INITGUID 기호를 #define 않아야 합니다.

아니요. DirectX 인터페이스는 COM 인터페이스입니다. 즉, 번호가 매겨진 해당 인터페이스에서 더 높은 번호가 매겨진 인터페이스를 파생할 필요가 없습니다. 따라서 DirectX 개체에 다른 인터페이스를 가져오는 유일한 안전한 방법은 인터페이스의 QueryInterface 메서드를 사용하는 것입니다. 이 메서드는 모든 COM 인터페이스가 파생되어야 하는 표준 IUnknown 인터페이스의 일부입니다.

서로 다른 버전의 여러 구성 요소를 자유롭게 혼합할 수 있습니다. 예를 들어 동일한 애플리케이션에서 DirectInput 8과 Direct3D 9를 사용할 수 있습니다. 그러나 일반적으로 동일한 애플리케이션 내에서 동일한 구성 요소의 다른 버전을 혼합할 수 없습니다. 예를 들어 DirectDraw 7과 Direct3D 9를 혼합할 수 없습니다(DirectDraw와 동일한 구성 요소가 DirectX 8을 기준으로 Direct3D로 하위화되었기 때문에). 그러나 동일한 애플리케이션에서 Direct3D 9 및 Direct3D 10을 함께 사용하는 것과 같은 예외가 있습니다.

예, 동일한 애플리케이션에서 이러한 버전의 Direct3D를 함께 사용할 수 있습니다.

반환 값은 개체의 현재 참조 수가 됩니다. 그러나 COM 사양에 따르면 이 값은 일반적으로 디버깅 목적으로만 사용할 수 있습니다. 다른 다양한 시스템 개체가 사용자가 만든 DirectX 개체에 대한 참조를 보유할 수 있으므로 관찰하는 값은 예기치 않은 것일 수 있습니다. 따라서 참조 수가 0이 될 때까지 Release를 반복적으로 호출하는 코드를 작성해서는 안 됩니다. 다른 구성 요소가 참조하는 경우에도 개체가 해제될 수 있기 때문입니다.

COM 인터페이스가 참조 계산되므로 중요하지 않습니다. 그러나 일부 버전의 DirectX에서는 인터페이스의 릴리스 순서와 함께 알려진 버그가 있습니다. 안전을 위해 가능하면 인터페이스를 역방향 생성 순서로 해제하는 것이 좋습니다.

스마트 포인터는 포인터 기능을 캡슐화하도록 설계된 C++ 템플릿 클래스입니다. 특히 COM 인터페이스 포인터를 캡슐화하도록 설계된 표준 스마트 포인터 클래스가 있습니다. 이러한 포인터는 캐스트 대신 QueryInterface를 자동으로 수행하고 AddRef 및 Release를 처리합니다. 당신이 그들을 사용해야하는지 여부는 주로 맛의 문제입니다. 코드에 여러 AddRefs 및 Releases와 함께 인터페이스 포인터를 많이 복사하는 경우 스마트 포인터를 사용하면 코드가 더 깔끔해지고 오류가 덜 발생할 수 있습니다. 그렇지 않으면, 당신은 그들없이 할 수 있습니다. Visual C++에는 "comdef.h" 헤더 파일에 정의된 표준 Microsoft COM 스마트 포인터가 포함되어 있습니다(도움말에서 com_ptr_t 조회).

DirectX 애플리케이션 디버깅의 가장 일반적인 문제는 DirectDraw 화면이 잠겨 있는 동안 디버그를 시도하는 것입니다. 이 경우 Microsoft Windows 9x 시스템에서 "Win16 Lock"이 발생하여 디버거 창이 그리는 것을 방지할 수 있습니다. 표면을 잠글 때 D3DLOCK_NOSYSLOCK 플래그를 지정하면 일반적으로 이를 제거할 수 있습니다. Windows 2000은 이 문제를 겪지 않습니다. 애플리케이션을 개발할 때 일부 매개 변수 유효성 검사를 수행하고 유용한 메시지를 디버거 출력에 출력하는 DirectX 런타임의 디버깅 버전(SDK를 설치할 때 선택됨)으로 실행하는 것이 유용합니다.

SUCCEEDED 및 FAILED 매크로를 사용합니다. DirectX 메서드는 여러 성공 및 실패 코드를 반환할 수 있으므로 간단하게 수행할 수 있습니다.

== D3D_OK

또는 유사한 테스트가 항상 충분하지는 않습니다.

당신은하지 않습니다! 게임은 ALT+TAB, 원격 데스크톱 연결, 빠른 사용자 전환, 자녀 보호 사용 제한 및 기타 많은 이벤트와 같은 많은 작업 전환 작업을 정상적으로 처리할 수 있어야 합니다.

동시에 키보드 중심 제어 체계를 사용하여 게임을 전환하는 실수로 인한 두 가지 일반적인 원인은 Windows 로고 키를 누르고 SHIFT 키를 사용하여 접근성 기능 StickyKeys를 활성화하는 것입니다. 기능을 사용하지 않도록 설정하여 이러한 경우를 해결하려면 게임에서 바로 가기 키를 사용하지 않도록 설정에 설명된 기술을 참조하세요.

데일 로저슨에 의해 COM 내부, 마이크로 소프트 프레스에 의해 출판, COM에 대한 훌륭한 소개입니다. COM에 대한 자세한 내용을 보려면 롱맨이 출판 한 돈 박스의 필수 COM 책도 매우 권장됩니다.

관리 코드는 .NET Framework CLR(공용 언어 런타임)에서 실행되는 코드입니다. 고유하게 실행되는 코드와 런타임 간의 협력 계약을 나타냅니다. 이 계약은 실행 시점에 런타임이 실행 중인 CPU를 중지하고 현재 CPU 명령 주소와 관련된 정보를 검색할 수 있음을 지정합니다. 일반적으로 쿼리 가능해야 하는 정보는 레지스터 또는 스택 메모리 콘텐츠와 같은 런타임 상태와 관련이 있습니다.

코드를 실행하기 전에 IL은 네이티브 실행 코드로 컴파일됩니다. 또한 이 컴파일은 관리되는 실행 환경에서 발생하므로(또는 더 정확하게는 관리되는 실행 환경을 대상으로 하는 방법을 알고 있는 런타임 인식 컴파일러에 의해) 관리되는 실행 환경에서 코드가 수행할 작업을 보장할 수 있습니다. 트랩 및 적절한 가비지 수집 후크, 예외 처리, 형식 안전성, 배열 경계 및 인덱스 검사 등을 삽입할 수 있습니다. 예를 들어 이러한 컴파일러는 가비지 수집기가 별도의 스레드의 백그라운드에서 실행되고, 활성 호출 스택을 지속적으로 걷고, 모든 루트를 찾고, 모든 라이브 개체를 추적할 수 있도록 스택 프레임과 모든 항목을 올바르게 배치합니다. 또한 IL에는 형식 안전이라는 개념이 있기 때문에 실행 엔진은 기본 형식 안전 보장을 보장하여 종종 보안 허점으로 이어지는 전체 클래스의 프로그래밍 실수를 제거합니다.

관리되지 않는 세계와 대조적으로 관리되지 않는 실행 파일은 기본적으로 메모리에 로드된 이진 이미지 x86 코드입니다. 프로그램 카운터가 배치되고 OS가 마지막으로 알고 있습니다. 메모리 관리 및 포트 I/O 등에 대한 보호가 있지만 시스템은 애플리케이션이 수행하는 작업을 실제로 알지 못합니다. 따라서 애플리케이션이 실행되면 어떤 일이 발생하는지 보장할 수 없습니다.

많은. 그러나 권장되는 두 가지는 다음과 같습니다.

• Charles Petzold의 Windows 프로그래밍(Microsoft Press)
• Jeffrey Richter의 Windows용 프로그래밍 애플리케이션(Microsoft Press)

Microsoft는 모든 시스템 DLL(기타 몇 개)에 대해 제거된 기호를 게시합니다. 액세스하려면 Visual Studio 내의 프로젝트 설정에서 기호 경로에 다음을 추가합니다.

srv*https://msdl.microsoft.com/download/symbols

캐싱 기호의 경우 로컬로 다음 구문을 사용합니다.

srv*c:\cache*https://msdl.microsoft.com/download/symbols

여기서 c:\cache는 기호 파일을 캐싱하기 위한 로컬 디렉터리입니다.

Direct3D 질문

일반 Direct3D 질문

주제에 대한 표준 책은 컴퓨터 그래픽입니다 : 폴리에 의해 원칙과 연습, 반 댐 외. 기하 도형, 래스터화 및 조명 기술의 수학적 기초를 이해하려는 모든 사람에게 귀중한 자원입니다. comp.graphics.algorithms Usenet 그룹에 대한 FAQ에도 유용한 자료가 포함되어 있습니다.

경우에 따라 다릅니다. Direct3D에는 완전한 기능을 갖춘 소프트웨어 꼭짓점 처리 파이프라인(사용자 지정 꼭짓점 셰이더에 대한 지원 포함)이 있습니다. 그러나 픽셀 수준 작업에는 에뮬레이션이 제공되지 않습니다. 애플리케이션은 적절한 대문자 비트를 검사 ValidateDevice API를 사용하여 지원을 결정해야 합니다.

성능 애플리케이션용이 아닙니다. 드라이버 유효성 검사를 위해 참조 래스터라이저가 제공되지만 구현은 성능이 아닌 정확도를 위해 설계되었습니다. Direct3D는 플러그 인 소프트웨어 래스터라이저를 지원합니다.

색 키 지정은 직접 지원되지 않습니다. 대신 알파 혼합을 사용하여 색 키 지정을 에뮬레이트해야 합니다. D3DXCreateTextureFromFileEx() 함수를 사용하여 이를 용이하게 할 수 있습니다. 이 함수는 키 색 매개 변수를 허용하며 지정된 색을 포함하는 원본 이미지의 모든 픽셀을 만든 질감의 투명한 검은색 픽셀로 바꿉니다.

예. Direct3D 기하 도형 파이프라인에는 프로세서 유형에 따라 여러 가지 코드 경로가 있으며 3DNow에서 제공하는 특수 부동 소수점 연산을 활용합니다. 또는 펜티엄 III SIMD 지침을 사용할 수 있습니다. 여기에는 사용자 지정 꼭짓점 셰이더 처리가 포함됩니다.

알파 값이 지정된 임계값보다 높거나 낮은 픽셀을 필터링할 수 있습니다. ALPHATESTENABLE, ALPHAREF 및 ALPHAFUNC 렌더링 상태를 사용하여 이 동작을 제어합니다.

스텐실 버퍼는 z 버퍼와 마찬가지로 픽셀당 정보의 추가 버퍼입니다. 실제로 z 버퍼의 일부 비트에 상주합니다. 일반적인 스텐실/z 버퍼 형식은 15비트 z 및 1비트 스텐실 또는 24비트 z 및 8비트 스텐실입니다. 다각형이 렌더링될 때 픽셀 단위로 스텐실 버퍼의 내용에 대해 간단한 산술 연산을 수행할 수 있습니다. 예를 들어 스텐실 버퍼는 증가하거나 감소할 수 있으며, 스텐실 값이 간단한 비교 테스트에 실패하면 픽셀을 거부할 수 있습니다. 이는 프레임 버퍼의 영역을 표시한 다음 표시된(또는 표시되지 않은) 영역만 렌더링을 수행하는 효과에 유용합니다. 좋은 예는 섀도 볼륨과 같은 볼륨 효과입니다.

이 버퍼 및 기타 볼륨 스텐실 버퍼 효과의 핵심은 스텐실 버퍼와 z 버퍼 간의 상호 작용입니다. 섀도 볼륨이 있는 장면은 세 단계로 렌더링됩니다. 첫째, 그림자가 없는 장면은 z 버퍼를 사용하여 평소와 같이 렌더링됩니다. 다음으로 그림자는 다음과 같이 스텐실 버퍼에 표시됩니다. 섀도 볼륨의 앞면은 보이지 않는 다각형을 사용하여 그려지지만 z-테스트를 사용하도록 설정되었지만 z-쓰기는 사용하지 않도록 설정되고 z-테스트를 통과하는 모든 픽셀에서 스텐실 버퍼가 증가합니다. 그림자 볼륨의 뒷면은 비슷하게 렌더링되지만 대신 스텐실 값이 감소합니다.

이제 단일 픽셀을 고려합니다. 카메라가 그림자 볼륨에 있지 않다고 가정하면 장면의 해당 지점에 대한 네 가지 가능성이 있습니다. 카메라에서 지점까지의 광선이 그림자 볼륨과 교차하지 않으면 그림자 다각형이 그려지지 않으며 스텐실 버퍼는 여전히 0입니다. 그렇지 않으면 그림자 볼륨 앞에 점이 있으면 그림자 다각형이 z 버퍼링되고 스텐실이 다시 변경되지 기본. 점이 그림자 볼륨 뒤에 있으면 후면과 동일한 수의 전면 그림자 얼굴이 렌더링되고 스텐실이 0이 되며 감소된 횟수만큼 증가합니다.

마지막 가능성은 점이 그림자 볼륨 안에 있다는 것입니다. 이 경우 섀도 볼륨의 뒷면은 z 버퍼 아웃되지만 앞면은 제외되므로 스텐실 버퍼는 0이 아닌 값이 됩니다. 결과는 그림자에 있는 프레임 버퍼의 일부가 0이 아닌 스텐실 값을 가지게 됩니다. 마지막으로 실제로 그림자를 렌더링하기 위해 전체 장면은 알파 혼합 다각형 집합으로 씻겨 0이 아닌 스텐실 값이 있는 픽셀에만 영향을 줍니다. 이 기술의 예는 DirectX SDK와 함께 제공되는 "섀도 볼륨" 샘플에서 확인할 수 있습니다.

이는 Direct3D 9 설명서에 설명되어 있습니다. 그러나 요약은 텍셀에 제대로 맞도록 화면 좌표를 픽셀 -0.5로 편향시켜야 한다는 것입니다. 대부분의 카드 이제 텍셀 맞춤 규칙을 제대로 준수합니다. 그러나 일부 오래된 카드 또는 그렇지 않은 드라이버가 있습니다. 이러한 경우를 처리하기 위해 가장 좋은 조언은 해당 하드웨어 공급업체에 문의하고 업데이트된 드라이버 또는 제안된 해결 방법을 요청하는 것입니다. Direct3D 10에서는 이 규칙이 더 이상 유지되지 않습니다.

디바이스를 만드는 동안 D3DCREATE_PUREDEVICE 플래그를 사용하여 순수 디바이스를 만듭니다. 순수 디바이스는 현재 상태(상태 변경 중)를 저장하지 않으므로 성능이 향상되는 경우가 많습니다. 이 디바이스에는 하드웨어 꼭짓점 처리도 필요합니다. 순수 디바이스는 일반적으로 개발 및 디버깅이 완료될 때 사용되며 최상의 성능을 달성하려고 합니다.

순수 디바이스의 한 가지 단점은 모든 Get* API 호출을 지원하지 않는다는 것입니다. 즉, 순수 디바이스를 사용하여 파이프라인 상태를 쿼리할 수 없습니다. 따라서 애플리케이션을 실행하는 동안 디버그하기가 더 어려워집니다. 다음은 순수 디바이스에서 사용하지 않도록 설정된 모든 메서드의 목록입니다.

• IDirect3DDevice9::GetClipPlane
• IDirect3DDevice9::GetClipStatus
• IDirect3DDevice9::GetLight
• IDirect3DDevice9::GetLightEnable
• IDirect3DDevice9::GetMaterial
• IDirect3DDevice9::GetPixelShaderConstantF
• IDirect3DDevice9::GetPixelShaderConstantI
• IDirect3DDevice9::GetPixelShaderConstantB
• IDirect3DDevice9::GetRenderState
• IDirect3DDevice9::GetSamplerState
• IDirect3DDevice9::GetTextureStageState
• IDirect3DDevice9::GetTransform
• IDirect3DDevice9::GetVertexShaderConstantF
• IDirect3DDevice9::GetVertexShaderConstantI
• IDirect3DDevice9::GetVertexShaderConstantB

순수 디바이스의 두 번째 단점은 중복 상태 변경을 필터링하지 않는다는 것입니다. 순수 디바이스를 사용하는 경우 애플리케이션은 렌더링 루프의 상태 변경 횟수를 최소한으로 줄여야 합니다. 여기에는 상태가 두 번 이상 설정되지 않도록 상태 변경 필터링이 포함될 수 있습니다. 이 절상은 애플리케이션에 따라 다릅니다. 프레임당 1000개 이상의 Set 호출을 사용하는 경우 순수가 아닌 디바이스에서 자동으로 수행되는 중복성 필터링을 활용하는 것이 좋습니다.

모든 성능 문제와 마찬가지로 애플리케이션이 순수 디바이스에서 더 잘 수행되는지 여부를 알 수 있는 유일한 방법은 애플리케이션의 성능을 순수 디바이스와 순수 디바이스와 비순수 디바이스를 비교하는 것입니다. 순수 디바이스는 API의 CPU 오버헤드를 줄여 애플리케이션 속도를 높일 수 있습니다. 하지만 조심하세요! 일부 시나리오의 경우 순수 디바이스는 중복 상태 변경으로 인한 추가 CPU 작업으로 인해 애플리케이션 속도가 느려집니다. 애플리케이션에 가장 적합한 디바이스 유형을 잘 모르고 애플리케이션의 중복 변경 내용을 필터링하지 않는 경우 순수하지 않은 디바이스를 사용합니다.

IDirect3D9 인터페이스의 메서드를 사용하여 애플리케이션에서 간단한 반복을 통해 열거형을 수행할 수 있습니다. GetAdapterCount를 호출하여 시스템의 디스플레이 어댑터 수를 확인합니다. GetAdapterMonitor를 호출하여 어댑터가 연결된 물리적 모니터를 확인합니다(이 메서드는 HMONITOR를 반환하며, Win32 API GetMonitorInfo에서 물리적 모니터에 대한 정보를 확인하는 데 사용할 수 있습니다). 특정 디스플레이 어댑터의 특성을 확인하거나 해당 어댑터에서 Direct3D 디바이스를 만드는 것은 GetDeviceCaps, CreateDevice 또는 기타 메서드를 호출할 때 D3DADAPTER_DEFAULT 대신 적절한 어댑터 번호를 전달하는 것만큼 간단합니다.

Direct3D 9를 기준으로 2개의 동시 텍스처만 지원할 > 수 있는 카드 유효성 검사를 강화했습니다. 특정 이전 카드 특정 알파 변조 작업을 사용하는 경우 3개의 텍스처 단계만 사용할 수 있습니다. 사람들이 3단계를 사용하는 가장 일반적인 용도는 엠보스 범프맵핑이며, D3D9를 사용하여 이 작업을 계속 수행할 수 있습니다.

높이 필드는 알파 채널에 저장되어야 하며 조명 기여도를 조절하는 데 사용됩니다. 즉,

// Stage 0 is the base texture, with the height map in the alpha channel
m_pd3dDevice->SetTexture(0, m_pEmbossTexture );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_TEXCOORDINDEX, 0 );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLOROP,   D3DTOP_MODULATE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAOP,   D3DTOP_SELECTARG1 );
m_pd3dDevice->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE );
if( m_bShowEmbossMethod )
{
 // Stage 1 passes through the RGB channels (SELECTARG2 = CURRENT), and 
 // does a signed add with the inverted alpha channel. 
 // The texture coords associated with Stage 1 are the shifted ones, so 
 // the result is:
 //    (height - shifted_height) * tex.RGB * diffuse.RGB
   m_pd3dDevice->SetTexture( 1, m_pEmbossTexture );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_TEXCOORDINDEX, 1 );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLOROP, D3DTOP_SELECTARG2 );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_CURRENT );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAOP, D3DTOP_ADDSIGNED );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAARG1, D3DTA_TEXTURE|D3DTA_COMPLEMENT );
   m_pd3dDevice->SetTextureStageState( 1, D3DTSS_ALPHAARG2, D3DTA_CURRENT );

   // Set up the alpha blender to multiply the alpha channel 
   // (monochrome emboss) with the src color (lighted texture)
   m_pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, TRUE );
   m_pd3dDevice->SetRenderState( D3DRS_SRCBLEND,  D3DBLEND_SRCALPHA );
   m_pd3dDevice->SetRenderState( D3DRS_DESTBLEND, D3DBLEND_ZERO );
}

이 샘플은 다른 이전 샘플과 함께 현재 SDK 릴리스에서 더 이상 배송되지 않으며 향후 SDK 릴리스에서 배송되지 않습니다.

Geometry(꼭짓점) 처리

Direct3D는 하나 이상의 꼭짓점 스트림에서 파이프라인의 처리 부분에 공급되는 각 꼭짓점을 어셈블합니다. 꼭짓점 스트림이 하나만 있으면 꼭짓점이 단일 원본에서 제공되는 이전 DirectX 8 이전 모델에 해당합니다. DirectX 8을 사용하면 다양한 꼭짓점 구성 요소가 다른 원본에서 올 수 있습니다. 예를 들어 하나의 꼭짓점 버퍼에는 위치와 법선이 있고 두 번째 버퍼에는 색 값과 질감 좌표가 있을 수 있습니다.

꼭짓점 셰이더는 단일 꼭짓점을 처리하는 프로시저입니다. D3DX 유틸리티 라이브러리에서 Direct3D에서 허용하는 토큰 스트림으로 어셈블되는 간단한 어셈블리와 유사한 언어를 사용하여 정의됩니다. 꼭짓점 셰이더는 단일 꼭짓점 및 상수 값 집합을 입력으로 사용합니다. 꼭짓점 위치(클립스페이스)와 선택적으로 래스터화에 사용되는 색 및 질감 좌표 집합을 출력합니다. 사용자 지정 꼭짓점 셰이더가 있는 경우 꼭짓점 구성 요소에는 더 이상 Direct3D에 의해 적용된 의미 체계가 없으며 꼭짓점은 사용자가 만든 꼭짓점 셰이더에 의해 해석되는 임의의 데이터일 뿐입니다.

아니요. 꼭짓점 셰이더는 변환된 꼭짓점 위치에 대해 클립 공간에서 동질 좌표를 출력합니다. 큐브 뷰 나누기 및 클리핑은 셰이더 이후 자동으로 수행됩니다.

꼭짓점 셰이더는 꼭짓점을 만들거나 삭제할 수 없습니다. 처리되지 않은 꼭짓점을 입력으로 사용하고 처리된 단일 꼭짓점을 출력하여 한 번에 하나의 꼭짓점에서 작동합니다. 따라서 기존 기하 도형(변형 적용 또는 스킨 작업 수행)을 조작하는 데 사용할 수 있지만 실제로는 새 기하 도형을 생성할 수 없습니다.

아니요. 하나 또는 다른 하나를 선택해야 합니다. 사용자 지정 꼭짓점 셰이더를 사용하는 경우 전체 꼭짓점 변환을 수행해야 합니다.

예. Direct3D 소프트웨어 꼭짓점 처리 엔진은 놀라울 정도로 높은 수준의 성능으로 사용자 지정 꼭짓점 셰이더를 완벽하게 지원합니다.

하드웨어에서 꼭짓점 셰이더를 지원할 수 있는 디바이스는 지원하는 꼭짓점 셰이더의 버전 수준을 나타내기 위해 D3DCAPS9::VertexShaderVersion 필드를 작성해야 합니다. 특정 수준의 꼭짓점 셰이더를 지원한다고 주장하는 모든 디바이스는 해당 수준 이하의 사양을 충족하는 모든 법적 꼭짓점 셰이더를 지원해야 합니다.

최소 96개의 상수 레지스터를 지원하려면 1.0개 이상의 꼭짓점 셰이더를 지원하는 디바이스가 필요합니다. 디바이스는 이 최소 개수 이상을 지원할 수 있으며 D3DCAPS9::MaxVertexShaderConst 필드를 통해 이를 보고할 수 있습니다.

이 상황의 일반적인 예는 각 얼굴에 다른 질감을 사용하려는 큐브입니다. 아쉽게도 대답은 아니요, 현재 꼭짓점 구성 요소를 독립적으로 인덱싱할 수 없습니다. 여러 꼭짓점 스트림이 있더라도 모든 스트림은 함께 인덱싱됩니다.

소프트웨어 기하 도형 파이프라인을 사용하는 경우 Direct3D는 먼저 제출한 범위의 모든 꼭짓점을 인덱싱할 때 "주문형"으로 변환하지 않고 변환합니다. 조밀하게 압축된 데이터(즉, 대부분의 꼭짓점이 사용되는 경우)의 경우 특히 SIMD 지침을 사용할 수 있는 경우 더 효율적입니다. 데이터가 드물게 압축된 경우(즉, 많은 꼭짓점이 사용되지 않음) 너무 많은 중복 변환을 방지하기 위해 데이터를 다시 정렬하는 것이 좋습니다. 하드웨어 기하 도형 가속을 사용하는 경우 꼭짓점은 일반적으로 필요에 따라 변환됩니다.

인덱스 버퍼는 꼭짓점 버퍼와 정확히 유사하지만 대신 DrawIndexedPrimitive 호출에 사용할 인덱스를 포함합니다. 가능한 경우 꼭짓점 버퍼와 동일한 이유로 원시 애플리케이션 할당 메모리 대신 인덱스 버퍼를 사용하는 것이 좋습니다.

아니요. D3DCAPS9::MaxVertexIndex 필드를 검사 디바이스에서 지원하는 최대 인덱스 값을 결정해야 합니다. D3DFMT_INDEX32 형식의 인덱스 버퍼가 지원되려면 이 값이 16번째 전원 -1(0xffff)보다 2보다 커야 합니다. 또한 일부 디바이스는 32비트 인덱스를 지원할 수 있지만 2보다 작은 최대 인덱스 값을 32번째 전원 -1(0xffffffff)으로 지원합니다. 이 경우 애플리케이션은 디바이스에서 보고한 제한을 준수해야 합니다.

x64에 최적화된 s/w 꼭짓점 파이프라인이 있지만 IA64에는 존재하지 않습니다.

성능 튜닝

다음은 성능을 최적화할 때 살펴볼 주요 영역입니다.

Direct3D는 대량의 기본 형식 배치에 최적화되어 있습니다. 단일 호출로 보낼 수 있는 다각형이 많을수록 좋습니다. 엄지 손가락의 좋은 규칙은 기본 호출 당 평균 1000 꼭짓점을 목표로하는 것입니다. 해당 수준 아래에서는 최적의 성능을 얻지 못할 수 있으며, 그 이상으로는 수익 감소 및 동시성 고려 사항과의 잠재적 충돌 가능성이 있습니다(아래 참조).

렌더링 상태를 변경하는 것은 특히 텍스처를 변경할 때 비용이 많이 드는 작업일 수 있습니다. 이러한 이유로 프레임당 상태 변경 횟수를 최대한 최소화하는 것이 중요합니다. 또한 꼭짓점 또는 인덱스 버퍼의 변경을 최소화해 보세요.

다른 처리와 동시에 렌더링을 수행하도록 정렬할 수 있는 경우 시스템 성능을 최대한 활용할 수 있습니다. 이 목표는 renderstate 변경을 줄이는 목표와 충돌할 수 있습니다. 동시성을 달성하기 위해 상태 변경을 줄이기 위해 일괄 처리와 드라이버에 데이터를 일찍 푸시하는 것 사이의 균형을 맞춰야 합니다. 라운드 로빈 방식으로 여러 꼭짓점 버퍼를 사용하면 동시성에 도움이 될 수 있습니다.

디바이스에 텍스처를 업로드하면 대역폭이 사용되며 꼭짓점 데이터와 대역폭 경쟁이 발생합니다. 따라서 커밋 텍스처 메모리를 초과하지 않는 것이 중요하므로 캐싱 체계가 각 프레임마다 과도한 수량의 텍스처를 업로드하도록 강제합니다.

애플리케이션 할당 메모리의 일반 블록이 아닌 꼭짓점 및 인덱스 버퍼를 항상 사용해야 합니다. 최소한 꼭짓점 및 인덱스 버퍼에 대한 잠금 의미 체계는 중복 복사 작업을 방지할 수 있습니다. 일부 드라이버에서는 하드웨어에서 액세스할 수 있도록 꼭짓점 또는 인덱스 버퍼를 더 최적의 메모리(비디오 또는 AGP 메모리)에 배치할 수 있습니다.

DirectX 7.0에서 도입되었습니다. 일련의 상태 변경 내용(조명, 재질 및 행렬 변경 포함)을 매크로로 기록하는 메커니즘을 제공하므로 한 번의 호출로 재생할 수 있습니다. 다음과 같은 두 가지 장점이 있습니다.

• 많은 호출 대신 하나의 호출을 실행하여 호출 오버헤드를 줄입니다.
• 인식 드라이버는 상태 변경 내용을 미리 구문 분석하고 미리 컴파일하여 그래픽 하드웨어에 훨씬 더 빠르게 제출할 수 있습니다.

상태 변경은 여전히 비용이 많이 들 수 있지만 상태 매크로를 사용하면 비용의 일부를 줄일 수 있습니다. 단일 Direct3D 디바이스만 사용합니다. 여러 대상에 렌더링해야 하는 경우 SetRenderTarget을 사용합니다. 여러 3D 창을 사용하여 창이 있는 애플리케이션을 만드는 경우 CreateAdditionalSwapChain API를 사용합니다. 런타임은 단일 디바이스에 최적화되어 있으며 여러 디바이스를 사용하는 경우 상당한 속도 저하가 발생합니다.

여러 다각형에서 공유되는 실제 데이터 기능 꼭짓점에서 발생하는 메시가 많습니다. 성능을 최대화하려면 버스에서 렌더링 디바이스로 변환되고 전송되는 꼭짓점의 중복을 줄이는 것이 좋습니다. 간단한 삼각형 목록을 사용하면 꼭짓점 공유가 수행되지 않으므로 가장 최적이 아닙니다. 그런 다음, 스트립과 팬을 사용하는 것이 선택되며, 이는 다각형 간의 특정 연결 관계를 의미하고 인덱싱된 목록을 사용하는 것입니다. 데이터가 자연스럽게 스트립과 팬에 속하는 경우 드라이버로 전송되는 데이터를 최소화하기 때문에 가장 적합한 선택입니다. 그러나 메시를 스트립과 팬으로 분해하면 많은 수의 개별 조각이 생성되어 많은 수의 DrawPrimitive 호출이 발생합니다. 이러한 이유로 가장 효율적인 방법은 일반적으로 삼각형 목록과 함께 단일 DrawIndexedPrimitive 호출을 사용하는 것입니다. 인덱싱된 목록을 사용하는 또 다른 이점은 연속 삼각형이 단일 꼭짓점만 공유하는 경우에도 이점을 얻을 수 있다는 것입니다. 요약하자면, 데이터가 자연스럽게 큰 스트립이나 팬에 속하는 경우 스트립이나 팬을 사용합니다. 그렇지 않으면 인덱싱된 목록을 사용합니다.

IDirect3DDevice9::GetAvailableTextureMem 은 AGP를 포함하여 사용 가능한 총 메모리를 반환합니다. 비디오 메모리의 양을 가정하여 리소스를 할당하는 것은 좋은 생각이 아닙니다. 예를 들어 카드 UMA(통합 메모리 아키텍처)에서 실행 중이거나 텍스처를 압축할 수 있는 경우 어떻게 되나요? 생각보다 더 많은 공간을 사용할 수 있습니다. 리소스를 만들고 '메모리 부족' 오류에 대한 검사 다음 텍스처에서 다시 확장해야 합니다. 예를 들어 텍스처의 상위 밉 수준을 제거할 수 있습니다.

1. D3DUSAGE_DYNAMIC 및 D3DUSAGE_WRITEONLY 사용 플래그 및 D3DPOOL_DEFAULT 풀 플래그를 사용하여 꼭짓점 버퍼를 만듭니다. (소프트웨어 꼭짓점 처리를 사용하는 경우 D3DUSAGE_SOFTWAREPROCESSING 지정합니다.)
2. I = 0입니다.
3. 상태를 설정합니다(텍스처, 렌더링 상태 등).
4. 버퍼에 공백이 있는지 확인합니다. 예를 들어 I + M <= N? (여기서 M은 새 꼭짓점의 수입니다).
5. 그렇다면 D3DLOCK_NOOVERWRITE 사용하여 VB를 잠급 수 있습니다. 이렇게 하면 Direct3D 및 드라이버에 꼭짓점을 추가할 것이며 이전에 일괄 처리한 꼭짓점을 수정하지 않음을 알 수 있습니다. 따라서 DMA 작업이 진행 중인 경우 중단되지 않습니다. 그렇지 않은 경우 11을 가져옵니다.
6. I에서 M 꼭짓점을 채웁니다.
7. 잠금을 해제.
8. Draw[Indexed]Primitive를 호출합니다. 인덱싱되지 않은 기본 형식의 경우 StartVertex 매개 변수로 I를 사용합니다. 인덱싱된 기본 형식의 경우 인덱스가 꼭짓점 버퍼의 올바른 부분을 가리키는지 확인합니다(이를 달성하기 위해 SetIndices 호출의 BaseVertexIndex 매개 변수를 사용하는 것이 가장 쉬울 수 있음).
9. I += M.
10. 고토 3.
11. 그래, 그래서 우리는 공간이 부족, 그래서 우리는 새로운 VB로 시작하자. 진행 중인 DMA 작업이 있을 수 있으므로 동일한 작업을 사용하지 않습니다. 동일한 VB를 D3DLOCK_DISCARD 플래그로 잠그면 Direct3D 및 드라이버와 통신합니다. 이것이 의미하는 바는 "이전 포인터로 끝났고 더 이상 이전 내용에 대해 신경 쓰지 않기 때문에 새 포인터를 줄 수 있습니다."
12. I = 0입니다.
13. 고토 4 (또는 6).

Direct3D 9를 기준으로 꼭짓점 스트림 선언은 더 이상 DWORD 배열이 아니라 D3DVERTEXELEMENT9 구조체의 배열입니다. 런타임은 추가 의미 체계 및 사용 정보를 사용하여 꼭짓점 스트림의 내용을 꼭짓점 셰이더 입력 레지스터/변수에 바인딩합니다. Direct3D 9의 경우 꼭짓점 선언은 꼭짓점 셰이더에서 분리되므로 런타임이 셰이더에 필요한 데이터만 바인딩하기 때문에 셰이더를 다양한 형식의 기하 도형으로 더 쉽게 사용할 수 있습니다.

새 꼭짓점 선언은 고정 함수 파이프라인 또는 셰이더와 함께 사용할 수 있습니다. 고정 함수 파이프라인의 경우 SetVertexShader를 호출할 필요가 없습니다. 그러나 고정 함수 파이프라인으로 전환하고 이전에 꼭짓점 셰이더를 사용한 경우 SetVertexShader(NULL)를 호출합니다. 이 작업이 완료되면 SetFVF를 호출하여 FVF 코드를 선언해야 합니다.

꼭짓점 셰이더를 사용하는 경우 꼭짓점 셰이더 개체를 사용하여 SetVertexShader를 호출합니다. 또한 SetFVF를 호출하여 꼭짓점 선언을 설정합니다. FVF에서 암시적 정보를 사용합니다. SetVertexDeclaration은 FVF로 표현할 수 없는 꼭짓점 선언을 지원하므로 SetFVF 대신 호출할 수 있습니다.

D3DX 이미지 파일 로더 함수는 BMP, TGA, JPG, DIB, PPM 및 DDS 파일을 지원합니다.

ID3DXFont::D rawText 함수를 사용할 때 발생하는 일반적인 실수는 색 매개 변수에 알파 구성 요소 0을 지정하는 것입니다. 그러면 텍스트가 완전히 투명합니다(즉, 보이지 않는 텍스트). 완전히 불투명한 텍스트의 경우 색 매개 변수의 알파 구성 요소가 완전히 포화(255)되었는지 확인합니다.

DirectX 8.1 SDK는 D3DX 라이브러리에 특히 D3DXSaveSurfaceToFile() 및 D3DXSaveTextureToFile()이라는 두 가지 함수를 추가했습니다. 이러한 함수는 이미지를 BMP 또는 DDS 형식으로 파일에 저장할 수 있도록 지원합니다. 이전 버전에서는 화면을 잠그고 이미지 데이터를 읽은 다음 비트맵 파일에 써야 합니다. 비트맵을 저장하는 함수를 작성하는 방법에 대한 자세한 내용은 이미지 저장을 참조 하세요.

또는 GDI+를 사용하여 이미지를 다양한 형식으로 저장할 수 있지만, 이를 위해서는 애플리케이션과 함께 추가 지원 파일을 배포해야 합니다.

Microsoft HLSL(High Level Shader Language)을 게임 엔진에 통합할 수 있는 세 가지 방법이 있습니다.

• 셰이더 소스를 꼭짓점 또는 픽셀 음영 어셈블리로 컴파일하고(명령줄 유틸리티 fxc.exe 사용) 런타임에 D3DXAssembleShader()를 사용합니다. 이러한 방식으로 DirectX 8 게임도 HLSL의 힘을 활용할 수 있습니다.
• D3DXCompileShader()를 사용하여 셰이더 원본을 토큰 스트림 및 상수 테이블 형식으로 컴파일합니다. 런타임에 토큰 스트림 및 상수 테이블을 로드하고 디바이스에서 CreateVertexShader() 또는 CreatePixelShader()를 호출하여 셰이더를 만듭니다.
• 시작하고 실행하는 가장 쉬운 방법은 D3DXCreateEffectFromFile() 또는 D3DXCreateEffectFromResource()를 효과 파일로 호출하여 D3DX 효과 시스템을 활용하는 것입니다.

2006년 12월 DirectX SDK부터 Direct3D 10용으로 개발된 새로운 HLSL 컴파일러가 Direct3D 9 대상에 대해 사용하도록 설정되었습니다. 새 컴파일러는 ps_1_x 대상을 지원하지 않으며 이제 모든 Direct3D HLSL 셰이더의 기본 컴파일러입니다. 이전 버전과의 호환성에 대한 플래그를 사용하여 ps_1_x 대상이 ps_2_0 대상으로 컴파일되도록 강제할 수 있습니다.

레거시 컴파일러를 사용하려는 애플리케이션은 런타임에 플래그를 제공하거나(컴파일러 플래그 참조) fxc를 사용할 때 스위치를 제공하여 계속 사용할 수 있습니다.

D3DXCreateEffect를 사용하여 ID3DXEffect를 만든 다음 GetPassDesc를 사용하여 D3DXPASS_DESC 검색합니다. 이 구조체에는 꼭짓점 및 픽셀 셰이더에 대한 포인터가 포함됩니다.

ID3DXEffectCompiler::GetPassDesc를 사용하지 마세요. 이 메서드에서 반환된 꼭짓점 및 픽셀 셰이더 핸들은 NULL입니다.

노이즈 내장 함수는 Ken Perlin에서 정의한 대로 perlin 노이즈를 생성합니다. 현재 h/w는 메서드를 기본적으로 지원하지 않으므로 HLSL 함수는 현재 텍스처 셰이더의 텍스처를 채우는 데만 사용할 수 있습니다. 텍스처 셰이더는 로드 시간 동안 절차적으로 정의된 텍스처를 생성하는 데 유용한 도우미 함수인 D3DXFill*Texture() 함수를 사용하여 구성하는 데 사용됩니다.

실행 중인 디바이스에 가장 적합한 HLSL 프로필을 결정하는 문자열을 반환하는 D3DXGetPixelShaderProfile() 및 D3DXGetPixelShaderProfile() 함수를 사용할 수 있습니다.

상수 테이블에 액세스하는 데 사용되는 ID3DXConstantTable 인터페이스를 통해 이 표에는 상위 수준 언어 셰이더 및 효과에 사용되는 변수가 포함되어 있습니다.

예, SetPrivateData를 호출하는 프라이빗 데이터를 설정하려면(pReal은 D3D 텍스처 개체이고 pSpoof는 래핑된 텍스처 개체임).

hr = pReal->SetPrivateData(IID_Spoof, &pSpoof, 
            sizeof(IDirect3DResource9*), 0)));

래핑된 포인터를 조회하려면 다음을 수행합니다.

    IDirect3DResource9* pSpoof;
    DWORD dwSize = sizeof(pSpoof);
    hr = pReal->GetPrivateData(IID_Spoof, (void*) &pSpoof, &dwSize);

얼굴 특성을 정의한 후 메시를 최적화하지 않았을 수 있습니다. 특성을 지정한 다음 ID3DXMesh::D rawSubset()를 호출하는 경우 이 메서드는 요청된 특성을 포함하는 모든 얼굴에 대한 메시 검색을 수행해야 합니다. 또한 렌더링된 얼굴은 임의 액세스 패턴일 수 있으므로 꼭짓점 캐시를 활용하지 않습니다. 하위 집합에 대한 얼굴 특성을 정의한 후 ID3DXMesh::Optimize 또는 ID3DXMesh::OptimizeInPlace 메서드를 호출하고 D3DXMESHOPT_ATTRSORT 이상의 최적화 메서드를 지정합니다. 최적의 성능을 위해 최적의 꼭짓점 캐시 사용률에 대한 꼭짓점 순서를 다시 지정하는 D3DXMESHOPT_VERTEXCACHE 플래그를 사용하여 최적화해야 합니다. D3DX Mesh에 대해 생성된 인접 배열에는 얼굴당 3개의 항목이 있지만 일부 얼굴에는 세 가장자리 모두에 인접한 면이 없을 수 있습니다. 어떻게 인코딩되는가? 인접한 얼굴이 없는 항목은 0xffffffff 인코딩됩니다.

PRT는 2003년 여름 SDK 업데이트에 추가된 D3DX의 새로운 기능입니다. 전역 -llumination, 부드러운 그림자 및 하위 표면 분산과 같은 복잡한 조명 시나리오를 실시간으로 렌더링할 수 있습니다. SDK에는 기술을 게임에 통합하는 방법에 대한 설명서와 샘플이 포함되어 있습니다. PRT 데모 샘플 및 LocalDeformablePRT 샘플 샘플은 각각 꼭짓점당 및 픽셀별 조명 시나리오에 시뮬레이터를 사용하는 방법을 보여 줍니다. 이 항목 및 기타 항목에 대한 자세한 내용은 Peter Pike Sloan의 웹 페이지에서도 확인할 수 있습니다.

Direct3DDevice9::CreateRenderTarget을 사용하여 다중 샘플링된 렌더링 대상을 만듭니다. 해당 렌더링 대상에 장면을 렌더링한 후 StretchRect에서 렌더링 대상 텍스처로 이동합니다. 오프스크린 텍스트로 변경한 경우(예: 흐리게 하거나 피는 경우) 프레젠테이션하기 전에 백 버퍼에 다시 복사합니다().

디버그 DirectX 런타임을 설치했을 것입니다. 디버그 버전의 런타임은 개발자가 초기화되지 않은 버퍼로 버그를 catch할 수 있도록 버퍼를 정적으로 채웁니다. 만든 후에는 DirectSound 버퍼의 내용을 보장할 수 없습니다. 특히 버퍼가 0으로 표시된다고 가정할 수 없습니다.

효과 매개 변수의 변경 내용이 DirectX 8에서 즉시 수행되지는 않습니다. 효율성을 위해 DirectSound는 버퍼가 재생되기 전에 재생 커서에서 시작하여 버퍼에서 100밀리초의 사운드 데이터를 처리합니다. 이 전처리는 다음 모든 호출 후에 발생합니다.

IDirectSoundBuffer8::SetCurrentPosition
IDirectSoundBuffer8::SetFX
IDirectSoundBuffer8::Stop
IDirectSoundBuffer8::Unlock

DirectX 9부터 효과 Just-In-Time을 처리하는 새로운 FX 처리 알고리즘이 이 문제를 해결하고 대기 시간을 줄입니다. 이 알고리즘은 쓰기 커서 바로 앞에 효과를 처리하는 추가 스레드와 함께 IDirectSoundBuffer8::P lay() 호출에 추가되었습니다. 따라서 언제든지 매개 변수를 설정할 수 있으며 예상대로 작동합니다. 그러나 재생 버퍼에서 매개 변수 변경이 들리기 전에 약간의 지연(일반적으로 100ms)이 발생합니다. 이때 재생 커서와 쓰기 커서 사이의 오디오(그리고 좀 더 안쪽 여백)가 이미 처리되었기 때문입니다.

DirectSoundEnumerate()를 사용하여 사용 가능한 DSound 디바이스를 나열할 필요가 없는 경우 dsound.lib와 애플리케이션을 연결하지 않고 대신 COMs CoCreateInstance(CLSID_DirectSound...)를 통해 사용한 다음, Initialize(NULL)를 사용하여 DSound 개체를 초기화합니다. DirectSoundEnumerate()를 사용해야 하는 경우 LoadLibrary("dsound.dll")를 사용하여 dsound.dll을 동적으로 로드할 수 있습니다. GetProcAddress("DirectSoundEnumerateA/W") 및 GetProcAddress("DirectSoundCreateA/W") 등을 사용하여 해당 메서드에 액세스합니다.

DirectSound 도움말 파일에서 질문에 대한 답변을 찾을 수 없는 경우 여러 채널 오디오 데이터 및 WAVE 파일에서 사용할 수 있는 자세한 정보가 포함된 좋은 문서가 있습니다.

DirectSound 9.0에서 버퍼를 복제하면 이제 중복 버퍼에서 IDirectSoundBuffer8 인터페이스를 가져올 수 있습니다. 그러면 AcquireResources 메서드에 액세스할 수 있습니다. 이렇게 하면 버퍼를 하드웨어 리소스와 DSBCAPS_LOCDEFER 플래그와 연결할 수 있습니다. 그런 다음 Play()를 호출하기 전에 이 버퍼에서 EAX 매개 변수를 설정할 수 있습니다.

다양한 버전의 DirectSound, 핵심 Windows 오디오 스택 및 커서 위치 알림을 신뢰할 수 없게 만드는 오디오 드라이버에는 몇 가지 미묘한 버그가 있습니다. 알림이 잘 동작한다는 것을 알고 있는 알려진 HW/SW 구성을 대상으로 지정하지 않는 한 커서 위치 알림을 사용하지 마세요. 위치 추적의 경우 GetCurrentPosition()은 더 안전한 기술입니다.

각 버퍼에 대한 각 GetCurrentPosition() 호출은 시스템 호출을 발생시키고 시스템 호출은 DSound CPU 공간의 큰 구성 요소이므로 최소화해야 합니다. NT(Win2K 및 XP)에서 SW 버퍼의 커서(및 일부 디바이스의 HW 버퍼)는 10ms씩 이동하므로 10ms마다 GetCurrentPosition()을 호출하는 것이 이상적입니다. 5ms마다 더 자주 호출하면 성능이 저하됩니다.

오디오 코드의 성능을 향상시키기 위해 수행할 수 있는 몇 가지 작업은 다음과 같습니다.

• GetCurrentPosition을 너무 자주 호출하지 마세요. 각 버퍼에 대한 각 GetCurrentPosition() 호출은 시스템 호출을 발생시키고 시스템 호출은 DSound CPU 공간의 큰 구성 요소이므로 최소화해야 합니다. NT(Win2K 및 XP)에서 SW 버퍼의 커서(및 일부 디바이스의 HW 버퍼)는 10ms씩 이동하므로 10ms마다 GetCurrentPosition()을 호출하는 것이 이상적입니다. 5ms마다 더 자주 호출하면 성능이 저하됩니다.

• 오디오에 대해 별도의 낮은 프레임 속도를 활용합니다. 요즘 많은 Windows 게임은 초당 100 프레임을 초과할 수 있으며 대부분의 경우 동일한 프레임 속도로 3D 오디오 매개 변수를 업데이트할 필요가 없습니다. 초당 또는 세 번째 그래픽 프레임마다 또는 30ms 정도마다 오디오를 처리하면 오디오 품질을 줄이지 않고 애플리케이션 전체에서 오디오 호출 수를 크게 줄일 수 있습니다.

• 3D 개체에 DS3D_DEFERRED 사용합니다. 대부분의 사운드 카드 매개 변수 변경에 즉시 응답하며, 특히 수신기의 위치 또는 방향을 변경하는 경우 단일 프레임에서 많이 변경 될 수 있습니다. 이로 인해 소리카드/CPU가 불필요한 계산을 많이 수행하므로 또 다른 빠르고 보편적인 최적화는 일부 매개 변수 변경을 연기하고 프레임의 끝에서 커밋하는 것입니다.

  또는 적어도 버퍼에서 개별 Set3DParamX 호출이 아닌 SetAllParameters를 사용합니다.

  마찬가지로 개별 Set3DParamX 호출 대신 3D 버퍼에서 SetAllParamenters 호출을 최소한 사용해야 합니다. 가능하면 시스템 호출을 최소화하기만 하면됩니다.

• 중복 호출을 하지 마세요. 재생 호출 목록을 저장하고 정렬합니다. 한 오디오 업데이트 프레임에 새 소리를 재생하라는 요청이 2개 있는 경우가 많습니다. 요청이 도착할 때 처리되는 경우 첫 번째 새 소리를 시작한 다음 두 번째 요청된 소리를 즉시 바꿀 수 있습니다. 이로 인해 중복 계산, 불필요한 재생 호출 및 불필요한 중지 호출이 발생합니다. 목록을 정렬할 수 있도록 재생될 새 소리에 대한 요청 목록을 저장하는 것이 좋으며, 재생을 시작해야 하는 음성만 실제로 재생됩니다.

  또한 각 사운드 소스에 대한 3D 및 EAX 매개 변수의 로컬 복사본을 저장해야 합니다. 매개 변수를 특정 값으로 설정하라는 요청이 있으면 검사 값이 실제로 마지막 값 집합과 다른지 확인할 수 있습니다. 그렇지 않은 경우 호출을 수행하지 않아도 됩니다.

  사운드 카드 드라이버는 이 시나리오를 감지하고 (동일한) 계산을 다시 수행하지 않지만 오디오 호출은 (링 전환을 통해) 오디오 드라이버에 도달해야 하며 이는 이미 느린 작업입니다.

오디오를 버퍼로 스트리밍하는 경우 AWC(After-Write-Cursor) 및 BPC(Before-Play-Cursor)의 두 가지 기본 알고리즘이 있습니다. AWC는 결함의 비용으로 대기 시간을 최소화하는 반면 BPC는 반대입니다. 일반적으로 스트리밍 사운드에 대한 대화형 변경 내용이 없기 때문에 이러한 종류의 대기 시간은 게임 및 유사한 애플리케이션에 거의 문제가 되지 않으므로 BPC가 더 적절한 알고리즘입니다. AWC에서 스트리밍 스레드가 실행될 때마다 쓰기 커서(일반적으로 N=40 정도, Windows 일정 지터를 허용)를 초과하여 루프 버퍼의 데이터를 최대 Nms까지 "위로" 올립니다. BPC에서는 항상 버퍼에 가능한 한 많은 데이터를 작성하여 플레이 커서(또는 플레이 커서 진행률을 잘못 보고하는 드라이버를 허용하기 전에 32바이트)까지 채웁니다.

BPC를 사용하여 결함을 모방하고, 게임이 테스트 하드웨어에서 결함이 없는 경우에도 버퍼를 100ms 이상 사용하면 일부 컴퓨터에서 결함이 있습니다.

시작 대기 시간(위에서 멘션 스트리밍 대기 시간과 다름)은 일부 하드웨어의 경우 문제가 될 수 있습니다(Play() 호출은 특정 사운드 카드 경우에 시간이 오래 걸립니다.) 이 대기 시간을 줄이려면 트위치 소리(총탄, 발자국 등)를 위한 편리한 트릭은 일부 버퍼가 항상 반복되고 침묵을 재생하도록 유지하는 것입니다. 트위치 사운드를 재생해야 하는 경우 무료 버퍼를 선택하고 쓰기 커서가 있는 위치를 확인하고 쓰기 커서 바로 너머의 버퍼에 사운드를 넣습니다. 일부 사운드카드는 지원한다는 것을 알고 있는 지연된 속성에 대해 QuerySupport에 실패합니다. 해결 방법이 있나요? 지연되지 않은 버전의 속성에 대해 QuerySupport를 수행하고 지연된 설정을 사용할 수 있습니다. 가장 최근의 소리카드 드라이버도이 문제를 해결할 수 있습니다.

Windows Media 인코더 9 시리즈의 Windows Media 인코더에 대한 설명서를 참조하세요.

DirectSound는 기본적으로 MP3 디코딩을 지원하지 않습니다. 직접 직접 파일을 디코딩하거나(DirectShow 필터의 ACM 코덱 사용) 직접 디코딩할 수도 있고, 디코딩을 수행할 수 있는 DirectShow 자체를 사용할 수도 있습니다. 그런 다음 결과 PCM 오디오 데이터를 DirectSound 버퍼에 복사할 수 있습니다.

NURBS는 지원되지 않습니다. 다각형 메시로 변환할 수 있습니다.

SUBD는 지원되지 않습니다. 다각형 메시로 변환할 수 있습니다.

미리 보기 창은 문제의 가장 엄격한 의미에서 애니메이션 효과를 제공하지 않습니다. 애니메이션을 재생하지 않고 대신 마야 장면의 최신 상태로 동기화됩니다. 애니메이션을 내보낼 때 각 변환의 행렬은 배율, 회전(쿼터니언) 및 변환 구성 요소(SRT라고도 함)로 분해됩니다. SRT는 잘 보간되고, 더 압축된 형태의 데이터를 제공하며, 독립적으로 압축할 수 있기 때문에 행렬보다 더 바람직합니다. 모든 행렬이 SRT로 분해할 수 있는 것은 아닙니다. 분해할 수 없는 경우 결과 SRT를 알 수 없으므로 애니메이션에서 작은 오류가 검색될 수 있습니다. 분해 중에 가장 자주 문제를 일으키는 Maya의 두 가지 기능은 전단과 오프 센터 회전 또는 저울입니다. 이 문제가 발생하는 경우 중심에서 벗어난 회전 또는 배율을 사용하므로 계층 수준을 높이는 변환을 추가하는 것이 좋습니다.

D3DX 애니메이션이 SRT를 지원하는 경우 다음과 같습니다.

[S]x[R]x[T]

Maya의 행렬은 훨씬 더 복잡하며 다음과 같은 상당한 양의 추가 프로세스가 필요합니다.

[SpInv]x[S]x[Sh]x[Sp]x[St]x[RpInv]x[Ro]x[R]x[Rp]x[Rt]x[T]

마야의 딱딱한 피부는 현재 지원되지 않습니다. 부드러운 스킨을 사용하세요.

X 파일은 IK를 지원하지 않습니다. 대신, IK 솔루션은 X 파일에 저장된 프레임에 구워집니다.

Maya용 DirectX 확장은 현재 미리 보기 및 내보내기용 DirectXShader 자료만 지원합니다. 이후 버전에서는 다른 자료가 지원될 수 있습니다.

예, 하지만 동일한 축으로 작동합니다. 따라서 DirectInput을 사용하여 트리거를 독립적으로 읽을 수 없습니다. XInput을 사용하여 트리거는 별도의 값을 반환합니다.

DirectInput이 트리거를 하나의 축으로 해석하는 이유에 대한 자세한 내용은 DirectInput에서 컨트롤러 사용을 참조하세요.

XInput은 한 번에 4개의 컨트롤러를 연결합니다.

아니요, 그렇지 않습니다.

예, DirectInput을 통해 일반 컨트롤러에 액세스할 수 있습니다.

XInputSetState 함수를 사용합니다.

헤드셋을 연결할 때 컨트롤러의 헤드셋은 표준 USB 오디오 장치 역할을 하므로 연결되면 Windows에서 이 USB 오디오 디바이스를 기본값으로 사용하도록 자동으로 변경됩니다. 사용자는 모든 오디오가 헤드셋을 통과하기를 원하지 않으므로 수동으로 원래 설정으로 다시 조정해야 합니다.

컨트롤러의 조명은 운영 체제에 의해 미리 결정되며 변경할 수 없습니다.

죄송합니다. 이 단추는 나중에 사용하도록 예약되어 있습니다.

드라이버는 Windows 업데이트 통해 사용할 수 있습니다.

XInput 시작 시 ID는 XInput 엔진 및 연결된 컨트롤러에 의해 결정되지 않습니다. XInput 애플리케이션이 실행되는 동안 컨트롤러가 연결되어 있는 경우 시스템은 새 컨트롤러에 사용 가능한 가장 낮은 수를 할당합니다. 컨트롤러의 연결이 끊어지면 해당 번호가 다시 사용할 수 있게 됩니다.

XInputGetDSoundAudioDeviceGuids 함수를 사용합니다. 자세한 내용은 AudioController 샘플을 참조하세요.

컨트롤러가 플레이어에서 사용 중인 경우 컨트롤러가 다시 연결되고 플레이어가 단추를 눌러 일시 중지할 준비가 되었음을 알릴 때까지 게임을 일시 중지해야 합니다.