www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - combindings and directxbindings

reply Ethan <gooberman gmail.com> writes:
https://github.com/GooberMan/combindings
https://github.com/GooberMan/directxbindings

I needed some DirectX 12 bindings. Autogeneration was out of the 
question. The .idl files Microsoft uses internally is full of 
plain C++ code that is inserted in to headers without additional 
parsing, and DirectX is basically useless without those #defines 
and function definitions. So in between compile times elsewhere, 
I hand converted the necessary headers to D modules.

Then me being me, I wanted to go one step further. Why should it 
just be a direct translation? Why not have some convenience 
methods added?

So now there's two libraries.

combindings - A thin layer that defines COM compatible UDAs and 
autogenerates some convenience features
directxbindings - Little more than direct hand-done translations 
of DirectX headers to D

These will be updated as I use them. And they're essentially 
mostly untested right now, I'm testing as I go.

They're also released under a Creative Commons 0 license. It 
seems to be the only really valid public domain license 
internationally; and these are COM bindings. There's no way I 
should be attributed on a random project just because you're 
using a very thin glue layer I wrote for something that should 
just plain exist as a D feature anyway (ie COM interface 
autogeneration).

COM Bindings aims for compatability first, and convenience 
second. The idea is that you should be able to copy/paste code 
from C++, replace the -> with . and off you go. That's not 
_entirely_ possible for one very good reason: the IID_PPV_ARGS 
macro. This expands to two symbols meant to be inserted in a 
function call in C++. If you want to do something similar in D, 
both templates and mixin templates are entirely unsuitable. You 
need to resort to string mixins. *UGLY* *UGLY* *UGLY* why even 
bother moving to D if you're going to be uglier than C++.

Next step then. We analyse function attributes. If we find a 
 _COM_Outptr_ or  _COM_Outptr_opt_ attribute in a function and 
the previous parameter is a REFIID, then sweet. We know what to 
do. For example, the following C++ code:

HRESULT result = D3D12CreateDevice(adapter, 
D3D_FEATURE_LEVEL_12_0, IID_PPV_ARGS(&device));

Can be translated to the following thanks to the wrapper stubs 
generated:

HRESULT result = D3D12CreateDevice(adapter, 
D3D_FEATURE_LEVEL_12_0, device);

And if you really really want, you can still just do a direct 
translation of equivalent C++ code:

HRESULT result = D3D12CreateDevice(adapter, 
D3D_FEATURE_LEVEL_12_0, &IID_IDirect3D12Device, 
cast(void**)&device);

Or try something that doesn't require linking to external 
variables:

HRESULT result = D3D12CreateDevice(adapter, 
D3D_FEATURE_LEVEL_12_0, device.IIDPtrOf, cast(void**)&device);

HRESULT result = D3D12CreateDevice(adapter, 
D3D_FEATURE_LEVEL_12_0, IIDPtrOf!IDirect3DDevice12, 
cast(void**)&device);

Likewise when you have functions where the output device is 
optional, you can just straight up template instantiate them:

HRESULT result = D3D12CreateDevice!IDirect3DDevice12(adapter, 
D3D_FEATURE_LEVEL_12_0 );
Sep 06
next sibling parent Dennis <dkorpel gmail.com> writes:
On Sunday, 6 September 2020 at 18:14:25 UTC, Ethan wrote:
 So now there's two libraries.

 combindings - A thin layer that defines COM compatible UDAs and 
 autogenerates some convenience features
 directxbindings - Little more than direct hand-done 
 translations of DirectX headers to D
Cool stuff! I'm using OpenGL instead of Direct3D so I don't have a use for these currently, but I'll keep them in mind in case that changes. Have you considered publishing it to code.dlang.org? I noticed there's already https://code.dlang.org/packages/aurora-directx and https://code.dlang.org/packages/directx-d , have you checked these out?
Sep 07
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Sunday, 6 September 2020 at 18:14:25 UTC, Ethan wrote:
 So now there's two libraries.

 combindings - A thin layer that defines COM compatible UDAs and 
 autogenerates some convenience features
 directxbindings - Little more than direct hand-done 
 translations of DirectX headers to D
Cool stuff! I'm using OpenGL instead of Direct3D so I don't have a use for these currently, but I'll keep them in mind in case that changes. Have you considered publishing it to code.dlang.org? I noticed there's already https://code.dlang.org/packages/aurora-directx and https://code.dlang.org/packages/directx-d, have you checked these out?
Sep 07
parent Ethan <gooberman gmail.com> writes:
On Monday, 7 September 2020 at 19:35:41 UTC, Dennis wrote:
 Have you considered publishing it to code.dlang.org?
Not yet. Pretty busy at the moment, should probably wait for them to be actually designated usable before doing so.
 I noticed there's already
 https://code.dlang.org/packages/aurora-directx and 
 https://code.dlang.org/packages/directx-d, have you checked 
 these out?
Aurora DirectX does not convert a bunch of defines (specifically the macro expansions). DirectX-D does not preserve the COM attributes. Both are licensed in a way that will require attribution for source, and binaries for DirectX-D. Attribution for COM bindings? Nah. These *should* be autogenerated by a machine exclusively, but I haven't sat down to solve that particular problem yet thanks to the fact that you'll end up having to parse C headers every single time to get complete bindings. One thing I forgot to mention about the glue layer in combindings - it will parse named enumeration types and provide aliases to each member in the package namespace. Again, this facilitates copy/paste code. There's absolutely nothing stopping anyone applying combindings to those two alternative libraries and taking advantage of this, in fact. Not having the UDAs means you won't get the convenience methods to make your code more D-like, but you can at least convert C/C++ enumeration manipulations simply by copy/pasting the code in to D.
Sep 07