Saturday 15 October 2011

64 bit build of the Microsoft Effects11 DLL

On request, I've added a 64 bit build my DLL version of the Microsoft Effects11 library.

See http://www.jsbmedical.co.uk/DirectXForDelphi/D3DX11 effects DLL.

Note that the dlls for both Win32 (x86) and x64 have the same file name. On a 64 bit OS the 32 bit dll should go in "C:\Windows\SysWOW64" and the 64 bit dll in "C:\Windows\System32". Alternatively the appropriate version can go in the same folder as the *.exe file that uses it. You can use Delphi build events to copy the appropriate dll version from a standard folder to your project output folder. Using build events to do this is useful because it means that you can delete all the files in the output folder prior to performing a release build, and the dll will be replaced during the build. It also means that when the master copy of the dll is updated it will get copied to each project output folder when that project is built.

I've not tested the x64 dll with Delphi XE2 yet as my trial version has expired.

JB.

Tuesday 12 October 2010

Update for use with June 2010 DirectX SDK

I've updated my Direct2D/Direct3D Delphi interface units for use with the June 2010 DirectX SDK.

The units should work with Delphi 2009, 2010 and XE. They may work (or be made to work) with other versions of Delphi.

Key changes:

UD3DCommon_JSB.pas added.
UD3DCompiler_JSB.pas added (allows D3D11 shader reflection).

Note that UD3DCommon_JSB.pas may need to be added to the "uses" section of existing applications.

See http://www.jsbmedical.co.uk/DirectXForDelphi/ for the units and effects DLL.

Note that applications that use these units will require the June 2010 DirectX redistributable files to be installed. The version suffix associated with this version is 43 (e.g. D3DCompiler_43.dll, d3dx11_43.dll etc).

Hint: You may wish to merge the new units with your existing units (e.g. using BeyondCompare) rather than overwrite them, so that you are aware of the changes.

JB.

Tuesday 19 January 2010

Runtime linking to Direct3D DLLs

I've added optional runtime linking to the Direct3D DLLs. By runtime linking I mean the linking is done when the application requests it, rather than when the application loads. When runtime linking is enabled, applications which use Direct3D DLLs will still load even if the DLLs are not present.

Typical situations where this is useful are:

1) Enabling applications which require a particular version of DirectX to display an accurate message about the problem - e.g. "Direct3D 11 is not installed".

2) Enabling Applications which work with a range of Direct3D versions (e.g. 9, 10, 10.1, 11) to be run even if one or more versions are not present.

To enable runtime linking:

1) Specify the conditional define "UseRuntimeLinking" in the base build configuration of the Delphi project.

2) Early on in your application, call the Link method (procedure) for each Direct3D header file that you are using.

E.g.

try
  DXGI_JSB.Link;
  D3D10_JSB.Link;
  D3D10_1_JSB.Link;
  D3DX10_JSB.Link;
except
  raise Exception.Create('Direct3D 10.1 is not installed.');
end;

Notes:
 
1) Call "Link" for later versions of Direct3D first, so that the user is instructed to install the latest required version of Direct3D. Typically all the Link calls and associated logic can be put in a single place such as your graphics library and called from many applications.
 
2) Call "Link" only once for each run of the application.
 
3) A special exception "E_Effects11" is raised by D3DX11_JSB if d3dx11Effects_JSB.dll is not present. The reason for this is that this DLL needs to be installed as part of the application and so requires a specific message about this file to be given to the user. (This DLL is typically put in System32 or the application folder).
 
JB.

Tuesday 1 December 2009

Fix for shaders not being NULLed in D3DX11 effect library

I've updated my DLL version of the D3DX11 effect C++ static library (from the Aug 2009 DirectX SDK) with a fix for its failure to NULL shader types that are not used in a given effect.

Without this fix, if one technique specifies a geometry shader and the next does not, the geometry shader specified by the first technique will be used for the second. This will either give incorrect results, or more likely, will fail due to layout incompatibilities.

The fix has been applied to vertex, geometry, hull and pixel shaders.

I've also removed the Aug_2009 suffix. Please use the latest headers so that the reference to this DLL is correct in D3DX11.pas.

See: d3dx11Effects_JSB.zip (http://www.jsbmedical.co.uk/DirectXForDelphi/).

Unzip and copy this file to the System32 folder.

JB.

Sunday 20 September 2009

Fix for shader creation bug in D3DX11 effect library

I've updated the DLL version of the pre-release D3DX11 effect C++ static library (from the Aug 2009 DirectX SDK) with a fix for its failure to create shaders when the feature level is less than 11.

Applications using D3DX11CreateEffectFromMemory now work correctly with hardware acceleration on Direct3D 10.1 graphics cards.

See: d3dx11Effects_Aug_2009_JSB.zip (http://www.jsbmedical.co.uk/DirectXForDelphi/).

Unzip and copy this file to the System32 folder.

JB.

Saturday 19 September 2009

DLL version of D3DX11 effect library

I've converted the supplied open source C++ static library version of the D3DX11 effect library to a DLL so that it can be used with Delphi.

See: d3dx11Effects_Aug_2009_JSB.zip (http://www.jsbmedical.co.uk/DirectXForDelphi/).

Unzip and copy this file to the System32 folder. The latest copy of the headers are required to link to this version.

So far, this seems to work OK with test applications that use the reference renderer.

However, please note that the Direct3D 11 test applications that I have tried, running with hardware rendering and Direct3D 10.1 feature level, cause my Direct3D 10.1 graphics card drivers (ATI) to crash and restart.

There are two error messages sent from the D3DX11 effects library to "Output" when D3DX11CreateEffectFromMemory is called:

1) "ID3D11Device:: CreateVertexShader: The pClassLinkage parameter must be NULL, unless GetFeatureLevel returns D3D_FEATURE_LEVEL_11_0 or greater".
2) "ID3D11Device:: CreatePixelShader: The pClassLinkage parameter must be NULL, unless GetFeatureLevel returns D3D_FEATURE_LEVEL_11_0 or greater".

Then there are pixel and vertex shader error messages during rendering. It seems that the D3DX11 effects library currently has a problem supporting Direct3D 10.1, coupled with problems in the current ATI drivers.

JB.

Thursday 17 September 2009

Status

I've just uploaded the latest versions.

Changes:

1) Major changes to identifier naming to make them more Delphiesque.

2) Completed the local maths functions in D3DX10_JSB.pas.

3) Added a translation of D3DX11effect.h to D3DX11_JSB.pas. This was missing from the DirectX 11 SDK (Aug 2009) include folder (as it has not yet gone "live"), but was available in an obscure sub folder. This is not yet tested to any degree, but should be soon, so please become a "Follower" if you want to use this.

4) Added a 'UsePointersForOptionalOutputInterfaces' conditional define for better Clootie/JEDI compatibility with optional output interface parameters. See the 'Translation notes' at the top of the interface units. I strongly recommend that you do not use this because Delphi does not call Release on the interface parameter before it gets overwritten (possibly the only time I've seen any problems with the wonderful Delphi interface handling). If was "nil" before the call, as it often is in initialization code, then things are OK. However, if it was already set then the reference count for the object will not be decremented, leading to difficult to diagnose problems. If you want to use this option, add the conditional define from within project options.

5) Changed enums and records to use the new Delphi style names, with type aliases for the original names to compatibility with existing code. This fixes the problem where Delphi's code insight gives the original C++ names rather than the new Delphi style names.

JB.

Monday 14 September 2009

DirectWrite and Direct2D1

I've added Delphi interface units for DirectWrite and Direct2D1.

I've kept them as separate units (even though there is a small amount of interdependency) because MS say that DirectWrite can render to an arbitrary renderer.

These compile, and I've done minimal testing (e.g. the "Hello World!" test application that you can download).

JB.

PS: I've just seen that Delphi 2010 includes a version of D2D1, but not Direct3D 11 etc.

Direct3D 10, 10.1 and 11 Delphi interface units (headers)

I've just converted the Direct3D 10, 10.1 and 11 C++ header files into interface units for use with Delphi 2009 and 2010. The interface units are based on the Aug 2009 version of the Microsoft DirectX 11 SDK (published 8th September 2009). The reason for converting them myself was because I needed them urgently and was not able to wait for the JEDI/Clootie versions.

See: http://www.jsbmedical.co.uk/DirectXForDelphi/

I will soon be using these myself, and will be posting regular updates as issues arise. Therefore if you have any problems (e.g. unexpected error messages when calling some DirectX methods), please download the latest version from the above link.

The software license is included at the top of each file.

The interface units are intended for Delphi 2009 and 2010, though they may work with other versions. If you are interested in using them with FPC or C++ I may be able to provide either multiple versions or a multi-purpose version, though I would to work with you to test them as I don't have time to install multiple compilers.

Note that Direct3D 10 and 11 are intertwined, so for Direct3D 11 you need both the Direct3D 10 and 11 interface units.

They are not quite compatible with the JEDI equivalents. For example, I've chosen to make optional interface output parameters into "out" parameters rather than pointers. This is to ensure that Release is called on the supplied interface. You can still provide a "nil" parameter - see instructions at the top of the header files. Also I've left enumerations as enumerations rather than changing them to constants, which means that you need to cast them to LongWord in some cases.

If you are interested in this work, please spread the word. If there is enough interest I will consider translating other header files on request. Delphi is a fantastically fast development environment and I am very interested in keeping it alive (in fact I need to - because the last ten years of my life are locked up in it...).

So that I can gauge the level of interest, please do get in touch (e.g. by becoming a "follower", emailing (see the comments at the top of the interface units for my email address) or leaving a message) if you are going to use, or thinking of using, this work.

John Bladen.