DirectX

(Redirected from Direct3D)
DirectX
Component of Microsoft Windows
Directxlogo.png
Current DirectX logo
Introduced inWindows 95

Microsoft DirectX is a collection of COM-based APIs for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms.

Originally all API names started with "Direct" in their names (Direct3D, DirectDraw, etc.), thus the name DirectX was coined as a shorthand term for all of these APIs (the X standing in for the particular API names) and soon became the official name of the collection.

WinG & DCI[edit | edit source]

The first true attempt to bring fast video performance to Windows came in the Virtual Flat Framebuffer Device (also known as VFLATD[1] or DVA.386 – Direct Video Access), which shipped as part of Video for Windows (VfW), enabling the DrawDib functions to circumvent GDI and write decompressed video frames directly into VRAM. While it had some limitations to the size of framebuffer it could support, it did allow for much faster framebuffer access by using a page-fault handler to emulate linear framebuffers on banked display adapters. VfW also supported DISPDIB.DLL, which supported shutting off GDI to allow a program to write directly to the VGA framebuffer (KERNEL.EXE exported a selector for A0000h). On Windows NT, VfW used either a DIB section or DCI to draw to the screen, and DISPDIB is actually implemented on top of DrawDib.

Windows NT 3.5 added the CreateDIBSection API call to GDI, which allowed one to create an HBITMAP backed by a device-independent-bitmap in user-accessible memory (prior to this, the only method to display a DIB using GDI was via API calls such as SetDIBits, which converted a DIB to a DDB, which was a slow process) and thus have a device context with a DIB selected into it. As such, one could both use GDI calls to draw onto the DIB and draw the DIB onto the screen using speedy functions such as BitBlt. The reason for the naming of the API is that Windows NT memory objects are referred to as sections, and in fact you can create a DIB section around existing memory by passing a section handle; otherwise, GDI (really, CSRSS; the Client-Server Runtime Subsystem) will create one for you. The DIB section is in shared memory between your application and the subsystem server where GDI (and the display driver and its mapped memory) lives.

Windows 95 (then known as "Chicago") also added this API call, in conjunction with the introduction of the DIB engine (first detailed, along with the DIB DC-related API calls, in the 1992 Chicago specification, and implemented as early as July 1992). The DIB engine was designed to simplify development of Windows 95 display drivers, allowing video card vendors to simply ship a "minidriver" which provided code to set video modes and provide a pointer to the framebuffer, while the DIB engine would take care of everything else. The DIB engine was optimized for packed-pixel 8/16/24/32-bit framebuffer arrangements, since those framebuffers were the same format as Windows DIBs (while many prior cards had unusual framebuffer arrangements, including multi-plane graphics).

The DIB engine allowed GDI to treat the entire screen as one big GDI bitmap – one big DIB (and allowed both applications and GDI to access the same bitmap), and many drivers (particularly those for banked SVGA adapters) used VFLATD for this, but many drivers also used DCI, or the Display Control Interface, which was also part of the VfW technology wave. DCI expanded on VFLATD, allowing support for multiple offscreen surfaces and framebuffers above 1MB in size. DCI was designed primarily for digital video, and thus supports color spaces such as YUV as well as acceleration of video decompression and stretching. DCI was encumbered by legal action from Apple, who claimed that code used in DCI had been developed for them by a third-party company in an attempt to speed up video performance under QuickTime for Windows, and the same company later contracted with Intel.

DCI was implemented with display drivers (including DVA.386 and DCISVGA.DRV) implementing a "DCI provider", which communicated with the DCI Manager (DCIMAN.DLL / DCIMAN32.DLL) client DLL via message passing. In most cases, DCI clients would be libraries such as WinG or Video for Windows, but applications could call into the DCI Manager directly to open the DCI provider and access the framebuffer.

WinG was a port of an early version of the Chicago DIB engine to Windows 3.1x, and most of its functions are parallels to GDI calls added in Windows 95 / NT 3.5. On Windows 3.1, a WinGDC is distinct from an HDC, as is a WinGBitmap from an HBITMAP, and WinGBitBlt/WinGStretchBlt vs BitBlt/StretchBlt, since WinG uses its own video path despite hooking into GDI through WINGDIB.DRV, but on NT 3.50 / 95, they're interchangeable. This places some limitations on what you can do with WinG on Windows 3.1; standard GDI BitBlt functions cannot blit between WinG DCs and GDI DCs, and the DIB engine (WINGDE.DLL) acts as a GDI driver to allow standard GDI operations onto WinGDCs. Meanwhile, one must use WinG to blit from a WinGDC (with a DIB selected onto it) to a GDI (display/screen) DC, as WinG will then obtain a pointer to the framebuffer of the GDI DC and draw onto it, or fall back to StretchDIBits if required.

Many early Windows 95 games, such as WinDoom and Fury 3, use WinG (often in conjunction with Win32s), but it was soon discontinued and replaced with DirectDraw. One well-known application using WinG acceleration is Microsoft Bob.

Microsoft did port DCI to 32-bit Windows, including Windows NT 3.51 (to a limited extent), and DCI 2.0 evolved into DirectDraw (DirectDraw in fact identifies itself as DCI 2.0, and the APIs with the concept of onscreen and offscreen primary surfaces is the same, with the DirectDraw design team starting from DCI), with the DCI API being subsumed into DirectX (which used a COM-based interface as opposed to a C-based API), with some structures, enumerations, error codes, and return values being shared. When a DirectDraw driver is unavailable on a Windows 9x operating system, it can fall back to use DCI if available via the Hardware Emulation Layer (and then it will fall back to the DIB engine as a last resort). Additionally, OPENGL32.DLL (the software OpenGL 1.1 renderer for Windows) used DCI to draw to the screen, as did the original version of GDI+, because the same redistributable DLL file had to be able to work not only on NT systems, but also on the 9x family, where very old drivers without DirectDraw support could be installed. On Windows 9x, DirectDraw will also use DISPDIB.DLL to draw fullscreen graphics in any VGA-compatible modes (i.e. 320x200x256 Mode 13h or 320x240x256 Mode X).

Starting with Windows NT 4.0, Microsoft began stripping out DCI support from the operating system, removing several DCI-related exports from GDI32.DLL, removing support for DCI from display drivers, and reimplementing the DCI Manager APIs on top of DirectDraw and GDI. The reason for this was simple; NT 4.0's video architecture had been redesigned, moving large parts of GDI and USER (and the new DirectDraw, which started work on NT shortly after NT 4.0's development began) into the kernel-mode module WIN32K.SYS, meaning that the NT 3.x display drivers that implemented DCI directly would be incompatible, so a clean break could be made to supplant DCI. Several DCI functions closely map to DirectDraw equivalents, such as DCIBeginAccess being implemented on top of IDirectDrawSurface_Lock, and DCICreatePrimary mapping to IDirectDraw_CreateSurface. DCI surfaces are implemented as a thin wrapper over DirectDraw surfaces, but the API is heavily stripped down, only supporting a single surface. Meanwhile, Windows 95/98/Me continued to have full native support for DCI as a peer to DirectDraw, since DCI display drivers were still supported. Vestigial DCI Manager support remains in modern versions of Windows NT despite the absence of the lower-level components. DirectDraw development began in 1994 (after the early WinG betas) for Windows 95 as the first serious effort to make graphics performance on Windows competitive with DOS, enabling games to shift over to Windows.

Development on Video for Windows-related technologies and WinG as out-of-band updates to the operating system did not continue after Windows 95, at which point they were integrated into the OS as core components.

Components[edit | edit source]

DirectX is composed of multiple APIs,[2] the most commonly known ones as follows:

  • Direct3D (D3D): Real-time 3D rendering API.
  • Direct2D: Current 2D graphics API.
  • DirectDraw: Deprecated 2D graphics API.
  • DirectSound: Deprecated Audio API (replaced by XAudio2 and XACT3).
  • DirectX Diagnostics (DxDiag): A tool for diagnosing and generating reports on components related to DirectX, such as audio, video, and input drivers.
  • DirectX Media for Audio/Video acceleration (deprecated).
  • DirectWrite, a Text rendering API.
  • DirectInput, an input API for interfacing with keyboards, mice, joysticks, and game controllers (deprecated).
  • DirectPlay, a network API for communication over a local-area or wide-area network (deprecated).
  • DirectX Ray Tracing (DXR): Light ray-tracing API.
  • DirectShow: The streaming media technology intended to replace Video for Windows, originally known as ActiveMovie (deprecated)

Versions[edit | edit source]

DirectX 4 was never released. Raymond Chen of Microsoft explained that after DirectX 3 was released, Microsoft began developing versions 4 and 5 in parallel. Version 4 was planned as a short-termed release with minor changes, whereas version 5 would've been a bigger release. Due to the lack of interest from game developers in the DirectX 4 features it was soon canceled, and the large amount of documents that already distinguished the two new versions resulted in Microsoft choosing to not re-use version 4 to describe features intended for version 5.[3]

Gallery[edit | edit source]

  • Setup (9.0c, June 2010)

    Setup (9.0c, June 2010)

  • Diagnostic Tool in Windows XP

    Diagnostic Tool in Windows XP

  • Diagnostic Tool in Windows 7

    Diagnostic Tool in Windows 7

  • DirectX 5 ViewPoint Collection Release Notes, mentioning the cancellation of DirectX 4

    DirectX 5 ViewPoint Collection Release Notes, mentioning the cancellation of DirectX 4

References[edit | edit source]

  1. ↑ https://www.os2museum.com/wp/undocumented-vflatd/
  2. ↑ https://en.wikipedia.org/wiki/DirectX#Components
  3. ↑ https://devblogs.microsoft.com/oldnewthing/?p=40963
Retrieved from "https://betawiki.net/index.php?title=DirectX&oldid=344706"