search

MichalStrehovsky / sokol-csharp

C# bindings for Sokol using Sokol's binding generator
32 stars 2 forks source link

alternative bindings #1

Open lithiumtoast opened 3 years ago

lithiumtoast commented 3 years ago

heya, just FYI

I have progress on generating bindings for sokol automatically for C# using an alternative method: https://github.com/lithiumtoast/sokol-cs You can find my break down here: https://github.com/floooh/sokol/issues/448#issuecomment-753645295

I'm currently investigating nAOT using the above technique. Dynamic linking works, static linking does not work so far in my testing.

I will try zerosharp and bflat next :)

MichalStrehovsky commented 3 years ago

Ah, didn't see that, I was looking into something that would work with sokol's native bindgen and didn't see C# there yet. As you probably saw, it wasn't much work to tweak the Zig python generator to generate C# instead.

I see we came up with different solutions to the inline array problem.

I guess mine requires a bit less trying to figure out type layout manually and I just let the runtime handle that. Hopefully https://github.com/dotnet/runtime/issues/12320 will fix that for good soon. One obvious drawback of the ExplicitLayout approach is that two versions of the bindings are necessary to cover 32bit and 64bit platforms. ExplicitLayout also affects System-V struct passing which might pose a problem on systems that follow System-V calling conventions (Linux). I don't know whether any of the structs in Sokol are passed by value (the calling convention obviously doesn't matter when passed by reference).

lithiumtoast commented 3 years ago

One obvious drawback of the ExplicitLayout approach is that two versions of the bindings are necessary to cover 32bit and 64bit platforms.

Yup, structs will be different sizes based purely on some fields being pointers. But, 64 bit is pretty ubiquitous these days, at least for gaming, as you can see from Steam hardware survey: https://store.steampowered.com/hwsurvey/directx/. I'm mostly interested in creating bindings of C libraries for C# in the context of game development so in practice this is a minor problem. In contexts where both 32-bit and 64-bit bindings are required it's also simple enough to just have 2 bindings at the cost of duplication of C# code / extra C# code. When the bindings are automatically generated it's not that much more effort :)

ExplicitLayout also affects System-V struct passing

I'm not aware of any problem so far. I do all my primary development on and for macOS (BSD-like). I also test on Windows and Linux Ubuntu after macOS is working correctly. So far I have been experimenting with libuv, sokol, flecs, and SDL2 without any problems.

MichalStrehovsky commented 3 years ago

The explicit layout stuff might have been fixed in https://github.com/dotnet/coreclr/pull/22041. Looks like I'm not good at keeping track of those things.

lithiumtoast commented 3 years ago

The explicit layout stuff might have been fixed in dotnet/coreclr#22041. Looks like I'm not good at keeping track of those things.

Yup, the documentation warns about ExplictLayout on non-Windows before .NET Core 3.0. https://docs.microsoft.com/en-us/dotnet/standard/native-interop/customize-struct-marshaling

❌ AVOID using LayoutKind.Explicit when marshaling structures on non-Windows platforms if you need to target runtimes before .NET Core 3.0. The .NET Core runtime before 3.0 doesn't support passing explicit structures by value to native functions on Intel or AMD 64-bit non-Windows systems. However, the runtime supports passing explicit structures by reference on all platforms.