Split this project into small ones

[jfrancisco-neto]

You could split this project into small ones that have especific files, ex:

Dx9, dx11, dx12, dxdi e etc.

And, of course, upload the bins into the nuget.org to make it more easy to use.

[smourier]

Hi,

I won't break the project into smaller ones, because I can't really. When you pull out a C/C++ header, many other definitions from other headers come with it. All technologies are much more inter-related than one could think. For example, DXGI uses WIC, DX12 uses other DX headers, etc. So there is no real clear technical separation of definitions.

Also the +6000 files are automatically generated, so the cool thing is it will be relatively easy to update them when there are updates like DX13, new SDKs, new technology etc. The whole project has been built to support quick updates, and I wouldn't be able to maintain it if it was organized manually.

What I could do though is organize the 6000 files using folders representing the header files that defines it. So for example D2D1_STROKE_STYLE_PROPERTIES1.cs would be stored in a "d2d1_1.h" folder. At least it would be easier to browse in github.com!

For the nuget, yes, I will do it when I find 5 minutes.

[na2axl]

For example, DXGI uses WIC, DX12 uses other DX headers, etc. So there is no real clear technical separation of definitions.

So it's really not possible to create projects like DirectN.DXGI which depends on DirectN.WIC and a DirectN.Common which hold common files used by others projects ?

I think it will be very greater and will make your library more usable since it will allow users to pick only the wrapper he want (like me, I'm only interested on DirectX wrappers and browse more than 6000 files to get it is not easy).

[jfrancisco-neto]

@na2axl totally agree. Other alternative is to create the wrapper yourself using SharpGen or CppSharp. It would be great if the project split happen... but at least we have alternatives.

[smourier]

I don't pretend to be a great SharpGen or CppSharp expert, but I tried them before I started DirectN as I hate to reinvent the wheel.

Just try CppSharp on one header file such as d3d9helper.h like this:

class Program
{
    static void Main(string[] args)
    {
        ConsoleDriver.Run(new SampleLibrary());
    }
}

class SampleLibrary : ILibrary
{
    public void Postprocess(Driver driver, CppSharp.AST.ASTContext ctx)
    {
    }

    public void Preprocess(Driver driver, CppSharp.AST.ASTContext ctx)
    {
    }

    public void SetupPasses(Driver driver)
    {
    }

    public void Setup(Driver driver)
    {
        var options = driver.Options;
        options.GeneratorKind = GeneratorKind.CSharp;
        var module = options.AddModule("d3d9");
        module.Headers.Add(@"C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\d3d9helper.h");
    }
}

and look at the d3d9.cs file produced. you'll see this it's beautiful, but ... ridiculous and totally useless. it doesn't compile, it's using pointers (needs unsafe), manual allocation, derived interfaces are wrong, structs are wrong, etc. also, where are the needed IID (interface ID) guids?

No offense to the developers, it's just it's not the right tool (again, maybe there are some tweaks we can apply that I don't know).

You see, when you look at hundreds of Windows header files, there are files down there that are more than 20-years old. So, for example they don't use annotations and it's very difficult to know what's the correct C# interop definition (in fact DirectN probably contains incorrect definitions). D3D9 are probably the worst to work with.

And BTW, you can observe in the generated d3d9.cs the same issue that's globally solved in DirectN: references. When you start trying to interop just 1 file, you draw an almost never ending thread of needed references.

DirectX needs DXGI stuff to compile. DXGI needs WIC stuff to compile. WIC needs some old GDI structures to compile, etc.

Anyway, I'm not saying that it's technically impossible to split the whole thing into smaller ones, but it's a lot of manual work. The best alternative is use SharpDX which is very good (but I suppose it requires a lot of work from the developer(s), much more than the time I can spend on DirectN). I used it before writing DirectN and I had a lot of issues with it trying to match SharpDX naming with Windows documentation, and it has the same references issue, one you start using one SharpDX assembly, you end up using all of them pretty rapidly. That's why I created DirectN. One super strong DirectN's objective is to correspond to the header files, and to the official documentation, naming, etc.

But the whole DirectN.dll is just ~3M size (same size as combined size of SharpDX files, which makes sense). The nuget is a must, I'll work on that asap.

[smourier]

I have added the Nuget https://www.nuget.org/packages/DirectN/. I'll close this issue for now.

[jfrancisco-neto]

@smourier good point. Thanks for your kindness.

[EzeKees]

I agree with @smourier comment. It is preferable to have everything in the same assembly, in the long run, you end up using everything