As nvidia doesn’t have Direct3D 10.1 compatible hardware yet it isn’t a surprise that PerfHUD doesn’t support this updated Version. This includes the case were the Direct3D 10.1 runtime is only used to create a 10.1 techlevel device. Therefore it is necessary to create Direct3D 10.0 devices with the Direct3D 10.0 runtime if you still want to use PerfHUD. This might not a big deal anyway as the same code is required if the application should run on Vista without installed Service Pack.

But there is another problem. If you use DXGI to enumerate over the adapters and pass them to D3D10CreateDevice1 to check if Direct3D 10.1 is supported you risk an access violation.

IDXGIAdapter* pAdapter;

int AdapterID = 0;

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      D3D10_DRIVER_TYPE driverType = D3D10_DRIVER_TYPE_HARDWARE;

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

        driverType = D3D10_DRIVER_TYPE_REFERENCE;

      ID3D10Device1* pDevice1 = NULL;

      //Expect this to crash if run with PerfHUD

      if (D3D10CreateDevice1 (pAdapter,

driverType,

NULL,

0,

D3D10_FEATURE_LEVEL_10_1,

D3D10_1_SDK_VERSION,

&pDevice1) == S_OK)

      {

            pDevice1->Release ();

            OnAdapterSupportD3D10_1 (pAdapter);

      }

      ID3D10Device* pDevice = NULL;

      if (D3D10CreateDevice  (pAdapter,

driverType,

NULL,

0,

D3D10_SDK_VERSION,

&pDevice) == S_OK)

      {

            pDevice->Release ();

            OnAdapterSupportD3D10 (pAdapter);

      }

AdapterID++;

}

As PerfHUD hook Direct3D 10 and DXGI the returned adapter interfaces differs from that one that an unhooked DXGI returns. The Direct3D 10.1 runtime assumes that the adapter interfaces are unmodified and therefore doesn’t check them very well.

An attempt to work around this limitation would be to ignore the PerfHUD adapter when it comes to the Dirtect3D 10.1 test creation.

IDXGIAdapter* pAdapter;

int AdapterID = 0;

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      D3D10_DRIVER_TYPE driverType = D3D10_DRIVER_TYPE_HARDWARE;

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

      {

        driverType = D3D10_DRIVER_TYPE_REFERENCE;

      }

      else

      {

            ID3D10Device1* pDevice1 = NULL;

            if (D3D10CreateDevice1 (pAdapter,

                                   driverType,

                                   NULL,

                                   0,

                                   D3D10_FEATURE_LEVEL_10_1,

                                   D3D10_1_SDK_VERSION,

                                   &pDevice1) == S_OK)

            {

                  pDevice1->Release ();

                  OnAdapterSupportD3D10_1 (pAdapter);

            }

      }

      ID3D10Device* pDevice = NULL;

      if (D3D10CreateDevice  (pAdapter,

driverType,

NULL,

0,

D3D10_SDK_VERSION,

&pDevice) == S_OK)

      {

            pDevice->Release ();

            OnAdapterSupportD3D10 (pAdapter);

      }

      AdapterID++;

}

But this would still crash at the same place. The reason for this is that PerfHUD modifies all adapter interfaces and not only add an additional one. This lead to a working solution

// Test all adapter once to look for PerfHUD

bool PerfHUD = false;

int AdapterID = 0;

IDXGIAdapter* pAdapter;

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

        PerfHUD = true;

      pAdapter->Release();

      AdapterID++;

}

while (m_pFactory->EnumAdapters (AdapterID, &pAdapter) == S_OK)

{

      D3D10_DRIVER_TYPE driverType = D3D10_DRIVER_TYPE_HARDWARE;

      DXGI_ADAPTER_DESC Desc;

      if (pAdapter->GetDesc (&Desc) == S_OK &&

         (wcscmp(Desc.Description, L"NVIDIA PerfHUD") == 0))

      {

            driverType = D3D10_DRIVER_TYPE_REFERENCE;

      }

      If (!PerfHUD)

{

            ID3D10Device1* pDevice1 = NULL;

            if (D3D10CreateDevice1 (pAdapter,

                                   driverType,

                                   NULL,

                                   0,

                                   D3D10_FEATURE_LEVEL_10_1,

                                   D3D10_1_SDK_VERSION,

                                   &pDevice1) == S_OK)

            {

                  pDevice1->Release ();

                  OnAdapterSupportD3D10_1 (pAdapter);

            }

      }

      ID3D10Device* pDevice = NULL;

      if (D3D10CreateDevice  (pAdapter,

driverType,

NULL,

0,

D3D10_SDK_VERSION,

&pDevice) == S_OK)

      {

            pDevice->Release ();

            OnAdapterSupportD3D10 (pAdapter);

      }

      AdapterID++;

}

Finnaly don’t forget to remove all PerfHUD code in your release version if you don’t want that others can run your application with PerfHUD.

And sometimes it goes really fast. Unfortunately I could not finish any of my part time projects last year. But it seems that other people have trouble with their projects, too. While the release date for the OpenGL 3.0 specification is still a big secret the Alky Project (Direct3D 10 for Windows XP) is official near dead. The project is now open source but it seems that neither the wine developers nor the team from ReactOS are interested in. Not surprising if you look at the code. It is hard to tell what they have done there after this alpha release some time ago. Personally I will wait for a working OpenGL 3.x implementation before I touch this Direct3D 10 for Windows XP thing again.

This will hopefully give me some time to work on my managed Direct3D library or doing some work on my Direct3D 10/10.1 compatible software rasterizer. I know that software rasterizer projects sound a little bit retro today. But with the mass availability of multi core CPUs it got a new interesting aspect. Adding a Direct3D unification layer to my managed Direct3D library is an interesting project, too. As always I could not really decide what I like more.

Download

Based on the new distribution interval it is three month after the last SDK.

For Direct3D there are only minor changes:

The fragment linker and the constant table can now requested as large address aware with two new flags (D3DXFRAGMENT_LARGEADDRESSAWARE; D3DXCONSTTABLE_LARGEADDRESSAWARE) and two new functions that can handle these flags (D3DXGetShaderConstantTableEx; D3DXCreateFragmentLinkerEx)

The XACT Engine is upgrade to version 2.10 and therefore use new GUIDs. Additional there is a new XACT 3 Engine that got complete new headers.

XAudio2, as still in BETA, get’s some heavy reworked headers.

For both sound APIs there is  an additional supplement called “Audio Processing Objects” (XAPO).

The documentation includes a new section about the DDS format and what have changed there for Direct3D 10.

Time runs fast if you are busy. It’s is more than a month since my last entry and at least two months to wait for the next DirectX SDK.

In the mean time I am doing some work on my codeplex project. The biggest hole is still the Direct3D9 part but it gets some updates lately. But I am although adding some code for Direct3D9Ex and the upcoming Direct3D 10.1.

An interesting aspect of Direct3D 10.1 is that you can create a D3D10.1 device even on Direct3D 10.0 Hardware. The new functions will not work and therefore we got some kind of a caps system back. But instead of many bits and values there is only a global enumerator. The D3D10_FEATURE_LEVEL1 value that need to provided during device creation  select the feature set .

Currently there are two values: D3D10_FEATURE_LEVEL_10_0 and D3D10_FEATURE_LEVEL_10_1. There is no D3D10_FEATURE_LEVEL_9_0 but from the technical point of view it would not impossible to write a Direct3D 10 runtime that works with older Direct3D 9 level hardware. It need to provide an additional interface to query the caps but beside of this it would simplify the development of applications that need to scale over a large  range of GPUs. But to make it useful this runtime need to be part of the redistributable DirectX components and work on Windows XP too.

I don’t expect such a solution from Microsoft but as it could build on top of Direct3D it can be done as an community project. 

Download

Two months are over again and it is time to check what’s new.

Two new APIs:

-          A tech preview of Direct3D 10.1

-          A Beta from XAudio2

XACT:

-          Upgraded to version 2.9 without any interface changes

Direct3D 9:

-          SDK  version is update but no interface changes

DXGI:

-          There is a new usage flag: DXGI_USAGE_DISCARD_ON_PRESENT

Direct3D 10:

-          A new enumeration: D3D10_PRIMITIVE

-          A new format support flag: D3D10_FORMAT_SUPPORT_SHADER_GATHER

-          Some new debug messages:

D3D10_MESSAGE_ID_BLENDSTATE_GETDESC_LEGACY
D3D10_MESSAGE_ID_SHADERRESOURCEVIEW_GETDESC_LEGACY
D3D10_MESSAGE_ID_CREATEQUERY_OUTOFMEMORY_RETURN
D3D10_MESSAGE_ID_CREATEPREDICATE_OUTOFMEMORY_RETURN
D3D10_MESSAGE_ID_CREATEPREDICATE_INVALIDDESC
D3D10_MESSAGE_ID_CREATECOUNTER_OUTOFRANGE_COUNTER
D3D10_MESSAGE_ID_CREATECOUNTER_SIMULTANEOUS_ACTIVE_COUNTERS_EXHAUSTED
D3D10_MESSAGE_ID_CREATECOUNTER_UNSUPPORTED_WELLKNOWN_COUNTER
D3D10_MESSAGE_ID_CREATECOUNTER_OUTOFMEMORY_RETURN
D3D10_MESSAGE_ID_CREATECOUNTER_NONEXCLUSIVE_RETURN
D3D10_MESSAGE_ID_CREATECOUNTER_NULLDESC
D3D10_MESSAGE_ID_CHECKCOUNTER_OUTOFRANGE_COUNTER
D3D10_MESSAGE_ID_CHECKCOUNTER_UNSUPPORTED_WELLKNOWN_COUNTER
D3D10_MESSAGE_ID_SETPREDICATION_INVALID_PREDICATE_STATE
D3D10_MESSAGE_ID_QUERY_BEGIN_UNSUPPORTED
D3D10_MESSAGE_ID_PREDICATE_BEGIN_DURING_PREDICATION
D3D10_MESSAGE_ID_QUERY_BEGIN_DUPLICATE
D3D10_MESSAGE_ID_QUERY_BEGIN_ABANDONING_PREVIOUS_RESULTS
D3D10_MESSAGE_ID_PREDICATE_END_DURING_PREDICATION           

D3D10_MESSAGE_ID_QUERY_END_ABANDONING_PREVIOUS_RESULTS
D3D10_MESSAGE_ID_QUERY_END_WITHOUT_BEGIN

D3D10_MESSAGE_ID_QUERY_GETDATA_INVALID_DATASIZE
D3D10_MESSAGE_ID_QUERY_GETDATA_INVALID_CALL
D3D10_MESSAGE_ID_DEVICE_DRAW_PS_OUTPUT_TYPE_MISMATCH
D3D10_MESSAGE_ID_DEVICE_DRAW_RESOURCE_FORMAT_GATHER_UNSUPPORT

-          A new name element: D3D10_NAME_COVERAGE

Direct3DX 10:

-          Four new functions:
D3DX10CreateDevice
D3DX10CreateDeviceAndSwapChain
D3DX10GetFeatureLevel1
D3DX10DebugMute 

Direct3D allows you to get the version number of the used display driver.  But the Direct3D SDK documentation doesn’t told you what this number can tell you. This information is only in the WDK (windows driver kit) formerly known as DDK.

As every other version number in the windows world they have four part separated by a dot. The first one encodes the operating system the driver was written for.

The second number defines the supported device driver interface

The last two numbers are mostly defines by the driver developers and include the real driver version.

Most time you would not have to care about this stuff but it could be useful if your code runs on some exotic hardware. The XP Version of Direct3D 9 needs only a driver with the DX 7 device driver interface. But without a real D3D9 driver the runtime change some behaviors.

On Vista there is an uglier problem with the driver versions. DXGI seems to use the second number to check if Direct3D 10 is supported. This would not be a problem as long as the drivers have the right version number. Unfortunately nvidia install the D3D10 drivers even if there is no GeForce 8xxx in the system. Therefore the version numbers that Direct3D reports are not a good way to check if Direct3D hardware is available.

Wine got its first lines of Direct3D 10 code this week. At least a sign a life even if it is only a small one.

The guys from Falling Leaf haven’t release anything new but they have give some kind of road map in their forum. First Quarter of 2008 seems their current aim for a release.  In another thread they talk about 2 or 3 month to show some “real” demos running.

I haven’t much time lately to work on my own little wrapper. To get the Tutorials running with the UI I need to add geometry shader first. DXUT use the D3DX10 sprite class that use a geometry shader to draw sprites. As simple as it sounds it may requires some changes as my generated GLSL pixel shader now can feed from a vertex or geometry shader. But I believe I can get the tutorials running by end of the month.

Finally after some time with only videos AMD/ATI let everyone download the new Ruby demo as executable.  After the hardly readable words of warning: “Whiteout demo requires Windows Vista®, an ATI Radeon™ HD series product with 512MB of video memory and a high end CPU with 1GB of RAM” I should not expect that it works on a G80. But I thought I will give it a try as the required hardware and the G80 are both Direct3D 10 GPUs.

At first it looks good. The load screen shows up and the bar grows and reaches the end. But then there is a colorful pixel soup before everything goes pure white. Even with the sound is still there I decided to stop they dilemma. After the desktop is back again a info box popped up that informs me that my video driver was reset.

Looks like I have to blame nvdia for a bad driver but I give it a second run with the debug layer active. Firstly the log shows some warnings about bad data types in the input layouts. But then it starts to throws errors about bad shader semantic bindings.  This increases the responsible for this to the demo group that writes the sushi engine.

The final question is what can a Direct3D 10 programmer learns from this?

Always use the debug layer during development as you can’t trust the drivers. Some may become unstable others may ignore the errors.

It’s time again for the bimonthly DirectX SDK comparison. The June SDK includes the following header changes.

Direct3D 9:

The June version adds all the D3D9Ex stuff that was formerly part of the Platform SDK.

Direct3DX 9:

The version is upgraded to 34.

There is a new flag for the effect system. D3DXFX_LARGEADDRESSAWARE allows the effect system to use the upper address space. If this feature is used a D3DXHANDLE is not longer compatible with LPCSTR.

Direct3DX 10

The version is now 34 too. The preprocessor defines D3DX10_DLL_W and D3DX10_DLL _A can now be used to load the right D3DX 10 DLL dynamic.

XACT:

The engine use new GUIDs (as always)

X3D audio listener now supports a cone.

X3D audio emitter has an additional InnerRadius and InnerRadiusAngle.

XInput:

Add subtypes for guitar and drum kit.

Direct Draw:

Yes you read right. :D

Direct Draw on Vista supports shared surfaces and therefore there are some new caps. Additional there are new flags that controls how the GDI DCs are handled.

Sometimes it is better to double check your results.

It’s still true that a view object does not change the reference count that you can influence with AddRef and Release. But there is another internal mechanism that protects the resource from being deleted as long as there is a view object alive. This makes it not necessary to keep a reference to the resource after you have created a view. Additional the presented code to free a view that was created with a D3DX10CreateShaderResourceViewFrom is totally wrong. It causes a memory and resource leak. My only excuse for this mistake is that the samples in the SDK do it wrong too. Instead of executing this complex code it would be enough to simply release the view.

This all change the answer to the question form “You, only you.” to “You and other Direct3D 10 object you own”. This could although include effect parameters. Therefore you have to release the effect or set the parameter to NULL to free a resource for sure.

Update: I was wrong.

You, only you.

This answer sounds strange as in the world of COM reference counting there can be more than one single owner. With Direct3D 9 the device becomes a second owner of your texture as soon as you call SetTexture. You may already read that this is not longer true for Direct3D 10. For nearly every application this change would make no difference as they hold a reference to the resources anyway.

But with Direct3D 10 most times you assign a view instead of a resource to the pipeline. This could lead to the idea to keep only a pointer to the view and not to the resource itself. Especial in the case when the resource is immutable.

You may use code like this one:

Device->CreateTexture2D (… , &pTex);
Device->CreateShaderResourceView (pTex, NULL, &m_pView);
pTex->Release ();

It locks right but as soon as you assign this view to the device strange things would start to happen. The reason for this is that the Release call destroy your texture as the view doesn’t add a reference during creation. But the view will still point to the now invalid texture resource. Maybe the pointer becomes valid again after you create another texture. But even if this happen the result on the screen will not be the expected. To avoid this you should never ever release a resource as long as there is a view attached to it.

But this behavior of the view objects could hit you on another place, too. There are three D3DX10CreateShaderResourceViewFrom methods that give you a newly created shader resource view. As this view haven’t call AddRef for the resource it contains it will not call Release for it during its own destruction. Therefore you would have leaked a resource when you only release the view. Instead you have to do the following.

ID3D10Resource* pRes;
pView->GetResource (&pRes);
pRes->Release(); // GetResource have called AddRef.
pView->Release ();
pRes->Release();

You can use the same code if you want to store only the view of your own created resources. But it could be tricky to remember which view can be released direct and which one need this special handling.

But even if I got some Direct3D 10 applications working it would, as any other wrapper project, never a 100% replacement for the original Direct3D 10 on Vista. With every new D3D10 game it could fail again. The original version would never have such problems as this games we developed used it. Another problem would be the mapping of functions that have no OpenGL counterpart. And finally as any other emulation layer it would need some CPU time. Therefore a CPU limited application would possibly run faster with the original.

A blog entry from Cody Brocious about the Alky Project this week had let me think again about the possibility to run Direct3D 10 games on Windows XP. Some euphoric people have already called this a world saver or something like this. I am although have read comments that call this solution a back port. Something that many people had said is not possible at all. First of all this is not a back port it is an wrapper or to more exact an Direct3D API to OpenGL API translation layer. You may ask why something that could run D3D10 applications is not a back port. Well it may or may not run applications that make use of the D3D10 API but you still can’t use Direct3D 10 GPU drivers on other systems than Windows Vista. A full back port would required this and as I had written before this would requires a huge amount of work that is practical impossible for someone outside Microsoft. Maybe this Windows clone ReactOS would someday handle Windows Vista drivers but this would not made Direct3D 10 games playable on Windows XP.

You may say I should go away with this technical stuff as you only want your Direct3D 10 applications run on Windows XP and these guys will made it possible for you. They even talk about the unnecessary to update your video hardware. All this for only $50 that you have to pay to become a member of their Sapling Program. Doesn’t this remember on the bussines model of Cedega? Well Transgaming Technologies want $5 per month and I haven’t see any word about Direct3D 10 but at least you get more than simple promises for your money.

Talking about promises get us to the question: “Could the Alky Project successful?”

It is not impossible but in its current state this software is far away from giving you bank for your bucks. Not a single Direct3D 10 application I tried with it works correct. Most of them doesn’t even start at all. The rest produce not the correct visible result. Many Direct3D(X) 10 entry points are missing and even the functions that work are only stubs. Somebody mention in the comments to their blog entry that the wrapper use only the fixed function OpenGL pipeline and doesn’t care about the shader code. I don’t know how long they have need to put this together but hopefully not that long. Anyway I don’t expect that they are ready when the first game with Direct3D 10 support hit the shelf.

Does this mean that all hope is gone? Well the Wine team has started working on Direct3D 10, too. But natural they are focusing on Linux and their summer of code is more about building the basic infra structure. But with this there are only one step behind the Alky Project. Well anybody who starts with a Direct3D 10 to OpenGL wrapper today is only one step behind.

With at least two projects on the way we could though that the future of Windows XP gaming looks bright. But how long would it take until these approaches can show us some real results like running a game like it was meant on Windows XP instead of Windows Vista?

I don’t know the answer and therefore I had to wait and see.

After the April SDK still doesn’t contain a piece of a managed Direct3D 10 I decide to update my own solution again.  If you look at the new assembly you may notice that there is a Direct3D 9 namespace, too. The code behind this is not ready to use for more than simple device enumeration but I was too lazy to remove it from this build.

As every two month we got a new DirectX SDK.

You can download this piece over there. There is no download for the debug symbols as they are now distributed with the same symbol server that is used for the operating system symbols.

As every time a quick comparison of the new and old headers show some differences.

The D3DX9 version is updated to 33 but there are now API changes. A look at the release info shows that the new version was nessary because the shader compiler is updated.

DXGI defines 3 new status and error messages:

-          DXGI_STATUS_MODE_CHANGE_IN_PROGRESS

-          DXGI_ERROR_GRAPHICS_VIDPN_SOURCE_IN_USE

-          DXGI_ERROR_NOT_CURRENTLY_AVAILBLE

Let’s look at Direct3D 10:

-          The SDK version goes one up to 1001.

-          There is a new shader variable type: D3D10_SVT_TEXTURECUBEARRAY

-          3 new shader input flags: D3D10_SIF_TEXTURE_COMPONENT_0, D3D10_SIF_TEXTURE_COMPONENT_1, D3D10_SIF_TEXTURE_COMPONENTS

-          One new Name: D3D10_NAME_SAMPLE_INDEX

-          The shader debugging structures are removed.

-          The shader desc lost 4 instructions counts but they are still in the documentation (need to ask what’s going on there)

-          The sRGB D3DX10_FILTER enumeration values are back.

-          All functions that takes a thread pump take an additional pointer to an HRESULT were the asynchronous operation result can be stored.

-          The D3DX shader compile functions now take two flags instead of one.

-          The D3DX effect creation functions take additional profile information.

-          D3DX10LoadTextureFromTexture and D3DX10FilterTexture are not longer support a threaded operation.

-          D3DX10SaveTextureToMemory takes an addition flag parameter.

In comparison to Direct3D 9 there is no general object for hardware enumeration in Direct3D 10. But Vista supports another API for this purpose. DirectX Graphics Infrastructure (DXGI) is the way to go. This short example shows how to use DXGI to look for a Direct3D 10 compatible graphics adapter.

     IDXGIFactory* pDXGIFactory; 

      HRESULT hr = CreateDXGIFactory (__uuidof(IDXGIFactory), (void**)&pDXGIFactory);

      if (hr != S_OK) 
            return -1;

      int AdapterIndex = 0;

      IDXGIAdapter* pAdapter;

      // Loop as long as DXGI returns valid adapters.

      while (pDXGIFactory->EnumAdapters (AdapterIndex, &pAdapter) == S_OK) 
      { 
            DXGI_ADAPTER_DESC AdapterDesc; 

            if (pAdapter->GetDesc (&AdapterDesc) != S_OK) 
                  continue; 

            std::wcout << L"Name:                    " << AdapterDesc.Description << "\n\r"; 
            std::wcout << L"D3D10 support:           "; 

            LARGE_INTEGER version; 

            if (pAdapter->CheckInterfaceSupport (__uuidof (ID3D10Device), &version) != S_OK)
                  std::wcout << L"NO\n\r"; 
            else 
                  std::wcout << L"YES\n\r"; 

            pAdapter->Release (); // Don't forget to release when you are done 
            AdapterIndex++; 
      } 

      pDXGIFactory->Release ();

Be aware that the key method CheckInterfaceSupport will not work with interface GUIDs of older Direct3D version.

Maybe you know this situation. After spending more hours together with the debugger than it is good for you are ready to shout: “It must be the compiler. It couldn’t be the source code.” Normally someone else will you then remember on one of the general rules. <Don’t blame the compiler. If you put garbage in it will give you garbage back.>

Well last week I was looking for a problem that unfortunately only occurs on a test system without any debugger at all. To make the whole thing even more badly the application simply terminates without showing our friend Dr. Watson. Using some tracelogs I was able to find the region that cause the problem but not the function that was responsible. I finally decide to give the remote debugger a chance and to my surprise I was able to attach it before the app crashes and it reports a access violation back to my development system. Unfortunately the debugger was not able associate the source code on my system with the app on the test system but I got the memory address of the failing instruction. Maybe you already know this little trick. The Visual Studio debugger allows you to set breakpoint on instruction addresses and will translate the address to a function name if possible.

After this step I know the function and I even know why it was only happening on the test system. The function contains some 3DNow code that will not be used on any system. Anyway I don’t know how old this function is but it has never failed in this way before. Out of good ideas I decide to take a look at the generate code and directly for the instruction that caused the crash it does some really crazy things with the stack pointer.

This remembers me on another general rule: “No rule without exception”. It may very uncommon these days but there is still a chance that you can blame the compiler and win. The chances are small but at least this shows us that anything is possible.

It’s time again to take a look at the last DirectX SDK. But this time there isn’t much to report.

XACT is upgraded to version 2.6 and as always after a version upgrade the GUIDs change.

The second change are some constants for DirectSound. As stated in the “What’s new” this change is mainly about the speaker configuration.

Finally the version of the whole SDK is upgraded and that’s all what you will find in the includes.

Two months are over and there is another DirectX SDK.

The side contains the changes in an overview style but a comparison of the headers tells us more.

Here we go:

D3D9:

The shader compiler gets a bunch of new flags:

D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY
D3DXSHADER_IEEE_STRICTNESS
D3DXSHADER_USE_LEGACY_D3DX9_31_DLL

D3DXSHADER_OPTIMIZATION_LEVEL0
D3DXSHADER_OPTIMIZATION_LEVEL1
D3DXSHADER_OPTIMIZATION_LEVEL2
D3DXSHADER_OPTIMIZATION_LEVEL3

The D3DXPARAMETER_TYPE enumeration has the new member D3DXPT_UNSUPPORTED.

There are a number of new math functions:

D3DXSHMultiply2
D3DXSHMultiply3
D3DXSHMultiply4
D3DXSHMultiply5
D3DXSHMultiply6

The documentation contains the details.

The sprite object got a new flag. D3DXSPRITE_DO_NOT_ADDREF_TEXTURE could improve the performance.

D3D10:

The device interface includes two new members SetTextFilterSize and GetTextFilterSize. The documentation doesn’t tell us what they do.

There is a new flag for device creation. D3D10_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS.

Three new message ids for the debug feature:

D3D10_MESSAGE_ID_DEVICE_SETTEXTFILTERSIZE_INVALIDDIMENSIONS
D3D10_MESSAGE_ID_DEVICE_DRAW_SAMPLER_MISMATCH
D3D10_MESSAGE_ID_CREATEINPUTLAYOUT_TYPE_MISMATCH

The Shaderdescription got 6 new members:

GSOutputTopology
GSMaxOutputVertexCount;
MovInstructionCount;
MovcInstructionCount;
ConversionInstructionCount;
BitwiseInstructionCount;

D3D10GetShaderDebugInfo gives you a binary block with the debug info includes in a shader. There are a number of new structures for this. The documentation includes their names but not many details. The header contains some comments that could help.

D3DX10 got the D3DXSHMultiplyX functions too.

There are three filter flags remove from D3DX10:

D3DX10_FILTER_SRGB_IN
D3DX10_FILTER_SRGB_OUT
D3DX10_FILTER_SRGB

Three new functions for texture handling and their helper structure:

D3DX10LoadTextureFromTexture, D3DX10FilterTexture and D3DX10SHProjectCubeMap.

DXGI:

We got a new flag for MakeWindowsAssocation. DXGI_MWA_NO_PRINT_SCREEN disable the print screen key.

As we have three instead of two flags know the DXGI_MWA_VALID value is changed to 0x7

In the case you are using XACT there are many changes too.