Vortice integration

[amerkoleci]

Before starting with PR would this project be interested in migrating from SharpDX to mine Vortice.Windows directx bindings?

This will allow future d3d12 backends as the bindings are updated with latest directx SDK?

Avalonia is moving to Vortice.Windows as I made PR there as well.

Waiting for feedback.

Thanks guys!

[mrhelmut]

The team has plans to move to a different structure for MonoGame, moving away from C# wrappers and external dependencies as much as possible.

The idea is to move all platform code to native libraries maintained by the team and having MonoGame be only the high level C# facade with no bound to a platform. Ultimately, there should be only one generic C# assembly which could be used throughout all targets, with a swappable native library doing the per-platform work.

This is motivated by years of issues tracking and maintaining external dependencies and a need to standardize all platforms, especially consoles.

The plan is to implement Metal, Direct3D 12 (inc. GDK), and Vulkan this way.

[Mindfulplays]

Thank you. Are there any docs/issues we can follow along? Re: standardize platform API...

[mrhelmut]

Not yet, but some of the groundwork has started. It's a big one though, it'll take months. It is likely that MG 3.8.1 and 3.9.0 will release first and that this rework will be the next big thing.

[amerkoleci]

So you plan something similar to FNA3D native rendering library? Same for Audio etc?

[mrhelmut]

It might end up being similar or derivative, it is still being figured out.

[EzeKees]

It would be great if, if possible, the library could also be used for general use. In the same way that SharpDX or its variants are now used.

[Beyley]

It would be great if, if possible, the library could also be used for general use. In the same way that SharpDX or its variants are now used.

I doubt external use of the native libs will be a priority, but it will always be an option, given ittl just expose a C API for interop

[Beyley]

Is this like Silk .Net?..it has an interesting " API scraper" code generator and doing stuff like this... Very active vault but haven't tried it...
…
On Mon, Sep 19, 2022, 8:43 PM Beyley Thomas @.> wrote: It would be great if, if possible, the library could also be used for general use. In the same way that SharpDX or its variants are now used. I doubt external use of the native libs will be a priority, but it will always be an option, given ittl just expose a C API for interop — Reply to this email directly, view it on GitHub <#7523 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD74XGIUZOI4BP24QUONPSLV7EQFRANCNFSM46S32HJQ . You are receiving this because you are subscribed to this thread.Message ID: @.>

I dont think its the Monogame team's goal to generate their own bindings, so i dont think SilkTouch is relavent here

[mrhelmut]

It would be great if, if possible, the library could also be used for general use. In the same way that SharpDX or its variants are now used.

I doubt external use of the native libs will be a priority, but it will always be an option, given ittl just expose a C API for interop

Not a priority because we don't want to have to do the customer support for an additional audience.

Also, Silk and every other C# wrappers are exactly what we'd like to avoid. The closest library to what we intend to do is FNA3D (or possibly the upcoming new SDL_gpu).

[Ravendarke8]

Also I don't see point in supporting different wrapper "just because". That is ofc considering the plans for completely native rendering backend, all and all I have nothing against vortice as wrapper, just in this context I don't see a reason.

[rds1983]

Moving all platform code into native library might not be the best idea, imho.
Because MonoGame will then lose its unique trait.
I mean for many years, FNA & MonoGame used different approaches on how to handle platform-specific code. FNA was relying on native libs. While MG used C# wrappers. And that made both frameworks unique to each other.
Now, if MG will follow FNA's way, frameworks will basically become clones.

Moreover I dont think that C# wrappers approach is worser than native libs approach.
At least, if one needs to dive into the platform code, then diving into C# code is way more pleasant.