Direct X

Microsoft DirectX.[1]



1995년 9월 30일에 첫 등장해, 마이크로소프트가 Windows 95 시절부터 개발해 오고 있는 윈도우용[2] 종합 멀티미디어 라이브러리.

역사 및 버전별 상세 정보는 DirectX/버전 정보 참조.

자신이 이용하는 응용 프로그램(주로 게임)이 요구하는 DirectX 버전이 Windows 운영 체제에서 이미 지원되고 있다면 기본적으로 별 다른 작업이 필요없다. 다만 Windows XP까지는[3] OS에서 기존 제공하는 초기 버전부터 추가 설치를 통한 마지막 버전까지 비교적 오랫동안 사후 지원되어서 사용자가 OS에서 기본으로 제공하는 버전보다 상위 버전으로 사용하려면 직접 설치해주지 않는 한 DirectX 버전 문제를 겪는 경우가 발생했기 때문에 응용 프로그램 패키지에 동봉된 최신 DirectX나 MS가 공식 배포하고 있는 DirectX 런타임을 다운로드받아 설치하는 걸로 조치해야 했다. 이 때문에 게임 같은 경우에는 설치 과정에서 DirectX가 없거나 구버전일 경우 DirectX를 같이 설치해주기도 했는데 어떤 게임은 DirectX 설치 여부를 확인하지도 않고 강제로 설치하는 바람에 구버전 DirectX가 덮어씌워져서 OS에서 온갖 오류가 발생하기도 했다. 그나마 Windows 2000과 XP가 서비스 팩을 통해 DirectX 버전을 업그레이드하는 방법이 있어 찾는 수고로움이 Windows 98에 비해 덜 하긴 했다.

Windows Vista부터는 업그레이드된 횟수가 98, 98 SE, Me, 2000, XP에 비해 상대적으로 적어서 그런 일을 해야 할 수고가 더 줄어들고[4] 9.0c 이전 버전은 Vista 이후 버전에도 실행할 수 있게끔 컨버팅[5]해놓으면서 레거시 상태로 유지되지만 구버전 라이브러리와의 호환성이 완벽한 건 아니라서 오래된 게임에서 간혹 DirectX 관련 실행 오류가 나타나는 경우가 있다. 주로 .dll 파일 누락이 원인이기에 해당 이름의 dll 파일을 찾아서 구하면 되지만 잘 모르겠다면 MS에서 제공하는 DirectX 최종 사용자 런타임(아카이브)을 통해 설치해주면 대부분 해결된다.

2011년 Windows 7 서비스 팩 1까지는 DirectX 런타임을 웹 브라우저를 거칠 필요없이 Windows 업데이트를 통해 구할 수 있어도 Windows와 DirectX 라이브러리 자체는 서로 분리되어 있었기 때문에 DirectX로 응용 프로그램을 개발하려면 DirectX SDK를 별도로 설치해야 했으나 Windows 8의 정식 출시로부터 1달 뒤인 2012년 11월에 Windows 8.0 SDK가 발표되면서 마지막까지 DirectX SDK에 있던 라이브러리들마저 Windows SDK에 전부 포함되어 굳이 DirectX SDK를 찾아서 설치할 필요가 없어졌다. 단 DirectX SDK에 사용했던 라이브러리와 소스 코드를 그대로 사용할 수 있는건 아니고 일부 라이브러리가 미지원되거나 변경된 부분이 있어서[6] 기존에 DirectX SDK로 개발했던 프로젝트를 Windows SDK 라이브러리 버전으로 변환하려면 해당 절차를 통해 수정해야 하는 번거로움이 있다. DirectShow를 비롯한 미디어 관련 라이브러리들은 이미 오래 전부터 Windows SDK에 흡수되었고 Windows Vista부터는 Media Foundation 소속 라이브러리로도 취급되었다.

물론 Windows (8.0 이후) SDK가 기본 설치 및 설정되는 비주얼 스튜디오 2012 이후 버전의 환경이라도 DirectX SDK 라이브러리로 개발하고 싶을 경우 DirectX SDK를 직접 다운로드받아 설치해서 경로를 추가 지정하면 DirectX SDK 환경처럼 개발할 수 있지만 DirectX SDK와 Windows (8.0 이후) SDK가 둘 다 설치된 상태이면서 개발 프로젝트에 둘 다 사용 가능하게끔 파일 경로를 지정하면 두 SDK에 있는 라이브러리들이 서로 충돌할 수 있는 문제점이 있다.

하지만 DirectX SDK가 레거시 SDK로 격하되었더라도 2012년 이전부터 개발 중인 게임이나 개발되어 출시된 게임들은 이미 구축된 소스코드를 함부로 수정할 수 없는 어려움이 있는데 수정하고 싶어도 선택과 집중에 있어서 우선 순위에 밀려 반영할 수 없는 개발사 차원의 복잡한 문제와 오랫동안 DirectX SDK에 몸 담가서 익숙해진 터라 2012년 이후 시점에 신규로 개발되는 프로젝트들도 DirectX SDK로 개발하려는 일부 기성 게임 개발자의 성향이 남아있기 때문.

DirectX SDK를 붙잡고 싶은 개발자들도 언젠가 DirectX SDK를 버려야겠지만 DirectX 11.0 버전이 여전히 현역인건 물론이고 최신 버전인 12보다도 훨씬 더 많이 사용될만큼 굳이 버려야 할 필요성이 약해서 DirectX SDK를 버리고 Windows (8.0 이후) SDK로 갈아타기까진 생각보다 오랜 시일이 걸릴 것으로 보이며 Windows 10 SDK를 통해서만 개발할 수 있는 DirectX 12로 완전히 갈아탈 때까진 DirectX SDK는 한동안 계속 사용될 것으로 보인다.

라이브러리 충돌 없이 DirectX SDK로 개발하려면 DirectX 계열 라이브러리들이 완전히 포함된 Windows 8.0 이후 버전의 SDK를 사용하지 말아야 하는 제약 조건이 불가피해지는데 이를 갖추려면 비주얼 스튜디오 자체를 처음 설치하는 경우 2010 이전 버전이나 인스톨러에서 Windows SDK를 아예 하나도 설치하지 않게 구성할 수 있는 2017, 2019 버전 중에 하나 설치해서 사용하면 되고 이미 2012, 2013, 2015 버전 중에 하나가 설치되어 그대로 사용하고 싶다면 프로젝트 속성 메뉴에서 포함할 라이브러리 파일의 경로 설정을 바꿔야 기본 설치 및 설정된 Windows 8.0 또는 8.1 SDK를 사용하지 않게 변경 및 지정할 수 있지만 프로젝트 생성할 때마다 속성 변경해야 해서 속성 시트를 따로 만들어줘야 하는 작업이 필요하다.

반대로 Windows (8.0 이후) SDK가 기본적으로 포함되지 않는 비주얼 스튜디오 2010 환경에서 DirectX SDK가 아닌 Windows 8.0 또는 8.1 버전의 SDK를 이용해서 개발하는 것도 가능하다. Windows SDK 아카이브를 통해 다운로드 받아서 설치한 후 비주얼 스튜디오의 프로젝트 속성에서 경로를 추가 지정해주면 된다. 보다 자세한 내용은 해당 블로그 게시글을 참조.

버전별 Windows SDK의 요구 사양은 다음과 같다. 최신 Windows SDK의 요구 사양, Windows SDK 버전별 요구 사양

현재 Windows SDK 아카이브에서 제공하는 가장 오래된 SDK가 7.1 버전이기 때문에 7.0 이전 버전을 찾으려면 마이크로소프트 공식 홈페이지의 다운로드 센터나 이를 첨부(업로드)한 보유자의 게시글 등 다른 곳에서 찾아야 한다.

DirectX는 하나의 API가 아닌 컴포넌트 형태의 여러 API들로 구성된 "집합체"이므로 그 중에 사용하고자 하는 컴포넌트의 이름이 무엇인지 확인해야 한다.

DirectX 2.0부터 도입된 3D 그래픽 API이자 가장 긴 역사를 지니고 있는 컴포넌트로 3D 그래픽의 중요성이 커진 이후로 지금까지 DirectX 전체를 통틀어서 가장 높은 비중을 차지한다. 이 때문에 DirectX 9.0 이후로 새로운 메이저 버전을 소개할 때 Direct3D 위주로 개선되다 보니 Direct3D만 부각시키는 경향이 강해졌다. 그동안 DirectX SDK에 소속된 주요 라이브러리였으나 Windows 8부터는 독립되어 있던 DirectX SDK 자체가 Windows SDK에 포함된 라이브러리로 소속이 옮겨지면서 일부 사용법과 문법이 변경되었다. 최신 버전은 Direct3D 12로 Direct3D 11 계열 기준으로는 Direct3D 11.4.

DirectX 11부터 도입된 2D 그래픽 API로 DirectX SDK와 Windows SDK(7.0 버전 이상)에 둘 다 존재하는 라이브러리다.[12] 내부적으로는 Direct3D를 거쳐서 동작하는 원리라서[13] 초창기에 존재했던 DirectDraw와 GDI/GDI+ 를 대체하는 포지션이긴 하다. DirectX 8.0부터 Direct3D로도 2D 그래픽을 구현할 수 있기 때문에 존재감이 약하지만 2D 그래픽으로만 구성된 게임을 프로그래밍하는데 있어서 개발 난이도가 Direct3D보다 더 쉽다는 장점이 있다. 최근에 들어서는 Direct3D에 있던 일부 기술들을 2D에 적용시켜 버전을 거듭할 때마다 퀄리티가 상승되고 있다. Direct2D를 그래픽 하드웨어로만 돌릴 수 있는 권장 사양이 DirectX 10.1이지만[14] 하위 호환 버전인 DirectX 10.0까진 문제없이 돌릴 수 있고 기반이 다른 DirectX 9.0에서도 CPU 사용률이 높아지긴 하지만 Direct3D를 이용하면 돌릴 수 있다.

Windows 8.0 SDK, Directx 11.1부터는 Direct2D도 1.1로 판올림되면서 2D 그래픽임에도 멀티스레딩을 지원해 기존 1.0보다 동일자원에서 퍼포먼스가 5배나 크게 올랐다. Windows 8.1 SDK, Directx 11.1부터는 Direct2D도 1.2로 판올림되면서 3D 그래픽에서나 접하는 지오메트리 개념을 Direct2D에 접목시키면서 활용도가 더욱 넓어졌다. Windows 10 SDK 이후에는 대격변되어 메쉬 기반의 그라디언트, 벡터 기반의 SVG 파일 호환 등을 비롯해서 기능이 매우 다양해졌다. 최신 버전은 Direct2D 1.3으로 Windows SDK 10.0.15063 이후로 업데이트가 없는 상태.

UI에서의 그래픽적 요소로는 GDI(+)가 커널 레벨에서 소프트웨어로 처리되고 세션당 65535개로 핸들이 제한되지만, Direct2D의 경우 GDI의 핸들 제한이 없는데다 GPU 가속을 사용하기 때문에 더 가볍고 빠르며 안티 앨리어싱 등 품질 또한 우수하다.

DirectX 11부터 도입된 2D 그래픽 API이자 문자 및 글꼴 전용 API로 Direct2D와 함께 사용하기 때문에 쌍두마차 격으로 판올림되고 있다. Windows 8부터는 Direct2D와 마찬가지로 역시 DirectX SDK 소속에서 Windows SDK 소속으로 옮겨졌다. 최신 버전은 DirectWrite 1.3으로 Direct2D와 마찬가지로 Windows SDK 10.0.15063 이후로 업데이트가 없다.

Direct2D와 함께 기존의 GDI/GDI+를 대체하기 위해 등장하였다. GDI에 비해 하드웨어로 가속되는 폰트 렌더링이나 폰트의 회전 등에 GPU 가속을 사용하게 된다. 또한 기존의 GDI/GDI+ 기반 폰트 렌더링은 시스템 레벨에서 클리어타입이 전역으로 적용되나 DirectWrite의 경우 폰트 힌팅에 기존 클리어타입은 물론 HiDPI 디스플레이에서 권장되는 그레이스케일 기반 렌더링을 적용하는 것도 가능하다. 대표적인 것이 인터넷 익스플로러 10/11[15], 마이크로소프트 엣지, 마이크로소프트 오피스 2016 이상의 버전[16]이다.

Direct2D와 DirectWrite를 사용하여 프로그램을 작성하는 경우 Windows 10의 레거시 HiDPI 업스케일링은 동작하지 않으며 네이티브로 구현하여야 한다.

DirectX 10부터 도입된 커널 모드 드라이버 - 그래픽 하드웨어 간의 통신[17]을 위한 API로 과거에는 Direct3D 런타임 라이브러리가 전담했으나 추후에 등장할 후속 버전에 포함될 다른 컴포넌트들과의 상호 호환성 및 유연성을 위해 별도의 컴포넌트로 분리되었다. 최신 버전은 Windows SDK 10.0.15063부터 도입된 DXGI 1.6.

DirectX 11부터 도입된 GPGPU용 API로 GPGPU를 위한 API 자체는 이미 서드파티 API인 NVIDIA의 CUDA와 오픈소스 재단인 크로노스 그룹에서 정식으로 발표된 OpenCL이 먼저 알려졌다가 대세에 따라 MS도 DirectX 차원에서 정식으로 사용할 수 있도록 추가되었다. 셰이더 모델 4.0 이상을 요구하기 때문에 DirectX 10에서도 사용 가능하지만 기능이 일부 제한된다.

DirectX 10.1부터 도입된 저수준 언어 기반의 사운드/오디오 API로 XInput과 마찬가지로 XBOX 360의 XAudio에서 비롯되었다. 최신 버전은 XAudio 2.9

DirectX 12(Version 1809)부터 도입된 레이트레이싱용 API로 GeForce 20 RTX 시리즈와 TITAN V 등 하드웨어 레이트레이싱 코어가 없어도 사용할 수 있으나 퍼포먼스는 당연히 레이트레이싱 전용 코어가 없이는 많이 떨어진다.

DirectX 12(Version 1903)부터 도입된 기계 학습용 API로 DirectX 12 지원만 충족된다면 NVIDIA의 텐서 코어같은 전용 연산 장치가 없어도 동작할 수 있다. WinML의 구성 요소이기도 하다.

하복 엔진을 인수하여 제작되는 물리엔진 컴포넌트다

개발 중단되었기 때문에 더이상의 개선판을 볼 수 없지만 개발만 중단되었을 뿐 사용할 수는 있다. 단 권장하는 라이브러리가 아니므로 구형 시스템과의 호환성을 위해 부득이 사용해야 할 상황이 아닌 이상 최신 시스템이라면 가급적 현역 컴포넌트를 사용하는 것이 더 낫다. 일부 라이브러리는 Windows Vista 이후 버전부터 아예 사용할 수 없다.

참고로 미디어 관련 라이브러리들은 Windows 8이 출시되기 이전부터 Windows SDK에 있던 Media Foundation으로 일찌감치 흡수되었다.

DirectX 10.1부터 도입된 게임패드 전용 입출력 API로 XBOX 360에 사용된 XInput을 PC 플랫폼에서도 사용할 수 있게 개선되었으나 태생이 XBOX 360에서 출발한 컴포넌트이다보니 해당 라이브러리를 사용하려면 최소 DirectX 9.0 이상의 하드웨어가 필요하다. Windows 8.1에 포함된 Xinput 1.4 버전을 마지막으로 Windows.Gaming.Input 라이브러리로 대체되었기 때문에 마이크로소프트는 하위 호환성을 제외하면 WGI로 개발할 것을 권장하고 있다. WGI와 XInput의 차이는 오버헤드 감소, 최대 8개의 디바이스 지원, 임펄스 트리거 지원 등의 기능이 추가된 점이다.

초창기부터 DirectX 7까지 개발된 2D 그래픽 API로 2D 그래픽 게임의 프로그래밍에 있어서 필수적인 컴포넌트였으나 2D와 3D가 통폐합된 DirectX 8.0부터 제거되면서 사용률이 점차 반강제적으로 떨어졌고 훗날에 등장한 Direct2D가 2D 그래픽 API의 자리를 이어받게 되었다. 게임업계의 소식에 따르면 이 때 미국의 개발자들 중에서도 반발이 상당했다고 전해진다.

윈도우 7 이상의 OS에서 고전 게임을 플레이할 때 화면의 색깔이 깨져 보인다면 십중팔구 DirectDraw에 관련된 문제일 가능성이 매우 크다. 예를 들자면 스타크래프트(~ 1.16.1) 같은 게임들이 이런 문제가 있다. 여기를 참조하여 문제를 해결해보도록 하자. DirectDraw Compatibility Tool이라는 건데 레지스트리를 수정해 화면의 색이 깨지는 것을 막아준다.

XInput이 등장하기 전 까지 DirectX 1.0 초기부터 존재했던 입출력용 API.
XInput과 WGI가 게임패드만 지원하는것과 달리 키보드와 마우스 입력 장치 또한 DirectInput을 사용하는 것이 가능하였다(다만 DirectX 3.0부터). DirectX 5.0에서는 컨트롤러 진동 기능이 추가되었다.
초창기 게임패드들과 XInput을 사용하는 XBox 360 컨트롤러가 등장하기까지 이 둘은 혼용되었으며 레이싱 휠, 게임패드 어댑터(듀얼쇼크 → PC USB변환기 등), 건슈팅 조이스틱 등 상당히 많은 제품들이 이 API를 지원한다.

DirectX 1.0 초기부터 존재했던 사운드 API. 여러 개의 소리를 동시에 처리할 수 있는 믹싱 기능이 기본적으로 제공되며 샘플링 주파수 변경, 볼륨 조절 등 기본적인 오디오 신호 처리 기능이 제공되었다. 신규 기능 추가는 DirectX 8.0까지였으며 9.0에서는 추가 기능 없이 성능만 개선되었고 그 뒤로는 더이상 버전업이 되지 않았으며 현재는 XAudio2로 대체되었다.

Windows XP까지는 ASIO 같은 특수한 API를 사용하지 않는 이상 모든 소리가 이 DirectSound를 거쳐서 출력했는데 이 과정에서 50 ~ 100 ms 수준의 딜레이가 발생했으며, 여기에 강제 리샘플링까지 발생했기 때문에 Low Latency가 요구되는 작업(작곡 등)이나 Bit Perfect가 요구되는 작업(Hi-Fi 음원 등)에 사용하기 부적합했다. 또한 프로그램에서 특수한 선언을 정의하지 않으면 Kernel Wave Audio Mixer(이하 KMixer)라는 것을 거쳤는데, 이 과정에서 100 ~ 200 ms 정도의 딜레이가 추가로 발생해서 악명이 높았다. 결국 Windows Vista부터는 DirectSound와 KMixer를 완전히 없애고 WASAPI로 대체했다. 문제는 이 과정에서 하드웨어 가속 기능까지 없애버리는 바람에 EAX가 안 먹게 되었다.

DirectX 3.0부터 존재했던 3D 사운드 API. DirectX 5.0부터는 하드웨어 가속을 지원하도록 지원하고 있다. Creative의 EAX도 DirectSound3D를 기반으로 한 확장 API에 가깝다.
Windows Vista부터 오디오 드라이버 구조가 바뀌고 WASAPI의 도입으로 더이상 사운드의 하드웨어 가속을 지원하지 못하도록 되었다. 이 때문에 EAX 지원이 막히는 등 게임 쪽에서 대혼란이 발생했다. 사실상 현재는 사용할 수 없는 API고 DirectX 10부터 없어졌다.

원래는 Interactive Music Architecture라는 이름으로 ActiveX 컨트롤 중 하나로 소개되었다가 DirectX 6.1부터 DirectMusic이라는 이름으로 정식으로 수록된 API. 기본적으로 DirectSound와 비슷한 일을 하지만 MIDI를 기반으로 한 인터랙티브한 BGM 연출 기능이 주력인 것이 특징. 원래의 의도는 게임의 전개에 따라 실시간으로 MIDI 음악을 생성해서 재생할 수 있도록 하는(실시간 BGM 작곡) 나름 신박한 비전을 가지고 있었지만 이미 이 API가 등장했을 때부터 MIDI를 사용하는 게임이 급속하게 줄어들던 시기였고 결국 DirectX 8.0부터 DirectSound쪽으로 통합되었으며 이후 단종되었다. Windows Vista부터는 호환성 문제를 일으키는 경우가 있다.

Cross-platform Audio Creation Tool의 이니셜 약자로 2002년에 처음 소개된 고수준 언어 기반의 사운드/오디오 API. 본래 Xbox Audio Creation Tool의 약자로써 XBOX 게임기를 위한 컴포넌트였다가 콘솔 게임기와 PC와의 크로스 플랫폼이라는 의미로 확장되어 지금의 용어로 자리잡았다. XACT3 버전을 마지막으로 Windows 8부터는 더이상 사후 지원이 이루어지지 않고 있다.

XNA에서도 기본적으로 포함되어 있었다.

Windows용 미디어 스트리밍 API로 1996년 3월에 발표된 ActiveMovie가 1997년 DirectX 5.0부터 DirectX의 일부로 편입되면서 DirectShow로 바뀌었다. 응용 프로그램에서 고품질의 비디오 및 오디오의 디코딩, 인코딩, 캡처를 수행할 수 있고 Windows Media Encoder 9에서도 사용되었으며 공용 코덱처럼 한 번 설치해두면 MF를 쓴 프로그램은 얻어쓸 수 있었으나 개발은 더 이루어지지 않는 듯 하다.
과거에는 DirectX SDK에 포함된 라이브러리였으나 2005년 2월 버전을 마지막으로 그 이후는 Windows SDK 소속으로 옮겨졌으며 Windows Vista부터는 Media Foundation으로 대체되고 있다.

COM 기반의 데이터 스트리밍 구성 요소로 동영상 디코더/인코더 및 효과와 같은 스트리밍 객체를 사용하기 위한 API. 동영상 하드웨어 가속 API인 DXVA가 여기에 포함되어 있다. DirectShow 필터처럼 입력 데이터를 가져 와서 출력 데이터를 생성하는 데 사용하지만 DirectShow보다 훨씬 간단하다는 장점이 있다. 현재는 Media Foundation에 있는 Media Foundation Transforms(MFT)에 의해 대체되었는데 DMO 인터페이스의 사용 자체는 가능하지만 MS에서는 사용자 지정 코덱 또는 오디오/비디오 처리 플러그인을 사용할 경우 MFT로 구현할 것을 권장하고 있다.

대한민국에서는 DirectX 7 이하에서는 잉여 취급받는 네트워크 API였다. 웬만한 개발자들은 죄다 직접 네트워크 코드를 따로 만들어 쓸 정도. 대한민국에서는 온라인 멀티플레이가 지원되는 패키지 게임이 대세가 된 시절이 거의 없었기 때문에 DirectPlay를 쓸 이유 자체가 별로 없었다.

한편 DirectPlay는 패키지 게임 시장이 활발한 해외에서는 가장 인기가 많은 네트워킹 API였다.

DirectPlay가 등장했던 1990년대 후반에는 우리가 지금 흔하게 쓰는 컴퓨터 네트워크가 TCP, UDP로 완전히 통일되던 시대가 아니었다. 모뎀 플레이, IPX 네트워크 등 일부 유저들까지도 모두 끌어안아야 했다. 그러나 당시에 IPX, 모뎀, TCP를 모두 지원하려면 소켓 API뿐만 아니라 제각각 다른 API를 다 가져다 써야 했다. 뿐만 아니라 게임을 플레이하는 사람 입장에서도 네트워크 플레이를 위해 통신선을 선택하는 UI가 게임마다 제각각 다른 것도 스트레스였다. DirectPlay는 이러한 문제점을 단일 API로 한큐에 끝내버릴 수 있었고 이는 당대에 만족스러운 선택이었다.

해외의 메이저 온라인 게임 서비스 업체들(가령 Gamespy)은 DirectPlay 지원을 필두로 내세웠고 수많은 패키지 게임이 DirectPlay를 지원함으로 인해 온라인 게임 서비스 업체들과의 에코시스템이 구축되고 있었다. 반면 대한민국의 게임 회사 중에 온라인 멀티플레이를 지원하는 패키지 게임을 개발하는 회사는 거의 없었고 해외 온라인 게임 서비스 또한 대한민국에 직접 진출한 사례가 없다가 뒤늦게 MMO 온라인 게임으로 크게 시장이 성장한 말하자면 해외에서 보기 힘든 특이한 형태로 게임 산업이 궤도를 달렸기 때문에 DirectPlay가 해외와 달리 인기를 얻을 기회가 없었다. 아무튼 DirectPlay는 해외에서는 최고의 인기있는 네트워킹 API였다.

그러나 2000년에 가까워지면서 IPX나 모뎀은 역사의 뒤안길로 빠르게 사라져나갔고 승자는 TCP, UDP였다. 모뎀 등을 지원할 필요 없이 그냥 Windows Socket API(Winsock)만 갖다 쓰면 간단하게 끝나버리는 시대가 와버린 것이다. 게다가 DirectPlay는 Winsock보다 사용법이 더 생소했다. 그렇다고 DirectPlay가 Winsock보다 사용법이 그렇게 쉬운 것도 아니었다. 모뎀, IPX등을 지원하는 기능을 어떻게든 맞물려야 하는데 쓸 필요도 없는 기능에 수고를 해야 했다.

결국 Windows Socket API가 대세가 되면서 DirectPlay가 뒤로 밀려나버렸다. 대규모 멀티플레이 온라인 게임(MMO)에는 DirectPlay가 감당을 전혀 못한 점도 영향을 미쳤다.

한편 DirectX 8으로 오면서 DirectPlay는 큰 변화가 있었다. Direct3D 10이 그랬던 것처럼 아예 백지부터 제작된 것이나 다름없는 새로운 물건으로 등장한 것이다.

DirectX 8의 DirectPlay는 드디어 MMO 게임도 개발할 수 있는 성능을 가지게 되었다. 게다가 보이스챗과 게임플레이 네트워킹에 대해서 QoS 기능을 제공하는 등 기존 Winsock에서 해주지 않았던 혁신적인 기능들을 무장했다. 그러나 DirectPlay는 IPX, 모뎀 플레이를 지원하는 등 과거의 굴레를 완전히 벗어나지는 못했다. 그럼에도 불구하고 DirectX 8의 DirectPlay는 과거의 오명을 완전히 뒤집어버릴 정도로 엄청난 성능을 보여주었다. 물론 과거의 악몽 때문에 여전히 사용 비율은 높지 않다. 사실상 DirectX 8.0에서 버전업이 끊겼다.

고전 게임을 플레이 할 때 이 DirectPlay와 관련해서 오류가 나는 경우가 있는데 이 경우엔 제어판 → 모든 제어판 항목 → 프로그램 및 기능 → Windows 기능 켜기/끄기 창에서 레거시 구성 요소 혹은 DirectX 항목에 체크한 다음 확인 버튼을 클릭하면 설치가 된다.[18]

DirectPlay의 기술력은 이제 모두 XNA로 넘어갔으며 PC와 Xbox용 게임 개발에서 네트워크 멀티플레이를 하는 용도로 사용되고 있다. 그리고 XNA 역시 2013년을 끝으로 업데이트가 중단되었다.

DirectX 7부터 제공된 개발 관련 편의를 위한 보조적인 유틸리티 라이브러리. DirectX SDK가 별도로 존재하던 시절인 Windows 7까지는 정식으로 포함되어 있었지만 Standalone SDK가 Deprecated 처리되고 Windows SDK로 포함된 Windows 8부터 D3DX 자체가 Deprecated처리되었으며 마이크로소프트는 호환성과 성능 문제로 인해 공식적으로 사용을 권장하고 있지 않다.
d3dx9. d3dx9_42.dll와 같이 d3dx로 시작하는 라이브러리와 헤더 파일이 이에 포함된다.

버전에 대한 역사 및 버전별 지원 운영 체제에 대한 정보는 DirectX/버전 정보 항목 참조.

Windows CE에서는 GAPI(Game API)라고 내장 DirectX를 보강한 애플리케이션이 있다.

그래픽뿐만 아니라 사운드 쪽도 지원하는데 DirectSound가 그것이다. DirectX에는 좀 늦게 포함이 되었고 초기 기능은 보잘것 없었기 때문에 초기 윈도우 게임들은 사운드 효과가 많이 떨어졌다. 1990년대 중후반에 나온 게임들이 효과음만 PCM(WAV)을 사용하고 배경 음악을 CD 트랙이나 MIDI를 사용하는 것은 이런 이유 때문. 두 개 이상의 PCM을 믹싱해서 출력하는 기능이 떨어졌기 때문이다. 이후 DirectSound가 많이 발전하면서 배경 음악도 PCM으로 넣어 믹싱해서 출력하는 것이 가능해졌고 DirectX 3.0부터 DirectSound3D 컴포넌트가 추가되면서 3D 사운드도 지원하게 되었고 5.0 버전부터 3D 사운드를 취급하는 여러 서드파티 개발사가 개발한 규격들을 지원하게 되었다. 비슷하게 MIDI 음악 지원을 위해 DirectMusic이 추가되었으나 현재는 빠지고 DirectSound와 사운드 드라이버가 그 자리를 맡고 있다. MS에서는 게임의 플레이 상황에 따른 실시간 곡 변조나 실시간 BGM 생성을 기대했으나 이미 MIDI의 시대는 가버렸다. DirectX 8.0부터는 이들을 합쳐서 DirectX Audio라고 명명되었고 XBOX360 출시 이후 XAudio라는 이름으로 변경되었으며 2008년 3월에 Windows에도 XAudio가 도입되면서 XAudio 2로 업그레이드되었으며 현재는 Windows 10 SDK와 함께 등장한 XAudio 2.9가 최신 버전.

그 외에 동영상과 음악 코덱같은 멀티미디어 프로그래밍을 위해 DirectShow가 한때 추가되었으나 금방 Windows SDK 쪽으로 퇴출되었고 Windows Vista 이후 버전부터 Media Foundation으로 대체되는 중이다. 그런데 동영상을 화면에 출력하려면 DirectX에 포함된 구 버전 DirectDraw 라이브러리를 필요로 한다.

Windows XP가 나오기 이전까지는 웬만한 기능 향상마다 버전이 1 단위로 올라갔는데 덕분에 거의 매년마다 새 메이저 버전이 나와서 정신을 차릴 수 없을 정도였다.

Windows Vista 이후의 최신 윈도우에서는 DirectX 10 이후 버전은 제대로 내장되어 있지만 DirectX 9.0c 이전 버전은 제대로 내장되어 있지 않기 때문에 DirectX 9.0c 이전 버전으로 개발된 게임을 실행하려고 하면 d3dx9_××.dll이 없어서 게임을 실행할 수 없다는 메시지가 뜬다.[19] 이는 DirectX End-User Runtime(DirectX 최종 사용자 런타임)을 설치해주면 해결된다. 다운로드(마이크로소프트 홈페이지) 물론 어디까지나 DirectX 문제만 해결하는 것이기에 다른 호환성 문제로 게임에 문제가 발생하는 것까지는 막을 수 없다.

Windows 8과 함께 나온 DirectX 11.1, Windows 8.1과 함께 나온 DirectX 11.2, Windows 10과 함께 나온 DirectX 11.3, 12 이후에도 DirectX 9.0, 9.0c, 11.0 게임으로 개발되는 이유는 DirectX 11.0까지는 DirectX SDK를 이용하는 기존 방식대로 개발할 수 있으며 특히 최적화가 잘 되어 있고 DirectX 12에서는 아직 11에서의 기능이 다 구현되어있지 않은데다 더욱이 오랜 기간 동안 그래픽 회사들이 드라이버 중심적인 최적화와 안전성을 잘 해두었기에 개발자들이 편하게 개발할 수 있었지만 DirectX 12에서는 개발자에게 요구하는 스펙이 더 늘어나서 메모리 관리부터 그래픽에 모든 부분을 드라이버가 다해주던 것을 이젠 개발자가 하드웨어까지 공부해서 일일이 바닥부터 최적화를 시켜야 하는 방향으로 바뀌었기 때문이다. 즉 DirectX 11에서는 그래픽카드 드라이버가 알아서 다 해주던 것을 DirectX 12에서는 개발자가 대부분 하게 되었다는 것이다.

그런데 개발자들이 새로운 기술을 빨리 받아들이고 호응해준 것에는 개발자 편의 지향적인 기술이었기에 가능했던 일이라는 점. 빠른 퍼포먼스와 퀄리티를 뽑으려면 3dfx의 글라이드 API가 진리였던 1990년대 후반에 글라이드 API를 따라잡기 위해 게임에 도움이 되는 온갖 기술들과 개발 편의성을 절치부심으로 연구한 끝에 DirectX 5.0부터 SDK 꾸러미로써 초석을 갖추고 6.0 → 6.1 → 7.0에 들어서 획기적인 기술들을 대거 추가하자 글라이드 API를 편애했던 개발자들에게도 인정받았던 곳이 1999년 당시의 마이크로소프트였다.

그리고 DirectX 12의 장점이 오버헤드 감소로 인한 향상된 퍼포먼스(프레임속도)였는데 실제로 개발하면 이론만큼 그다지 빠르지 않다는 점. 오히려 최적화 잘못 시키면 DirectX 11보다 더 느려질 수 있다는 것이다. 그리고 그래픽 카드 회사들의 지원 부분이다. DirectX 12는 특이하게도 NVIDIA보다는 인지도가 낮은 AMD가 더 잘해준다고 한다. 단지 속도 면에서 AMD가 좋은 것뿐만 아니라 NVIDIA도 몇 달째 해결해주지 않은 버그도 바로바로 수정해준다고 한다. 다만 단점도 있는데 AMD는 드라이버에 별의 별 짓을 다 해서 새로운 버전마다 구조가 너무 바뀌어서 골치아프다고 한다. 반면 그래픽 카드 회사에서 가장 큰 손이라 할 수 있는 NVIDIA는 DirectX 12 부분에 드라이버 최적화와 안전성이 떨어지며 2019년 현재 아직까지 하드웨어로 실시간 렌더링으로써 시험기에 가까운 레이트레이싱과 딥 러닝을 이용한 안티에일리어싱에 집착하고 있다. 무엇보다 마이크로소프트 쪽의 개선 속도가 느린 점도 문제가 되고 있다. 4년째 접어든 지금이야 버그가 많이 수정되었지만 초기 버그는 다음 Windows 10 대규모 업데이트까지 기다려야 할 정도로 바로 수정이 안 되며 해당 대규모 업데이트에 안 되었다면 또 다시 다음 대규모 업데이트까지 기다려야 하는 상황이었던 것이다.

결론적으로 DirectX 11.0이 Windows 7과의 호환성과 다양한 그래픽 기술 그리고 드라이버 최적화 등 개발 환경에서 훨씬 우수하다. 하지만 마이크로소프트가 주도적으로 적극적으로 밀어 붙이고 개선을 하다보니 많은 개발자들은 DirectX 12에 대한 전망을 좋든 싫든 높게 보고 있다. 그리고 기존 그래픽 기술만 알던 개발자들도 하드웨어를 공부하고 최적화를 배워야 한다는 관점도 늘었다는 것이다. 다만 아직까진 개발자들 입장에서 DirectX 12는 11.0으로 제작 중인 게임의 성능 향상이 안 나올 때 최대한 하드웨어에 성능을 쥐어짜서 최적화시켜야 할 부득이한 상황에서 마지못해 사용하는 버전인 것으로 보고 있다. 특히 메모리 관리 부분이 까다로워서 DirectX 12로 개발할 경우 자칫하면 메모리를 더 소모하게 될 가능성이 높다.

애초에 마이크로소프트도 DirectX 12 버전을 생각만 하고 있었을 뿐 개발할 생각은 없었던 API였다. 그러다 AMD의 맨틀이라는 API가 DirectX 11의 게임 가속 방식은 느리다는 인식을 심어주면서 어쩔 수 없이 DirectX 12를 발표했다는 이야기가 많다. 이는 AMD가 가장 자부심을 느끼는 부분으로 우리가 없었으면 DirectX 12는 없었을 것이라는 발언을 하기도 했다. 드라이버에서 충분한 최적화를 하면 성능이 잘 나올 수 있고 개발자들도 게임 개발이 편했던 DirectX 11이었기에 게임 성능이라면 누구보다 예민했던 NVIDIA가 병렬식 비동기 컴퓨팅(AMD에서는 '비동기 셰이더')을 도입하지 않는 등 적극적이지 않았던 이유도 이런 이유였다.

.NET Framework의 두번째 UI 라이브러리인 WPF(Windows Presentation Foundation)는 Windows API의 GDI, GDI+를 쓰는 Windows.Forms와 다르게 DirectX 렌더링 방식이다.

DirectX 9이하는 일부 그래픽 카드에서 가속이 제대로 되지 않아 프레임 드랍이 생겨 dgvoodoo같이 호환용 DirectX 드라이버를 지원하는 글라이드 래퍼로 해결해야한다.[20]