Пакет средств разработки directx под microsoft windows

What’s New in the June 2010 DirectX SDK

This version of the DirectX SDK contains the following new features, tools, and documentation.

Visual Studio 2010 Support

The June 2010 DirectX SDK includes support for Visual Studio 2010. The DirectX SDK will continue to support Visual
Studio 2008 as well. However, Visual Studio 2005 will no longer be supported.

PIX: Object Naming Support

The June 2010 version of PIX supports naming for most resource objects
in Direct3D (D3D). Direct3D enables developers to
attach arbitrary data to objects in D3D code using the SetPrivateData API for application-specific usage.
PIX will now display specific string data for objects in the Object Table and other user interface elements where a
human-readable object name will provide a much more effective experience for the user.

PIX: Usability Improvements

The June 2010 version of PIX includes improvements to the PIX user interface:

• The Object Table shows the size and shader model for each shader.
• In the Shader Debugger, there is a new toolbar button that enables the display of all constant registers/variables
  immediately, rather than the first time they are read.
• In the Shader Debugger, it is possible to copy register and variable data to the clipboard.
• The Summary pane has a new Direct3D Information section, that shows details about what
  Direct3D capabilities are present on the computer.

XNAMath C++ SIMD Math Library

The June 2010 release updates XNAMath to version 2.03, which includes the following changes:

• Addition of XMVectorDivide to optimize SSE2 vector division operations
• Unified handling of floating-point specials between the Windows SSE2 and no-intrinsics implementations
• Use of Visual Studio style SAL annotations
• Modifications to the C++ declarations for XMFLOAT2A/3A/4A/4X3A/4X4A to
  better support these types in C++ templates

Version-less Naming of Cross-Runtime Data Types

The June 2010 DirectX SDK removes versioning from several Direct3D data types that cross runtime versions. This change
makes legacy data-type names equivalent to the new version-less data-type names. Therefore, you can use either
legacy or version-less names. However, your code will be cleaner and easier to maintain if you use the version-less
names.

New D3DCreateBlob Function

The June 2010 DirectX SDK includes a D3dcompiler_43.dll that exports the new D3DCreateBlob function. Therefore,
you are no longer required to use D3d10.dll to create and use an arbitrary length data object.

New ID3D11ShaderReflection Method

The June 2010 DirectX SDK adds the following new method to the ID3D11ShaderReflection interface:

• GetThreadGroupSize

New HLSL Language fixes and features

HLSL has been updated with the following fixes and features:

• The frexp intrinsic function has been updated to return a mantissa in the range of [0.5,1.0].
• New intrinsic functions have been added for better debugging support.
  • printf — submits custom shader messages to the information queue.
  • errorf — submits custom shader error messages to the information queue.
  • abort — submits custom shader error messages to the information queue and terminates
    the current draw or dispatch call being executed.
• Left-Hand-Side typecasting is now illegal and will cause a compile error.
  • Expressions such as (int)myFloat = myInt; are no longer valid. Use myFloat = (float)myInt; type syntax instead.

New HLSL Compiler fixes and features

The HLSL Effects compiler (fxc.exe) has been updated with the following fixes and features:

• No-optimization (/Od) compiles will produce less-optimized code than before in order to provide improved debugging.
• No-optimization (/Od) now implies (/Gfp).
• New compression (/compress) and decompression (/decompress) options have been added to enable the bundling and unbundling of shader files.
• A new numbering instructions (/Ni) flag has been added to turn on numbering of instructions in shader disassembly.
• Fxc.exe has a new @command.option.file feature for specifying command options in a file. This enables the /compress and /decompress
  options to be used on many files at once.

New D3D11 HLSL Format Conversion Functions

The new D3DX_DXGIFormatConvert.inl inline header includes light-weight conversion functions for use in Compute Shaders or Pixel Shaders on
D3D11 Hardware that can be useful when applications need to simultaneously read and write to textures, such as in-place editing scenarios.

Documentation Enhancements

The June 2010 DirectX SDK includes the following documentation enhancements:

• Added links to descriptions of data types for parameters and return values to help developers locate related types.
• Added additional header and lib information to reference pages for APIs implemented in DirectX samples.

Previous Releases

For a description of what was added in previous releases, see Features Introduced in Previous Releases in the DirectX SDK documentation.

Known Issues with the June 2010 DirectX SDK

Support for Visual Studio 2010 and Visual Studio 2005

Beginning with the June 2010 release, the DirectX SDK supports Visual Studio 2010. The June 2010 release continues to support Visual Studio 2008 Service Pack 1. The DirectX SDK no longer supports Visual Studio 2005; the February 2010 release was the last release to support Visual Studio 2005.

Support for DirectSetup

Beginning with the June 2010 DirectX SDK, DirectSetup no longer supports operating systems earlier than Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1.

Visual Studio 2008 Path Registration Sometimes Fails

In the June 2010 release, the DirectX SDK installer will attempt to automatically register the executable, include, and library path settings needed for compilation of samples and other DirectX programs. In some circumstances, however, automatic registration fails and, therefore, attempts to include DirectX SDK headers result in errors. To work around this issue, manually add the proper path registration to Visual Studio. For more information, see the instructions in the topic «Installing DirectX with DirectSetup» in the section «Install the DirectX SDK».

DirectX SDK Does Not Register Include/Library Paths with Visual Studio 2010

With Visual Studio 2010, the model for adding include, library, and executable paths has changed. In Visual Studio 2008 and previous versions, paths were specified as global settings under Tools\Options. With Visual Studio 2010, paths are now specified on a per-project basis on a VC++ Directories page. All the Visual Studio 2010 projects for the DirectX SDK samples and tools include direct per-project references to the DirectX SDK—via the DXSDK_DIR environment variable—and will compile without any additional steps. New projects that make use of DirectX SDK headers, libraries, or tools should have these references added to the VC++ Directories property page. For more information, see the topic «Installing DirectX with DirectSetup» in the section titled «Install the DirectX SDK», as well as the Visual Studio team blog entry: Visual Studio 2010 C++ Project Upgrade Guide.

Samples Content Exporter Requires Visual Studio 2008

In the June 2010 DirectX SDK, the Samples Content Exporter is designed to use Autodesk FBX SDK 2010.2. The Samples Content Exporter does not work with later versions of the Autodesk FBX SDK (2011.x). Also, the Autodesk FBX SDK does not yet support Visual Studio 2010, and the DirectX SDK Visual Studio 2010 projects for the Samples Content Exporter therefore use the ‘v90’ toolset provided with Visual Studio 2008. As a result, you must have Visual Studio 2008 installed in order to compile the Samples Content Exporter. For more information, see the Visual Studio team blog post entry: C++ Native Multi-Targeting.

Help Integration for Visual Studio 2010

The new Microsoft Help System (MHS), delivered via Visual Studio 2010, enables you to view documents on the MSDN Library using a standard browser. You can also select documents to download from the MSDN Online content publication web site (MSDN cloud) to your computer for viewing when a connection to the Internet is unavailable or undesirable. You can access this functionality from the Help Library Manager. To launch the Help Library Manager, select:

Start | All Programs | Visual Studio 2010 | Visual Studio Tools | Help Library Manager

The MHS is set to Online Mode by default. The first time you click a Help shortcut, you will be asked to confirm that you wish to connect to the Internet to view documentation in the MSDN cloud. If you wish to view documentation when a connection to the Internet is unavailable, you can import documentation sets (books) from the MSDN cloud and install these books to your computer. You can then switch to Offline Mode to view content on your computer by default.

• To import content to your local computer for viewing in offline mode, select «Install Content from online» in Help Library Manager. For the DirectX SDK documentation, select the «Win32 and COM Development» content title.
• To check for updated content in the MSDN cloud that you can import, select «Check for updates online» in Help Library Manager.
• To remove imported content from your local computer, select «Remove content» in Help Library Manager.

If you import content to your local computer, use Help Library Manager to specify, «I want to use local help» to switch to Offline Mode.

Documentation Organization

Beginning with the August 2009 DirectX SDK, the Windows Graphics documentation is provided as a separate documentation collection from the main DirectX SDK documentation collection. The Windows graphics documentation collection includes content for Direct3D 9, Direct3D 10.x, Direct3D 11, D3DX, DXGI, and HLSL.

Direct2D Documentation

In the June 2010 release, the Direct2D documentation is incorrectly marked preliminary and subject to change. This is the official, release documentation for Direct2D; this warning can be safely ignored.

Direct3D 11 Runtime

To obtain the Direct3D 11 runtime, please install the release version of Windows 7 or Windows Server 2008 R2. Windows Vista users can follow the procedure described in KB 971644 (or KB 971512 for corporate network users). For more details, see Direct3D 11 Deployment for Game Developers.

Effects 11

The Effects runtime for Direct3D 11 (FX11) is available as shared source in the DirectX SDK. For more information, please refer to Effects (Direct3D 11) and Effect System Interfaces (Direct3D 11) in the Windows Graphics documentation. The Effects 11 source is now located in the samples directory(Samples\C++\Effects11).

DirectX 11 Runtime Symbols

The modern DirectX Runtime is part of the operating system (OS), and symbols for the DirectX components (Direct3D, DirectInput, DirectSound, etc.) are provided as part of the OS symbol packages. DirectX 11 Runtime symbols are included in the Windows 7 and Windows Server 2008 R2 symbols packages available on the Microsoft website. However, we recommend using the Microsoft symbols server instead for the most current and correct set of symbols when debugging DirectX applications.

Note that DirectX 11 Runtime symbols for the down-level KB 971644 and KB 971512 update for Windows Vista and Windows Server 2008 are not included in the OS offline symbols package. They can be obtained from the Microsoft symbol server.

The Provided D3D9D.dll for Windows XP is Versioned for Service Pack 2

The D3D9D.dll that is included in the February 2010 and later DirectX SDKs is versioned for Windows XP SP2. If you use this DLL on Windows XP SP3 with an application that uses the Windows Presentation Framework (WPF), the code in the DLL will assert. This issue does not occur on Windows Vista or Windows 7. If you require only debug output, that is, you do not require symbols, you could also use the checked version of D3D9.dll, which is compatible with Windows XP SP3. Just rename the checked D3D9.dll to D3D9D.dll. The checked version of D3D9.dll is available to MSDN subscribers.

Control Panel for DirectX 9 Debug Output is Specific to 32-bit or 64-bit Applications

In order to turn DirectX 9 debug output on or off, you must use the DirectX control panel appropriate to the application being debugged. Use the 64-bit DirectX control panel for 64-bit applications and the x86 DirectX control panel for 32-bit applications.

D3DCompiler_42.dll and D3DCompiler_43.dll Are in Their Own Cab

Beginning in the August 2009 DirectX SDK release, D3DCompiler_*.dll has been moved out of the D3DX CAB to a new CAB: D3DCompiler_*_*.CAB. The D3D_Compiler functionality implements the offline HLSL compiler for D3D 9, 10, or 11. This change decouples the compiler from D3DX.

New Warning X3206: Implicit Truncation of Vector Type

Beginning in the August 2009 release of the DirectX SDK, the HLSL compiler will warn when an implicit truncation of a vector type occurs. For example, the follow code would elicit the warning.

float4 FastShadow ( float3 vLightPos, float4 vDiffColor )

{

float2 vLightMax = vLightPos + g_fFilterSize;

if ( bTextured ) In.vDiffColor.xyz *= DiffuseTex.Sample ( DiffuseSampler, In.vTCoord );

To avoid the warning, swizzle out the vector components as shown below.

float4 FastShadow ( float3 vLightPos, float4 vDiffColor )

{

float2 vLightMax = vLightPos.xy + g_fFilterSize;

if ( bTextured ) In.vDiffColor.xyz *= DiffuseTex.Sample ( DiffuseSampler, In.vTCoord ).xyz;

IXACT3Engine::PrepareWave Doesn’t Support xWMA

In the March 2008 and later SDKs, the IXACT3Engine::PrepareWave doesn’t support xWMA. If you want to use xWMA in XACT, you can prepare those waves by calling one of the following methods:

• IXACT3WaveBank::Prepare
• IXACT3SoundBank::Prepare
• IXACT3Engine::PrepareInMemoryWave
• IXACT3Engine::PrepareStreamingWave

Symbols for DirectX

The latest and most complete source for debugging symbols is the Microsoft Symbol Server. We recommend using the symbol server rather than using the included partial symbols package. For instructions about using the Microsoft Symbol Server, see http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx.

Installation Notes for All Platforms

• This SDK is supported on the most recent service packs of the following operating systems: Windows XP, Windows Server 2003, Windows Server 2008, Windows Vista, Windows 7, and Windows Server 2008 R2. This SDK supports Visual Studio 2008 Service Pack 1 and Visual Studio 2010.
• Before installing the current DirectX SDK, remove previous versions of the DirectX SDK.
• Use the Samples Browser to install samples included with the DirectX SDK.
• Some samples require that you have installed the latest Microsoft Windows SDK on your system.
• If you are using Visual Studio and run the Platform SDK Integration tool, all custom include and library paths will be erased for Visual Studio 2008, including those added by the DirectX SDK. To fix the issue, developers need to either reinstall the DirectX SDK or manually add the paths to Visual Studio 2008.
• If you encounter compilation issues related to the DirectX headers, make sure that the include directories in Visual Studio 2008 are set correctly. On the Win32 platform, make sure that there is a reference to the DirectX headers. «$(DXSDK_DIR)include» should appear in the include directory «$(VCInstallDir)Include.» In Visual Studio 2010, this directory should be added on a per-project basis in the VC++ Directories property page in the project properties dialog.
• Several virus protection software applications interfere with SDK installation. They may require you to disable virus protection software until SDK installation is completed.
• Your system may be corrupted, or cryptographic services may be disabled, if you encounter the following error message during installation: «A cabinet file is necessary for installation and cannot be trusted.» To resolve the problem, try the following:
  1. Enable cryptographic services. On the Start menu, right-click My Computer, and then click Manage. The Computer Management window appears. In the left navigation pane, click Services and Applications. In the right pane, double-click Services, and then double-click Cryptographic Services. The Cryptographic Services Properties property sheet appears. On the General tab, ensure that Service Status is Started, and that Startup Type is Automatic.
  2. If you are running Windows on a FAT32 drive, run scandisk.
  3. Try the resolution steps in Detecting digital signing issues in Windows XP.
  4. Try the resolution steps in You cannot install some updates or programs.
  5. Remove temporary files in the %temp% folder. If you are installing an end-user runtime, also remove «%windir%\system32\directx\websetup Error.»
• External firewall programs may indicate that the file InstallDeveloperFiles.exe wants to access the Internet. This is by design, and should be enabled.

Материал из РУВИКИ — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 5 июня 2020 года; проверки требуют 47 правок.

DirectX (от англ. direct — прямой, непосредственный, произносится как «ДайректЭкс») — это набор API, разработанных для решения задач, связанных с программированием под Microsoft Windows. Наиболее широко используется при написании компьютерных игр.
Пакет средств разработки DirectX под Microsoft Windows бесплатно доступен на сайте Microsoft. Зачастую обновлённые версии DirectX поставляются вместе с игровыми приложениями.

Практически все части DirectX API представляют собой наборы COM-совместимых объектов.

В целом, DirectX подразделяется на:

• DirectX Graphics, набор интерфейсов, ранее (до версии 8.0) делившихся на:
  • DirectDraw: интерфейс вывода растровой графики (его разработка давно прекращена);
  • Direct3D (D3D): интерфейс вывода трёхмерных примитивов.
• DirectInput: интерфейс, используемый для обработки данных, поступающих с клавиатуры, мыши, джойстика и прочих игровых контроллеров.
• DirectPlay: интерфейс сетевой коммуникации игр.
• DirectSound: интерфейс низкоуровневой работы со звуком (формата Wave).
• DirectMusic: интерфейс воспроизведения музыки в форматах Microsoft.
• DirectShow: интерфейс, используемый для ввода/вывода аудио- и/или видеоданных.
  • DirectX Instruments — технология, позволяющая на основе мультимедийного API DirectX создавать и использовать программные синтезаторы. В отличие от DX-плагинов, такие программы могут полностью управляться по MIDI и служат главным образом не для обработки, а для синтеза звука. Технология DXi была популярна в 2001—2004 гг., особенно в программных продуктах Cakewalk, но со временем проиграла «войну форматов» технологии VST от Steinberg.
• DirectSetup: часть, ответственная за установку DirectX.
• DirectX Media Objects: реализует функциональную поддержку потоковых объектов (например, кодировщики/декодировщики).
• Direct2D: интерфейс вывода двухмерной графики.

Изначально нацеленный на разработку видеоигр, DirectX стал популярен и в других областях разработки программного обеспечения. К примеру, DirectX, наряду с OpenGL, получил очень широкое распространение в инженерном/математическом ПО.

В 1994 году Microsoft была практически готова выпустить следующую, революционную, версию Windows — Windows 95. Главным фактором, определяющим, насколько популярна будет новая ОС, являлся набор программ, которые можно будет запускать под её управлением. В компании пришли к выводу, что, пока разработчики видят DOS более подходящей для написания игровых приложений, коммерческий успех новой ОС весьма сомнителен.

DOS позволяла разработчику получить прямой доступ к видеокарте, клавиатуре/мыши/джойстику и прочим частям системы, в то время как Windows 95, с её защищённой моделью памяти, предоставляла более стандартизованный, но в то же время весьма ограниченный и накладный доступ к устройствам. Microsoft нуждалась в новом способе дать разработчику всё, что ему необходимо. Крэйг Айслер (Craig Eisler), Алекс Сэйнт Джон (Alex St. John) и Эрик Энгстром (Eric Engstrom) решили эту проблему, назвав само решение DirectX.

Первый релиз DirectX был выпущен в сентябре 1995 года под названием «Windows Game SDK».

Ещё до появления DirectX Microsoft включила OpenGL в ОС Windows NT. Direct3D позиционировался как замена OpenGL в игровой сфере. Отсюда берёт своё начало противостояние между сторонниками кросс-платформенной OpenGL и доступной лишь в Windows (в том числе Windows NT) Direct3D. Так или иначе, остальные части DirectX очень часто комбинируются с OpenGL в компьютерных играх, так как OpenGL как таковой не подразумевает функциональности уровня DirectX (например, доступа к клавиатуре/джойстику/мыши, поддержки звука, игр по сети и т. д.).

DirectX является базой для Xbox API; Xbox API схож с DirectX 8.1, но обновление версии, как и на других консолях того времени, невозможно.

В 2002 году Microsoft выпустила DirectX 9 с улучшенной и расширенной поддержкой шейдеров. С 2002 года DirectX неоднократно обновлялся. В августе 2004 года в DirectX была добавлена поддержка шейдеров версии 3.0 (DirectX 9.0c).

В апреле 2005 интерфейс DirectShow был перемещён в Microsoft Platform SDK.

Хронология версий DirectX[править | править код]

Временная шкала

Версия DirectX	Логотип	Номер версии	Операционная система	Дата релиза
DirectX 1.0		4.02.0095	Windows 95a	30 сентября 1995
DirectX 2.0 / 2.0a		4.03.00.1096	Windows 95 OSR 2 и Windows NT младше 4.0	5 июня 1996
DirectX 3.0 / 3.0a		4.04.0068 / 69	Windows 95 OSR 2.5 и Windows NT 4.0 SP3 последняя официально поддерживаемая версия DirectX для Windows NT 4.0	15 сентября 1996
DirectX 4.0		4.05.00.0155 (RC55)	Доступен как бета для Windows NT 4.0	16 июля 1997
DirectX 5.0		4.05.01.1721 / 1998	Windows 98	5 мая 1998
DirectX 6.0		4.06.00.0318 (RC3)	Windows 98 SE последняя поддерживаемая версия DirectX Media для Windows NT 4.0, а также данная версия DirectX была в Dreamcast	7 августа 1998
DirectX 6.1		4.06.02.0436 (RC0)	Windows 95/98/98SE	3 февраля 1999
DirectX 6.2		5.00.2516.1900 (unofficial patch)	Windows NT/98SE/98/2000/ME	21 августа 1999
DirectX 7.0		4.07.00.0700 (RC1)	Windows 2000 и Windows ME	22 сентября 1999
DirectX 7.0a		4.07.00.0716 (RC1)	Windows 95/98/98SE/2000	17 декабря 1999
DirectX 8.0		4.08.00.0400 (RC10)	Windows 95/98/98SE/2000/ME	12 ноября 2000
DirectX 8.0a		4.08.00.0400 (RC14)	Последняя поддерживаемая версия DirectX для Windows 95	5 февраля 2001
DirectX 8.1		4.08.01.0810	Windows XP/XP SP1, XBOX	25 октября 2001
4.08.01.0881 (RC7)	Windows 98/98SE/2000/ME	8 ноября 2001
DirectX 8.1b		4.08.01.0901		25 июня 2002
DirectX 8.2		4.08.02.0134 (4.09.00.0134)		27 сентября 2002
DirectX 9.0		4.09.0000.0900	Windows Server 2003	24 декабря 2002
DirectX 9.0a		4.09.0000.0901		26 марта 2003
DirectX 9.0b		4.09.0000.0902 (RC2)		13 августа 2003
DirectX 9.0c		4.09.0000.0904 (RC0)	Windows XP SP2 и Windows Server 2003 SP1 DirectX 9.0c с обновлениями по декабрь 2006 года — последняя поддерживаемая версия DirectX для Windows 98, Windows 98SE и Windows Me DirectX 9.0c с обновлениями по февраль 2010 года — последняя поддерживаемая версия DirectX для Windows 2000 DirectX 9.0c с обновлениями по июнь 2010 года — последняя поддерживаемая версия DirectX для Windows XP и Windows Server 2003	9 августа 2004
DirectX 9.0L		4.09.0000.0905 (?)	Предоставляет дополнительные интерфейсы IDirect3D9Ex и IDirect3DDevice9Ex с функциональностью, доступной лишь через LDDM-драйверы ОС Windows Vista.
DirectX 10 (включён в состав Windows Vista)		6.0.6000.16386	Первая версия для Windows Vista и Xbox 360. Информация по Direct3D10	10 ноября 2006
DirectX 10.1		6.00.6001.18000	Service Pack 1 для Windows Vista, Windows Server 2008	4 февраля 2008
DirectX 11 (включён в состав Windows 7)		6.01.7600.16385	Windows 7, Windows Server 2008 R2	22 октября 2009
6.00.6002.18107	Windows Vista SP2 и Windows Server 2008 SP2 через Platform Update for Windows Vista and Windows Server 2008[1]	27 октября 2009
6.01.7601.17514	Windows 7 SP1, Windows Server 2008 R2 SP1	16 февраля 2011
DirectX 11.1 (включён в состав Windows [2]		6.02.9200.16384	Windows 7 SP1, Windows 8, Windows RT, Windows Server 2012	1 августа 2012
DirectX 11.2 (включён в состав Windows 8.1)		6.03.9600.16384	Windows 8.1, Windows RT, Windows Server 2012 R2	18 октября 2013
DirectX 11.3 (включён в состав Windows 10)			Windows 10	29 июля 2015
DirectX 12 (включён в состав Windows 10)		10.00.10240.16384	Windows 10, Windows 11, Xbox One, Xbox Series X	29 июля 2015

Ключевые особенности[править | править код]

• DirectX 6.0 — мультитекстурирование
• DirectX 7.0 — аппаратная поддержка преобразований, обрезания и освещения
• DirectX 8.0 — шейдерная модель 1.1
• DirectX 8.1 — пиксельные шейдеры 1.4 и вершинные шейдеры 1.1
• DirectX 9.0 — шейдерная модель 2.0
• DirectX 9.0b — пиксельные шейдеры 2.0b и вершинные шейдеры 2.0
• DirectX 9.0c — шейдерная модель 3.0
• DirectX 9.0L — версия DirectX 9.0 для Windows Vista и выше
• DirectX 10 — шейдерная модель 4.0 (только Windows Vista, Windows 7, Windows
• DirectX 10.1 — шейдерная модель 4.1 (только Windows Vista, Windows 7, Windows
• DirectX 11 — шейдерная модель 5.0 (только Windows Vista, Windows 7, Windows 8/8.1)
• DirectX 11.3 / DirectX 12  — шейдерная модель 5.1 (Windows 10 , частично Windows 7)

Многие современные устройства имеют DirectX-совместимые драйверы, иными словами, пользователь должен установить DirectX для использования всех возможностей устройства. На данный момент система обновления драйверов Windows Update позволяет загружать только необходимые библиотеки, а не весь драйвер целиком.

Поддерживаемые операционные системы:

• Windows 95/98/98 SE/ME;
• Windows NT 4.0, Windows 2000, Windows 2000 Advanced Server, Windows 2000 Professional Edition, Windows 2000 Server, Windows 2000 Service Pack 2, Windows 2000 Service Pack 3, Windows 2000 Service Pack 4;
• Windows Server 2003, Windows Server 2003 Service Pack 1, Windows Server 2003 Datacenter x64 Edition, Windows Server 2003 Enterprise x64 Edition, Windows Server 2003 Standard x64 Edition, Windows Small Business Server 2003;
• Windows XP, Windows XP 64-bit, Windows XP Home Edition, Windows XP Media Center Edition, Windows XP Professional Edition, Windows XP Service Pack 1, Windows XP Service Pack 2, Windows XP Service Pack 3, Windows XP Starter Edition, Windows XP Tablet PC Edition;
• Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10, Windows 11;
• Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2016, Windows Server 2019, Windows Server 2022.

Библиотеки обёртки[править | править код]

В случае возникновения различных проблем при использовании устаревших приложений и игр можно воспользоваться специальной библиотекой-обёрткой (wrapper).

На текущий момент существует несколько таких вариантов, в том числе трансляция вызовов в другие API, но высокая скорость работы возможна только из «DirectX в DirectX».

• dgVoodoo2 — обёртка для запуска устаревших игр на основе DirectX 1-7 и также 8-9 в DirectX 11/12 с уровнем функций 10/10.1/11 или через WARP. В первую очередь использовался для запуска Glide игр, но позже была добавлена поддержка DirectX.^[3]
• dxwrapper — обёртка для запуска DirectX 1-8 в DirectX 9.^[4]
• D9VK — обёртка для использования DirectX 9 игр и приложений под Vulkan без необходимости их переписывать.^[5]
• WineD3D — обёртка, превращающая команды DirectX в OpenGL

• GDI
• OpenGL
• Vulkan (API)
• Mantle (API) (от AMD)
• Simple DirectMedia Layer
• X (DirectX) — формат файла для хранения 3D-объектов, разработанный Microsoft для DirectX
• Direct3D 10
• Direct3D 11
• Direct3D 12
• WinG

• Адамс Д. DirectX: продвинутая анимация. Комплект. — «КУДИЦ-ПРЕСС», 2004. — С. 480. — ISBN 5-9579-0025-7.
• Nigel Thompson. 3D Graphics Programming for Windows (англ.). — Microsoft Press, 1996. — 328 p. — ISBN 1572313455. — ISBN 978-1572313453.

• DirectX End-User Runtimes (June 2010) (англ.)

Microsoft DirectX – это очень просто!

О чем пойдет речь в статье:

Что такое DirectX?

Для чего нужен DirectX?

Что входит в DirectX?

Что такое шейдер?

Зачем нужны шейдеры? Конвейер и шейдерная модель

Что дает пользователю компьютера очередная версия DirectX?

DirectX 10. Эволюционное обобщение пройденного

DirectX 10.1 Как же теперь жить? И пара слов об OGL

Когда говорят о “Microsoft DirectX”, то разные категории людей могут вкладывать в это различные понятия. Давайте разберемся, что может иметься в виду и что это такое на самом деле, для чего он нужен и чем же отличаются последние версии DirectX друг от друга.

Что такое DirectX?

Обратимся к первоисточнику – самой Microsoft:

http://msdn2.microsoft.com/en-us/library/bb219737.aspx


“DirectX is a set of low-level APIs for creating games and other high-performance multimedia applications. It includes support for high-performance 2D and 3D graphics, sound, and input”.

Учитывая, что API (Application Programming Interface) – это интерфейс разработки программ, буквальный перевод звучит так:
“DirectX – это набор низкоуровневых программных интерфейсов для создания игр и других высокопроизводительных приложений. Он включает в себя поддержку высокопроизводительной 2D и 3D графики, звука и устройств ввода”.

Применим эти знания на практике. Если моя карта поддерживает DirectX, это значит, что она … поддерживает набор низкоуровневых…. ну и далее по вышеприведенному тексту. Не срастается! Что-то здесь не так. Что же на самом деле поддерживает видеокарта? Попробуем разобраться.

В действительности, Microsoft предоставляет это определение для разработчиков программного обеспечения, следовательно, само собой под DirectX подразумевается APIs DirectX. А с точки зрения пользователя все выглядит несколько иначе. Поэтому дадим более общее определение, хотя оно при этом будет подлиннее.

DirectX – это технология Microsoft для операционных систем семейства Windows, предоставляющая разработчику программного обеспечения интерфейсы (то есть, комфортную среду интерактивного взаимодействия) для создания программ, эффективно использующих графические, мультимедийные устройства и устройства ввода, и обеспечивающая низкоуровневые утилиты (то есть эффективные высокооптимизированные программы) для взаимодействия этих устройств с прикладной программой и операционной системой через соответствующие драйверы.

Другими словами, вполне логично различать понятия DirectX как технологии в целом, как наборов программных интерфейсов при создании программного обеспечения и как программной составляющей операционной системы, отвечающей за поддержку мультимедийных и графических устройств, а также устройств ввода.

Для поддержки разработчиков программного обеспечения Microsoft предоставляет DirectX SDK (Software Developing Kit) – набор программ и утилит разработчика программного обеспечения под технологию DirectX, а для системных программистов и разработчиков компьютерного оборудования есть WDK (Windows Driver Kit )– набор программ и утилит для разработки драйверов. Оба этих программных продукта распространяются свободно и доступны для скачивания с сайта Microsoft. К слову сказать, по прилагаемой к DirectX SDK лицензии, все графические и мультимедийные файлы и компьютерные модели разрешается использовать в своих программах для демонстрационных некоммерческих целей.

Теперь можно смело утверждать, что если моя видеокарта поддерживает DirectX, то это означает, что она способна выполнять программы, созданные с использованием API DirectX, при условии наличия соответствующего драйвера и поддержки со сороны операционной системы.

Сегодня уже трудно найти видеоадаптер, не поддерживающий хотя бы DirectX 7, поэтому для нормальной работы приложения, разработанного в соответствии с конкретной спецификацией DirectX, нужно, во-первых, чтобы операционная система поддерживала эту версию (плюс к тому были установлены соответствующие или более новые библиотеки DirectX в виде dll – файлов, которые обычно автоматически устанавливаются при инсталляции программы, если на компьютере установлены более старые версии библиотек), во-вторых, чтобы видеокарта была с поддержкой соответствующего DirectX и, в третьих, чтобы был установлен подходящий драйвер видеокарты. Несоблюдение первых двух условий не позволит приложению запуститься, а в случае с драйвером может оказаться так, что самый последний доступный драйвер не является лучшим для конкретного приложения (вплоть до полной неработоспособности программы), хотя, в целом, действует правило, что лучше использовать самые свежие версии драйверов и рекомендуется этого правила придерживаться.

Часто можно услышать фразу “графический стандарт DirectX”. Это верно лишь c большой натяжкой, особенно до DirectX 10, поскольку ничто не мешало производителям видеокарт легко утверждать о соответствии DirectX даже при несоответствии этой спецификации (хотя она и делится на обязательную и опциональную часть), вводя покупателя и пользователя в заблуждение. Этому способствовало и порождение компанией Microsoft нескольких вариантов DirectX одной версии и, в особенности, множества модификаций шейдерных моделей (SM — Shader Model), чем особенно отличилась версия DirectX 9. Впрочем, этому есть и свое логичное объяснение. Так сложилось исторически, что, хоть программируемый конвейер и возможность исполнения шейдеров впервые появились в версии DirectX 8, настоящая их обкатка происходила уже в DirectX 9.

Но к конвейеру и шейдерам мы вернемся чуть позже.

Для чего нужен DirectX?

Несколько слов о том, что явилось катализатором появления DirectX. Безусловно, в первую очередь, это компьютерные игры. Персональные компьютеры и сейчас далеки от вычислительной мощности, позволяющей кинематографически реалистично воспроизводить на экране монитора с высоким разрешением полноценное интерактивное 3D действие в реальном режиме времени, тем более это им было не под силу двадцать лет назад. Поэтому программисты всегда боролись за каждый байт и мегагерц компьютерных ресурсов (а основные ресурсы – это процессорное время и оперативная память), выжимая все из топовых аппаратных решений, доступных на рынке. И в эпоху, когда основной ОС домашних компьютеров была DOS, очень много игр писалось на языке Ассемблер, что было достаточно трудоемко, но в умелых руках позволяло использовать 100% возможностей техники, так как позволяло напрямую программирвать видеокарту, модель распределения памяти и управлять системными ресурсами. Для тех, кто не застал это время, поясню, что, в отличие от Windows, MS-DOS (наиболее распространенная ОС того времени) – это однозадачная ОС, то есть запускаемая программа забирала все компьютерные ресурсы себе. Чтобы запустить другую программу, первую нужно было обязательно завершить, что часто делалось простой перезагрузкой компьютера.

Производители видеокарт тоже включились в эту гонку, выпуская новые и новые видеокарты, которые частенько и опережали свое время, и оказывались впоследствии тупиковым направлением развития. Но это уже совсем другая история.

Появление новой ОС – Windows 3.х привело к противоречию между конкретной программой, требующей в свое распоряжение максимальное количество ресурсов, и многозадачной ОС, делящей эти ресурсы по “справедливости” между приложениями. Кроме того, драйверы устройств перестали быть доступны программе напрямую – появилась прослойка в виде виртуальных драйверов. Несмотря на имеющуюся иерархию приоритетов у выполняемых в ОС программ, в первых версиях Windows быстродействие игр оказывалось неудовлетворительным. Поэтому долгое время DOS, которой разработчики игр отдавали предпочтение, сосуществовала параллельно с Windows. Но такое положение вещей не вписывалось в стратегию развития Microsoft и привело к интенсификации усилий по решению имеющихся проблем с быстродействием. Так появилcя Game SDK, впоследствии сменивший название на DirectX, призванный сделать программную прослойку от выполняемой программы до мультимедийного и графического оборудования универсальной, не требующей детального знания оборудования (это – дело производителя, задача которого – написать функциональный драйвер), легко создаваемой и сопровождаемой, минимальной по длине и максимальной по быстродействию.

Что входит в DirectX?

Мы выяснили, что означает, фраза “моя карта поддерживает DirectX”. Впрочем, тут есть один нюанс. DirectX – это собирательное понятие набора программных компонент, и, хоть графическая часть и есть его наиболее существенная, сложная и объемная составляющая, там присутствует и поддержка оборудования, отличного от видеокарт. К примеру, видеокарта вряд ли поддерживает DirectInput (хотя технически ничто не мешает, например, установить на ней пару USB-разъемов для подключения джойстика или геймпада). Поэтому, правильно говорить о поддержке видеокартой компоненты DirectGraphics (которая, на самом деле, только “прикрывает” настоящие компоненты – Direct3D и Direct3DХ), составной части DirectX, но маркетинг – он и в Африке маркетинг – поэтому не только короче, но и гораздо солиднее звучит именно вариант поддержки DirectX целиком! И никаких гвоздей! Поэтому от этого стереотипа уже практически не избавиться. Мы ведь живем, по большей части, в демократических государствах, и, раз большинство считает, что поддерживает, то несколько голосов за правду утонут в общем хоре негодования. Чтобы не прослыть белой вороной, заявляем – наши видеокарты поддерживают DirectX! Однозначно и в полном объеме!

То, что в этом случае видеокарты также должны поддерживать DirectInput, призванный обеспечить работу устройств ввода, таких как клавиатура, мышь, джойстики и другие манипуляторы, уже упомянуто. Все же, для полноты картины, перечислим все компоненты, которые входят в современную версию DirectX:

DirectGraphics

DirectSound

DirectInput

Коротко, логично и понятно. В свое время в разные версии DirectX в разное время включались, убирались и восстанавливались вновь и другие компоненты – DirectDraw, DirectMusic, DirectPlay, DirectShow и еще несколько, но они или уже существуют только для обратной совместимости либо перенесены в другие SDK, и их использование не рекомендуется либо уже попросту невозможно.

Так классифицирует DirectX сама Microsoft. Но я бы добавил сюда и
DirectX Graphics Infrastructure (DXGI) – компоненту инфраструктуры DirectX 10, которая вполне этого заслуживает. Более того, сама Microsoft в других местах ее так и позиционирует. К примеру, при описании отличий DirectX 10 от предыдущих версий читаем, среди прочего:


“Common 2D, focus and adapter-management functionality refactored into a new component: DXGI”,

что в переводе звучит так:


“В новую компоненту DXGI выделены все общие операции в режиме 2D и функциональность, связанная с поддержанием фокуса и управления видеоадаптером”.

Главная цель создания DXGI – управление низкоуровневыми задачами, которые не требуют включения в библиотеку исполнения DirectX – речь идет о более рациональном разделении установочных и исполняемых процедур.

Последняя версия DirectX SDK на момент написания статьи (Август 2007) добавляет еще одну компоненту,

The Windows Vista Game Explorer,

обеспечивающую соответствие новым правилам Microsoft по разработке игр для платформы Windows —
Games for Windows: Technical Requirements, Microsoft Corporation, Version 1.2.0007, August, 2007. В этих правилах, кстати, впервые прозвучало требование обязательной поддержки разрешения 1680х1050 (поддержка более низких разрешений 16:10 требовалась и раньше), а до сих пор это в драйверах Nvidia было лишь опциональным. С текстом этого документа можно ознакомиться на сайте разработчика, есть он и в составе DirectX SDK, начиная с августовской версии 2007 года.

The Windows Vista Game Explorer обеспечивает легкий, настраиваемый способ представить в ОС Windows Vista компьютерную игру. Эта компонента обеспечивает управление доступом, особенностями запуска, локализацию информации об игре и визуализацию ее представления (все игры теперь должны попадать в специальную папку Games, которую наверняка видели все пользователи этой ОС).

Несколько слов о компонентах DirectSound, DirectMusic и DirectInput.

DirectSound и DirectMusic находятся в подвешенном состоянии – обе компоненты получили от Microsoft “черную метку”. Это значит, что они более не развиваются (правда, в интерфейс DirectSound пока еще вносятся незначительные изменения) и при первом удобном случае будут заменены. На что? Это давно уже не секрет. Microsoft в последние годы сильно озаботилась мультиплатформенностью, правда часто вкладывая в это понятие свой смысл, но, тем не менее, такой шаг можно только приветствовать. И на знаменах (логотипах, заставках) DirectX, и в SDK уже давно присутствуют названия, начинающиеся с буквы “Х” — XNA, XACT, X3DAudio, XAudio2, XInput.

Говоря об использовании DirectXInput vs XInput, Microsoft прозрачно намекает (вернее, говорит открытым текстом), чем использование XInput предпочтительнее DirectXInput. Если посмотреть документацию, то выходит, что Xinput легче использовать, инициировать, он имеет единый кроссплатформенный интерфейс под Windows и Xbox 360, контроллеры от Xbox 360 будут вибрировать только через этот API, а иначе – не будут!, и будущие контроллеры под Xbox 360 (например, рули) смогут работать даже под Windows!

Надеюсь, намек все поняли.

В связи с этим удивляет положение Managed DirectX и анонс о прекращении упоминания о нем в следующей, ноябрьской версии DirectX SDK. Похоже, Microsoft хочет добиться, чтобы и наши правнуки играли на приставках Xbox 360, говоря о том, какой это удачный и современный продукт. Я понимаю, что департамент по развитию Xbox360 нанес удар по своей репутации (ведь правда, какая мелочь потерять несколько сотен миллионов для такого гиганта, как Microsoft) и должен как-то реабилитироваться. Ни в коей мере не умаляю достоинств этой приставки (скорее, наоборот, по совокупности потребительских качеств и учитывая возможности разработчика, считаю ее лучшей приставкой), мне просто не нравятся некоторые шаги Microsoft, которая частенько похожа на того медведя в лесу, который, чтобы сорвать всего лишь одну маленькую ягодку, мимоходом задевает и разрушает своей косматой лапой муравейник, вырывает малинник с корнями, даже не интересуясь, почему маленькие обитатели леса (те, кому удалось выжить) так его не любят. Он их даже не замечает. Только этот медведь, сидя на той же опушке через год, удивленно будет чесать свой затылок лапой — почему же там больше не выросло ни одной ягодки?

А на досуге предлагаю наиболее продвинутым пользователям компьютера решить задачу — поддерживает ли их видеокарта DirectSound, если она обеспечивает передачу звука по HDMI.

Что такое шейдер?

Слово «шейдер» очень часто употребляют неправильно, не понимая что это такое и отождествляя его с частью компьютерного оборудования. Но это понятие не относится к категории «hardware».

Что же такое “шейдер”? Это слово пришло в мир бытовых компьютеров из кинематографии, где так именовались специальные программы (“shaders”), участвующие в рендеринге (формировании) итогового изображения на экран (или в память). Поэтому шейдеры – это относительно небольшие программы, написанные на специализированных языках, которые выполняются графическим процессором. Для чего служат эти программы и почему заранее известно, что они небольшие? Современные ГПУ обрабатывают потоковую информацию – большие массивы однородных данных простых типов, которые надо обработать по короткому алгоритму и быстро передать дальше, чем меньше программа – тем быстрее обработка, хотя тенденция к усложнению явно прослеживается. Впрочем, большими эти программы (по крайней мере по отдельности) еще долго нельзя будет называть, а размер первых шейдеров вообще очень сильно ограничивался возможностями видеокарт (это определялось наличием в ГПУ регистров для хранения обрабатываемых данных и установленным ограничением на число выполняемых инструкций).

А зачем им нужен специализированный язык? ГПУ имеет многочисленные внутренние специализированные потоковые процессоры с ограниченной функциональностью и упрощенной системой команд. Для потоковой обработки этого вполне достаточно. Это – компромисс между функциональностью, стоимостью и быстродействием, оптимальный на сегодня.

Но даже для небольшой игры может потребоваться написание большого числа шейдеров. Шейдеры группируются в логически связанные блоки, именуемые эффектами (“effects”). Дополнительную информацию по этому вопросу можно получить из документации к DirectX SDK.

Зачем нужны шейдеры? Конвейер и шейдерная модель

Было время, когда о шейдерах никто и не думал. Хорошее было время! Откуда же они свалились на нашу голову? Для того, чтобы понять это, надо знать, как работает современная видеокарта и графический процессор и как это было в то далекое время, когда дети, увидев морскую волну, не кричали радостно “Шейдеры! Шейдеры!”. Поэтому будет уместно сделать маленькое лирическое отступление от непосредственной темы DirectX и разобраться в этом. Я постарался максимально упростить технические детали, насколько это мне удалось – судить вам.

Попробуем упрощенно описать, как функционирует видеокарта. Тут удобно применить технологию “черного ящика”, широко используемую в автоматике. У ящика есть вход и выход, внутренняя функциональность нас интересует весьма приблизительно, причем не интересует, как это происходит на самом деле, а важно лишь то, как это видится снаружи “черного ящика”. Этим черным ящиком и будет выступать видеокарта. Мы должны узнать, что подается на вход, что является выходом и в общих чертах понять, что происходит внутри этого “черного ящика”.

Что является выходом, большинству сразу понятно – к видеокарте подключается монитор и то, что мы на нем видим, и есть выход. Пока будем считать, что так оно и есть, хотя это является истиной далеко не всегда – карта может работать ведомой в SLI или CF без монитора, видеокарта может производить неграфические вычисления и также не подключаться к монитору, выполняя полезную работу как сопроцессор к ЦПУ, либо часть процессорного времени ГПУ может отдаваться задачам, не связанным непосредственно с графикой.

Так что же подается на вход видеокарты? Смотря что видно сейчас на мониторе, если, конечно, видеокарта у нас работает как видеокарта, а не считает, к примеру физику или химию
.

Допустим, программа должна выводить на экран трехмерный куб.

Как вообще можно описать куб математически? Способов существует много, но если речь идет о DirectX, то трехмерный объект представляется набором треугольников. Чтобы получился квадрат, нужно два треугольника а на шесть граней куба нужно уже 12 треугольников. Каждый треугольник имеет 3 вершины, поэтому всего нужно будет определить 36 вершин. Каждая вершина может быть представлена в виде трех чисел – ее координат в трехмерном пространстве. Область памяти, где хранится информация о вершинах объекта, называется вершинным буфером, или буфером вершин. Кому-то может показаться, что можно бы уложиться и в восемь вершин, и он будет не далек от истины, так как в действительности выборка может происходит по данным дополнительного индексного буфера, содержащего только индексы, привязанные к буферу вершин, а вершинный буфер может состоять только из уникальных координат, но эти нюансы мы здесь не рассматриваем. Координаты всех 36 вершин, одна за одной, непрерывным потоком, каждый кадр, поступают в видеокарту. Как правило, вершины имеют более сложный формат (хотя это и не обязательно), например, используются текстурные координаты для правильного наложения текстуры, вектор нормали, цвет и другие данные, но это выходит за рамки темы данной статьи.

Конечно, поток из 36 чисел за кадр – не нагрузка даже для самого древнего графического процессора, но более сложные объекты – игровые персонажи, окружающие предметы, природа могут содержать миллионы треугольников, и такой поток данных один или два потоковых процессора, имевшихся в наличии у старых видеокарт, уже не смогут обработать без катастрофического падения производительности. Поэтому число потоковых процессоров у видеоадаптеров, поддерживающих DirectX 9, измеряется десятками, а у нынешних топовых карт под DirectX 10 – сотнями. Без сомнения, скоро счет перейдет на тысячи, даже без учета объединения нескольких ГПУ на кристалле, плате видеокарты и в целом на материнской плате (а о кластерах даже думать не будем).

Таким образом, данные о вершинах хранятся в памяти, в буфере вершин, и периодически поступают на обработку в видеокарту. Что происходит с ними дальше – зависит от того, какую версию DirectX поддерживает видеокарта и какую версию DirectX поддерживает программа. Грамотное DirectX приложение при старте проверяет, удовлетворяют ли возможности видеокарты требованиям программы, и только при положительном ответе (после опроса системных данных) разрешает работу.

Итак, пока мы определились, что в видеокарту постоянно будет поступать информация из буфера вершин.

Теперь самое время обсудить, что такое “графический конвейер”. Тут – почти полная аналогия с заводским конвейером. От входа до выхода бежит лента транспортера, на которую поступают входные детали. И пока они на этой ленте направляются к концу конвейера, все, кто работает за конвейером, в соответствии с порученными технологическими операциями, производят соответствующие манипуляции, кто-то что-то привинчивает, или наоборот, отвинчивает, и в итоге начальную деталь вообще не узнать, ибо, как принято говорить, с конвейера уже сходит готовый продукт.

Представьте, что конвейер стал автоматизированным. Все операции выполняются роботами – станками и манипуляторами. Роботы запрограммированы раз и навсегда на выполнение конкретной операции в технологической цепочке. Если на транспортер конвейера ставили более мощный двигатель или рядом ставили еще один конвейер, оказывалось, что старые роботы уже сдерживают увеличение пропускной способности конвейера, независимо от числа линий. Поэтому в таких случаях каждый раз приходится менять роботов на более современных. Опять же, замена требовалась, если хотя бы чуть-чуть менялась технология обработки деталей.

Со временем инженеры так доработали роботов, что теперь стало возможно автоматически, во время работы, оперативно изменять их программу, в зависимости от того, какие детали находятся на конвейере и какие операции требуется выполнять. Кроме того, за процессом работы линий конвейеров стал наблюдать диспетчер, который следит за тем, правильно ли распределена загрузка входными деталями в соответствии с текущей производительностью роботов. Диспетчер сразу исправляет ситуацию так, чтобы не было ни простоев, ни завалов. Поэтому производительность труда на современных конвейерах многократно выросла.

Это несколько утрированное описание вполне можно отнести к конвейерам графических процессоров. Линии конвейера будут соответствовать потоковым процессорам, диспетчер – управляющее устройство ГПУ, программирование роботов — это выполнение программ-шейдеров, а если роботам добавить машинное зрение, обеспечить возможность выполнение любых технологических операций, используемых на производстве, поставить несколько дополнительный линий, возвращающих уже обработанные детали снова на вход конвейера (или отправляющих вообще на отдельный выход для обработки в соседнем цехе), то будет почти полная аналогия с универсальной шейдерной архитектурой.

Вернемся к вопросу, а что происходит дальше с данными вершин (в нашем примере – с координатами) в видеокарте? Как их связать с экраном монитора? Потихоньку мы доберемся и до монитора, но сейчас отметим, что то, как выглядит наш куб на мониторе, определяется не только координатами вершин треугольников, из которых складывается куб, но также и положением и ориентацией в пространстве наблюдателя (камеры), и параметрами самой камеры (угол поля зрения, формат кадра и т.д.). Поэтому должна быть возможность измерять координаты и угловую ориентацию объектов относительно общей точки отсчета, что даст возможность пересчитать положение и ориентацию любых трехмерных объектов относительно друг друга. Эти операции не очень сложные, но тем не менее требуют знания высшей математики, хотя при программировании таких задач можно полностью полагаться на известные приемы и алгоритмы, без необходимости изучения матричного исчисления (в профессиональных разработках обычно используется математика кватернионов, но, для простоты, в большинстве примеров программирования в DirectGraphics рассматриваются именно матричные операции).

Поскольку положение (то есть координаты) и ориентация (то есть углы поворота) наблюдателя (камеры) и технические параметры камеры определяют, что мы видим на мониторе, стоит задача – трансформировать 3D координаты вершин куба в 2D экранные координаты.

Для этого уже давно придумали формулы пересчета, и перевод из одной системы координат в другую это – умножение на мировую матрицу (определяющую положение в глобальной системе координат), матрицу вида (положение и ориентация наблюдателя) и матрицу проекции (с параметрами камеры).

Во времена, когда только появились первые специализированные графические процессоры, эту трансформацию координат выполнял процессор. Поскольку таких операций нужно делать много, то умножение матриц (обычно это можно оптимизировать до умножения вектора на матрицу) совокупно представляет собой весьма недешевую операцию и сильно загружает процессор. А поскольку это — операция рутинная и однородная, выполняющаяся над всеми вершинами всех объектов трехмерной сцены, то решено было разгрузить ЦПУ, переведя эти вычисления в ГПУ, на специализированный потоковый процессор, автоматически выполняющий такой пересчет.

Вот по такой логике и стали работать первые ГПУ с аппаратным блоком трансформации и освещения “T&L” (Transform And Lighting) — NVidia GeForce256. Чтобы не загромождать материал статьи, я не буду вдаваться в детали расчета освещения и отсылаю заинтересованных читателей к
http://www.nvidia.com/object/transform_lighting.html

Отныне (но не навсегда!) аппаратная поддержка “T&L” стала символом высокой производительности видеокарт, это давало серьезную прибавку быстродействия программам и было поддержано всеми игроделами – вскоре все 3D игры для запуска стали требовать графического процессора с поддержкой “T&L”. И все бы было хорошо, но прогресс не стоит на месте. Поскольку логика трансформации “T&L” была жестко “зашита”в ГПУ (отсюда и произошло название – фиксированный конвейер), она сильно ограничивала и выравнивала выразительные возможности создаваемых программ, кроме того, жестко реализованная модель освещения во многих случаях была слишком примитивной для реализации красочных или реалистичных эффектов. Да и Microsoft добавляла что-то новенькое в DirectX только каждые год – полтора. Техника мультитекстурирования, некоторое время решавшая проблему и широко использовавшаяся в дошейдерную эпоху для придания “красивостей” игровым объектам, уперлась в пропускную способность видеопамяти – требовалось многократное чтение из текстурной памяти и многократное чтение-запись в буфер кадра. Было очевидно, что долго так продолжаться не сможет. И было предложено революционное решение, предопределившее стратегическое направление развитие графических процессоров на долгие годы — замена фиксированного конвейера на программируемый – вместо блока “T&L” появился блок потоковых процессоров, выполняющих обработку потока данных из вершинного буфера по программе вершинного шейдера. Блок мультитекстурирования сменил блок потоковых процессоров, выполняющих обработку потока данных (уже обработанных вершинным шейдером и прошедшими операции удаления невидимых и неотображаемых поверхностей), по программе пиксельного шейдера.

С выходом DirectX 8, определившим спецификацию новой технологии, появилась возможность относительно легко реализовывать любые модели освещения, произвольные трансформации и попиксельную обработку изображения (намного более гибкую и совершенную, чем появившуюся еще в DirectX 6 технику DOT3 с картами нормалей).

Новая эпоха шейдерного графического программирования принесла не только улучшение качества графики, но и головную боль программистам и покупателям видеокарт.

Программисты пострадали из-за того, что новый путь развития графического программирования был новаторским, зачастую методом проб и ошибок, что приводило к постоянным изменениям спецификации от Microsoft в DirectXGraphics и тем возможностям, которые предоставлял API и, следовательно, к появлению новых и новых видеокарт, каждая из которых требовала изменений в коде шейдера. При этом производители видеокарт не утруждали себя 100% воплощением возможностей API в железе, что не мешало им заявлять о полной поддержке DirectX. Особенно ярко это проявилось в DirectX 9 — появились версии 9a, 9b, 9c и различные варианты поддержки программирования шейдеров, что привело к понятию “шейдерная модель” (Shader Model, SM). Поддержка шейдерной модели означала поддержку в АPI специфических команд языка, на котором пишется шейдер, и наличие соответствующих регистров и возможностей обработки данных в видеокартах. Технические различия интересны только программистам, но пользователи стали теряться среди DirectX карт, поддерживающих SM1.0, 1.1,1.3,1.4, 2.0,2.0a, 2.0b…. Плюс непонятные простым смертным аббревиатуры PS или VS рядом с этими цифрами.

Дело дошло до того, что шейдерные модели стали делиться на “для ATI” и “для Nvidia”.

Следующая шейдерная модель SM 3.0 положения со следованием стандарту не улучшила — например, ATI не стала подерживать карты смещения в вершинном шейдере, мотивируя это тем, что у Nvidia эта технология работает медленно и требует несколько десятков миллионов транзисторов на кристалле дополнительно. Вместо этого ATI предложила свой вариант рендеринга в буфер вершин, что опять потребовало от программистов создания еще нескольких программных заготовок.

Мало того, что программист должен был учитывать множество спецификаций, он должен был еще программировать физический опрос возможностей карты (так называемых capable bits) независимо от заявленной поддержки производителем карты на красочной суперобложке, чтобы убедиться, какую же программу подсунуть именно этой карте.

Посочувствовав друг другу, давайте доведем поток данных по конвейеру до монитора.

После обработки по программе вершинного шейдера, происходит удаление всего того, чего не видит камера – зачем обрабатывать то, что никто не увидит? Но ничего не увидеть можно и по простой причине, если интересующий наш объект не попал в поле зрения камеры. Но если ракурс удачный, расстояние до нашего куба подобрано адекватно его размеру и камера правильно настроена, мы увидим наш куб во всей красе.

А как обеспечивается то, что в полноэкранном режиме куб будет выглядеть примерно одинаково на мониторе и при разрешении 640х480, и при 1024х768? Да очень просто. Растеризатор (блок ГПУ, который и отвечает за перевод 3Д картинки в 2Д), работает с внутренним представлением буфера, независимо от размера, имеющим диапазон по сторонам измерения -1.0..+1.0. Поэтому пересчет в абсолютные экранные пикселы, так, чтобы левый верхний угол выводимого изображения имел координаты (0,0), а правый нижний (639,479) или (1023,767) – это задача по арифметике для первого класса начальной школы.

Конечно, на самом деле растеризация – очень сложный и многоступенчатый процесс, и то, что обычно называют растеризацией, вовсе таковой не является по большому счету, но это вы можете проверить сами, прочитав соответствующие материалы, а начать, естественно, рекомендую с того же первоисточника – документации DirectX SDK, сайта Microsoft и есть масса монографий с такими математическими выкладками, которые вызывают стойкое и долговременное отвращение к любым математическим формулам.

На этом месте статьи я остановился, никак не получалось решить – стоит ли описывать текстурирование, что повлечет необходимость более детального описания пиксельного шейдера, блендинга и фильтраций. Честно говоря, статья и так отняла много времени, поэтому после некоторых колебаний, я решил пропустить эти моменты, так как изначально все-таки стояла цель вводного ознакомления с DirectX, написанного простым языком. И, к тому же, есть масса доступных источников в интернете. Но, если появятся вопросы, – я постараюсь на них ответить.

Все вышеизложенное, для более сложной программы, требует сотен и тысяч строк кода (если, конечно, не пользоваться специальными фреймворками или высокоуровневым программированием), и приводится в движение волшебной командой Draw — Рисовать (как правило, их несколько на каждый кадр), которая используя многочисленные условия и договоренности, производит рендеринг (отрисовку) сцены в буфер кадра (ну или в какую — нибудь другую поверхность рендеринга, что в обоих случаях представляет собой выделенный участок видеопамяти).

В случае, если это – буфер кадра, нужно иметь в виду следующее. Как минимум, в DirectX для конкретной программы таких буферов будет два. Зачем? Потому что в процессе рисования объекты выбираются последовательно и новый объект может затирать информацию о предыдущем, если, к примеру, он его загораживает от камеры. Такая смена объектов, конечно, не заметна на глаз в деталях, но вот определенное мелькание и неприятные кратковременные “помехи” будут заметны. Поэтому, для того, чтобы от этого избавиться, применяется так называемая двойная буферизация. Создается два идентичных буфера кадра. Как только выполнены все команды Draw, по команде Present (Показать) происходит быстрое переключение адреса буфера, в котором формировалось изображение. Буфер, в который отрисовка закончилась, становится FrontBuffer (Передний Буфер) – областью памяти, которая уже формирует глобальный буфер кадра, который уже и поступает на монитор (если программа работает в полноэкранном режиме, то кадровый буфер программы и представляет собой глобальный буфер кадра). А буфер, который до этого был FrontBuffer, становится BackBuffer (Задний буфер) и в нем будет формироваться следующий кадр. Таким образом, рендеринг происходит все время в BackBuffer, а на монитор всегда идет изображение с FrontBuffer. Частота, с которой переключаются буферы кадра, определяет то число кадров в секунду, по которому судят об “играбельности” компьютерной игры и оно характеризует производительность графической подсистемы компьютера в данный фрейм. А если точнее, то в предшествующий. Но если уж совсем быть точным – то за некоторый период, зависящей от текущей 3D сцены, от объема видеопамяти и еще некоторых факторов. И в итоге это означает что это число характеризует совокупные аппаратные возможности компьютера при выполнении конкретной программы в конкретной операционной среде
.

Может возникнуть вопрос, если на видеокарте, поддерживающей DirectX 9, запускается старая программа, написанная без шейдеров и требующая наличия блока “T&L”, как она выполняется, ведь современные карты уже не содержат аппаратного “T&L”? Очень просто. Драйвер видеокарты различает такую ситуацию и имеет для этих целей простейшие шейдеры с обработкой в стиле а-ля “T&L”, что обеспечивает полную совместимость со старыми приложениями.

Что дает пользователю компьютера очередная версия DirectX?

Теперь, когда мы знаем, что такое DirectX, попробуем разобраться, с точки зрения пользователя-непрограммиста, а что нам дает каждая новая версия DirectX?

Ответ однозначен – НИЧЕГО! DirectX – это одновременно и инструмент и потенциал, который надо раскрыть. Это должны сделать и разработчики программы (программисты, администраторы, художники, музыканты, дизайнеры) и программисты – драйверописатели.

Чтобы раскрыть такой потенциал, нужно немало усилий по изучению нового API и возможностей видеокарт, написанию и отладке кода и его оптимизации, постоянное отслеживание производительности десятков типов видеокарт под последними драйверами, часто вносящими хаос в уже отлаженный под предыдущий драйвер код, нужно умение и способность выкроить чуть – чуть ресурсов для создания нового эффекта, под который их нехватило в предыдущей версии движка под предыдущую версию API… иначе зачем новый API, если все-будет выглядеть по старому? И стоит только выкроить полмиллисекунды на кадр, ее тут же забирают под дополнительные полигоны в сцене, и начинается все сначала…. Проходит время….. Уже анонсирована следующая версия DirectX….

Это была история о программистах из деревни Виллабаджо.

А в это время в деревне Виллариба программисты под OpenGL радуются и веселятся – смена поколения видеокарт не принесла им никах проблем со сменой API, только лишь возросло быстродействие! И они только что сделали классную новую игру! И не хуже последней игры, выпущенной в деревне Виллабаджо под DirectX!

Конечно, два предыдущих абзаца – шутка. Но в ней очень много правды.

Отметим, что арт-команда готова полностью загрузить следующие несколько поколений видеокарт уже сегодня. Но сегодняшные топовые карты это не осилят.

Можно поставить вопрос и по-другому, а чего не хватало программистам или в целом команде разработчиков в предыдущих версиях DirectX? Что же такого особенного дают новые версии, кроме беспокойства владельцу недавно купленной видеокарты?

Попробуем выяснить и это.

DirectX 10. Эволюционное обобщение пройденного

У Microsoft было достаточно времени – несколько лет, чтобы провести всесторонний тест выбранного направления развития графических API. И в самый расцвет DirectX 9 стало ясно, что продолжения не будет. В недрах подразделений R&D Microsoft рождалась новая операционная система. Первоначальные перемены названия преемника DirectX и кулуарные высказывания показывали, что DirectX 9 — это если не последний вариант DirectX вообще, то, по крайней мере, последний под Windows XP. Как оказалось, Microsoft все же не стала отказываться от брэнда DirectX и в новой Windows Vista увидела свет DirectX 10.

Конечно, смена поколения ОС – очень удобный повод железной рукой установить более жесткий порядок в плане следования выработанной спецификации (и тут мы всецело на стороне Microsoft). В этот период можно легко убрать те моменты, которые не устраивали, добавить то, чего не хватало и заложить резерв под будушие нужды. Но Microsoft поступила более радикально, бросив на XP тень полной бесперспективности, видимо с целью несколько ускорить естественный процесс отмирания прежних версий ОС. Ведь как бы ни уверяла Microsoft в том, что поддержка DirectX 10 настолько тесно интегрирована с ядром новой ОС, что никакая полноценная поддержка в Windows XP невозможна, очевидно, что изначально, помимо чисто технических целей улучшения (полного обновления) DirectX ставилась и цель, по чисто маркетинговым соображениям (чтобы поднять продажи ОС Vista), — получить техническую аргументацию в обосновании такой невозможности. На мой взгляд, виртуализация видеопамяти, переключение задач на ГПУ и унификация доступа к ресурсам, как наиболее влияющие на несовместимость факторы, и возникающие в связи с этим проблемы, вполне могли быть решены и в предыдущей версии ОС, если бы такая задача стояла (или, в худшем случае, была бы немного ограничена функциональность DirectX 10). По приведенной выше причине она, естественно, и не ставилась. Впрочем, это мое личное мнение, и оно может не совпадать с реальными намерениями Microsoft, но я не нашел доказательств обратному.

Гордо заявлено, что все написано с нуля. Хотелось бы спросить, а что, предыдущий опыт был отброшен? Наняты совершенно другие люди? Заведена дружба с разработчиками открытого графического ПО?

Нет, конечно. Первые описания и примеры работы с графической частью DirectX — Direct3D 10 появились публично еще в декабре 2005 года. Команда разработчиков кардинально не менялась. Более того, была сделана попытка ограничить полноценную поддержку OpenGL. Многие, кто был связан с этой темой, помнят размещенное в прошлом году объявление на первой странице официального сайта www.opengl.org , которое долгое время призывало всех оказать давление на Microsoft с целью недопустить дискредитацию OpenGL. Впрочем, эти нападки не новые, можно вспомнить и открытые письма грандов мировой игровой индустрии, направленные Microsoft (по аналогичному поводу!) и в 1997 году
http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html .

Вообще, надо отметить, что Microsoft получает массу открытых писем ежегодно по всяческим поводам и без повода, так что ей не привыкать.

Впрочем, хватит лирики, раз приказано жить по новому, то вариантов у нас немного — значит, будем жить. Что же нового принес нам DirectX10 (и Vista) ?

Здесь уже не обойтись без упоминания некоторых технических деталей, и я коротко перечислю существенные моменты, понимание которых не требует знания DirectX.

Внедрена новая модель драйвера Windows Vista Display Driver Model (WDDM). Чем стала плоха старая модель WDM, использовавшаяся в прежних версиях Windows, можно узнать по ссылке:


http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx

а вот все о новой модели WDDM:


http://msdn2.microsoft.com/en-us/library/ms797619.aspx

Краткий комментарий.

Произошла полная виртуализация графической памяти. Набирающая силу тенденция виртуализации всего и вся наконец-то добралась и до видеоподсистемы компьютера в полную силу. Чем же она так хороша? Да многим, и с точки зрения безопасности, и с точки зрения размера адресного пространства. Теперь каждому окну приложения выделяется собственная виртуальная память в размере полного экрана, собственный рендеринг (впрочем, WDM – Windows Display Manager трогать не будем). Разрешение экрана 1280х1024 потребует более 5Мб видеопамяти. 10 открытых приложений займет под 60 Мб. Без виртуализации, особенно на карте со 128Мб это называется приехали. Так что очень полезная штука.

Появилась возможность переключения задач на ГПУ. Теперь есть возможность прервать выполнение основной графической задачи и быстро выполнить в фоне, к примеру, расчет какого-нибудь физического взаимодействия объектов. Причем предоставляется возможность и прерывания выполнения работы над примитивом или посреди выполнения шейдера, если это поддерживается видеокартой (так как это не является требованием DirectX 10).

WDDM разрешает совместное использование поверхностей DirectX между процессами, тоже очень неплохо, что появилась официальная поддержка.

По модели драйвера вроде все, что относится к драйверописателям, не трогаем.

Теперь вернемся к DirectX 10. Начнем с того, что у всех на слуху.

Введена унифицированная шейдерная архитектура. Все шейдерные блоки теперь равнозначны и они выполняют задачи в соответствии с текущей стадией конвейера. В видеокартах предыдущего поколения это тоже было ограничено возможно, но приходилось сильно извращаться.

Если теперь производитель карты заверяет, что его видеокарта поддерживает DirectX 10, то этому уже, наверное, можно поверить. По новой спецификации, такая поддержка означает полное соответсвие API – все, что запрограммировано правильно, должно выполняться на любом DirectX 10 железе. Другое дело, что карты все равно разные и обеспечивают разные возможности. К примеру, Радеоны включили аппаратную тесселяцию, что скоро станет требованием DirectX, а видеокарты Nvidia 86хх имеют несколько аппаратных отличий, выгодно отличающих их (конечно, временно, до выхода нового поколения карт) от топовых решений 88хх (к примеру, это позволяет им обращаться к атомам в технологии CUDA, чего лишены их более старшие собратья, есть и другие преимущества. Впрочем, это вряд ли компенсирует владельцам этих карт банальный разрыв в быстродействии).

Появилась новая стадия в конвейере – стадия исполнения геометрического шейдера. Что можно интересного запрограммировать в коде геометрического шейдера? Как и вершинный шейдер, он на входе получает вершины и вершины же выдает на выход, но появляются существенные отличия. Входными данными уже являются не обезличенные вершины в потоке, а вершины примитивов, то есть вершины треугольника, линии или точки, а также соответствующие примыкающие вершины (три на треугольник и две на линию). В выходном потоке стадия геометрического шейдера может генерировать дополнительные вершины, образующие коллекцию вершин (point list), ломаную линию (line strip), либо группу связанных треугольников (tristrip).

Выходной поток вершин стадии геометрического шейдера может быть направлен, как входной поток, на стадию растеризации, либо в буфер памяти, и тогда он снова может являться входным источником вершин для стадии исполнения вершинного шейдера.

Безусловно, операция крайне процессороемкая (имея в виду ГПУ) в плане создания на лету высокополигональной геометрии (особенно, если делать ее за один присест).

Примеры работы геометрического шейдера владельцы видеокарт последних серий могут посмотреть, скачав свежие SDK на сайтах производителей своих видеокарт.

Шейдерная модель получила номер 4.0.

Программный язык написания шейдеров – только НLSL (хотя по-прежнему можно подключать внешний байт-код).

Произошла унификация подхода к используемым ресурсам – все ресурсы могут быть деривативами только от текстуры или буфера памяти.

Остальные отличия и нововедения, да, впрочем, как и большинство уже перечисленных, интересны только для программистов, которые эти новшества и так знают, всех интересующихся я отсылаю к документации по DirectX 10 SDK. Не думаю, что всем пользователям будут интересны сведения, звучащие как “в отличие от DirectX 9, теперь текстурные сэмплеры не ассоциированы с конкретной текстурой, а описывают применяемый к ресурсу метод фильтрации” или “DirectX 10 позволяет сократить ресурсоемкие операции смены состояния объекта Direct3D10, путем введения объектов состояния. Это особенно важно для организации обеспечения валидации объектов при их создании (а не при каждом использовании). Объекты состояния можно кэшировать в видеопамяти и в API — вызовах использовать хэндл на объект”.

Соответствуют ли изменения от DirectX 9 к DirectX 10 революционному обновлению? Мое скромное мнение – нет, это большой шаг вперед, но по значимости он не дотягивает до действительно революционного скачка от DirectX 7 к DirectX 8. Тем более очень интересная особенность – динамическая смена задач на ГПУ – не относится к DirectX.

Что мы, как обычные пользователи, вправе ожидать от технологии DirectX, присутствующей на рынке 8 месяцев плюс год открытого предварительного тестирования?

Увы. Мое мнение такое. Самые новые игры под DirectX 9 напрягали соответствующие топовые видеокарты под завязку. Новые возможности API, теоретически давая очень интересный инструмент в руки разработчика, не позволят реализовать его полный потенциал на существующих топовых DirectX видеокартах (имеется в виду Nvidia 8800 и AMD 2900) так, чтобы это было играбельно.

То, что анонсируемые на этот год премьеры будут ориентированы на эти топы, понятно, но уровеь всеобщего ожидания и интерес к этим играм такой, что плохо быть сделанными они не имеют права. Значит, их будут делать хорошо, чтобы разница в передаче игровой атмосферы под DirectX 10 была бы заметна. При этом, чтобы обеспечить приемлимый фпс, наверняка частью красот придется пожертвовать. Миддл сектор в лице 8600 и 2600 отдыхает.

Что касается профессиональных применений, то они тоже более ориентированы на архитектуры будущих видеокарт. Нынешие топы прокладывают эту дорогу, и, по большому счету, не так уж они и плохи. Но быстротечен век любого компьютерного оборудования — и тут уж ничего не поделать.

Но есть и хорошие моменты.

Во-первых, это только мое личное мнение, и я очень хочу, чтобы оно оказалось ошибочным (у меня самого пара 8600GT).

Во-вторых, наверняка будет много игр, не выжимающих все из железа, но реализующих какие-нибудь интересные возможности DirectX 10.

В третьих, скоро подоспеет новый топ от Nvidia. Но я не говорил, что это хорошая новость для всех.

DirectX 10.1 Как же теперь жить? И пара слов об OGL

Вы можете спросить, а что появляется вперед – API или новое оборудование? Конечно, API определяет будущую архитектуру и первым появляется на рынке, но этот процесс итерационный и происходит путем консультаций специальной группы ведущих вендоров, безусловно с участием AMD и NVidia, с главенствующей ролью Microsoft, ибо решающее слово – за ней. С момента официального появления DirectX10 прошло уже достаточно времени для подготовки и анонса очередного изменения. И этот анонс Microsoft сделала на SIGGRAPH — DirectX 10.1 появится в Windows Vista SP1. Это получило широкий резонанс и обсуждение (люди, не разбирающиеся в этой технологии просто подняли панику, интерпретировав информацию таким образом, будто бы видеокарты только c поддержкой DirectX 10.0 уже ни на что не годны), а сделанное за четыре дня до этого заявление о релизе OpenGL 3.0, окончательный стандарт которго будет принят в конце сентября 2007 года, осталось практически незамеченным. С другой стороны, нельзя не отметить, что разработчики OpenGL всегда более взвешенно подходят к своим пользователям и более лояльно относятся к имеющемуся у них оборудованию.

Кстати, еще пара слов о конкурирующем стандарте графического API – OpenGL. Его глобальное обновление, с точки зрения временных рамок, вторично по отношению к DirectX, так как он уже ориентируется на те аппаратные изменения, которые производители делают для соответствия спецификации DirectX. Поскольку аппаратное обеспечение и при OpenGL и DirectX одинаково, принципиально эти технологии примерно равноценны, если говорить о потенциальном качестве картинки, а различия проявляются на уровне самого API, открытости кода, мультиплатформенности, способе принятия расширений стандарта и еще нескольких менее важных для конечного пользователя моментов.

Но вернемся к DirectX 10.1. Абсолютно ничего страшного не произошло, всего лишь мелкое эволюционное изменение, вполне соответствующее тем временным рамкам, которые были приняты между предыдущими обновлениями версий DirectX. Поскольку изменений не так много, я решил привести их все (хоть это и сугубо технические моменты), чтобы вы также смогли оценить размеры “катастрофы”.

Перевожу с английского, документация DirectX SDK за август 2007 года:

Direct3D 10.1 добавляет 3 новых API интерфейса. Они добавлены в Direct3D.1 DLL (D3D10_1.DLL и D3D10Core.dll), и будут доступны в Windows Vista Service Pack 1, а именно:

две новые функции D3D10CreateDevice1 и D3D10CreateDeviceAndSwapChain1 для создания интерфейса ID3D10Device1, который получил новые методы для создания интерфейса блендинга ID3D10BlendState1, поддерживающего независимые моды блендинга для каждой поверхности рендеринга и для создания интерфейса ID3D10ShaderResourceView1 c подержкой новых массивов кубических текстур (см. D3D10_TEXCUBE_ARRAY_SRV1).

Это все.

Соответственно, появляется SM 4.1 для поддержки дополнительного метода работы с субресурсами и массивами кубических текстур.

Правда, к выходу Windows Vista Service Pack 1 список изменений может быть дополнен. Думается, что если бы Microsoft знала, какую волну подымет анонс и какой это найдет резонанс в среде технических дилетантов, она бы анонсировала его только вместе с выходом Windows Vista Service Pack 1, тем более, что всем кто следит за DirectX, о выходе версии DirectX 10.1 было известно давным-давно. Ни один разработчик не будет поддерживать DirectX 10.1 эксклюзивно, и если хочется поддерживать оба варианта, то никаких усилий для этого прикладывать не надо.

При написании статьи ни один сайт или любой другой информационный ресурс не пострадал от копипэйста или плагиата, за исключением нескольких строк, любезно предоставленных для цитирования компанией Microsoft.


Все написанное автором выражает только его личную точку зрения, которая может не соотвествовать объективной реальности. Свою точку зрения (по любому вопросу) автор с радостью и благодарностью изменит, если найдет ваши аргументы убедительными. Эти аргументы, критику, предложения и любые мысли вслух, имеющие какое-нибудь отношение к рассматриваемым вопросам, можно изложить
здесь

zauropod 19.08.2007