2.17.0 Spring 2023 Update 1

[Beyley]

Silk.NET Spring 2023 Update 1

• Added zero-cost extension methods for ComPtrs, making our DirectX bindings easier to use and higher quality than ever before.
• Added WebGPU bindings for Dawn and WGPU.
• Added Direct2D bindings. (massive thank you to @curin)
• Added DirectComposition bindings. (again, massive preesh to @curin)
• Added DirectWrite bindings.
• Added d3d11on12 bindings.
• Added WGL bindings.
• Added support for Android 12.
• Added support for OpenAL disconnect extension. (thanks @okaniku)
• Added GLFW API constants for ANGLE. (thanks @cyraid)
• Added extension functions for OpenAL BufferData to make use of AL_EXT_float32 enums.
• Added ReopenDevices extension for OpenAL Soft. (thanks @LeNitrous)
• Added BufferCallback extension for OpenAL Soft.
• Added Vulkan structure chain polymorphism. (thanks @Khitiara for the proposal)
• Added SDL/GLFW native libraries for Windows on ARM64.
• Added IsScancodePressed function in Silk.NET Input.
• Added TopMost in Silk.NET Windowing (thanks @MarioGK)
• Added EGL display and surface to INativeWindow.
• Added an explicit check against calling Reset on a window while within the render loop of said window.
• Added support for multiple native binary candidate paths for a single binding.
• Improved support for WASM and AOT in the Silk.NET loader.
• Improved support for Windows on ARM64.
• Improved Silk.NET.Maths generic specialization codegen.
• Improved support for DXVK, including a new DXHandle property in INativeWindow for getting Linux HWND equivalents.
• Improved support for Silk.NET.Windowing under reflection-free NativeAOT
• Updated to SDL 2.24.
• Updated to Vulkan 1.3.246.
• Updated to DirectStorage 1.1.1.
• Updated to OpenXR 1.0.27.
• Updated to Assimp 5.2.5.
• Updated to latest OpenCL specifications.
• Updated to latest OpenGL specifications.
• Updated to latest ImGui.
• Fixed XInput GetApi not being implemented. (thanks @skyebird189)
• Fixed TransparentBuffer not being applied correctly without specifying a PreferredBitDepth. (thanks @MarioGK)
• Fixed wide string marshalling.
• Fixed string array marshalling on systems where the max DBCS character size is insufficient for UTF8.
• Fixed Span overloads not calculating the correct length value for ommitted (implicit) length parameters.
• Fixed copying of native libraries under .NET Framework 4.6.1. (thanks @paralaxsd)
• Fixed SDL crashing on Android when the screen rotates in some cases.
• Fixed a memory leak when using GlobalMemory to marshal string arrays instead of StringArrayToPtr. (thanks @Khitiara)

Welcome to the biggest update yet!

---

This discussion was created from the release 2.17.0 Spring 2023 Update 1.

[desiwko]

- Updated to latest OpenGL specifications.

Not sure if it's this or something else, but updating to 2.17 totally broke existing code for me. Seems to revolve around OpenGL buffer objects and/or VAOs. Trying to do a little digging on my end to see if it's a me thing or something else. Rolling back to 2.16, everything works fine.

[Perksey]

I think we silently changed the default depth buffer settings & colour buffer settings to be consistent across the backends, but that’s the only thing I can think of. We barely touched OpenGL this update.

[desiwko]

I think it has to do with this:

Fixed Span overloads not calculating the correct length value for ommitted (implicit) length parameters.

One of my goals with Silk.NET has been to avoid using unsafe methods where possible. Hopefully this serves as a minimal example.

As an example, I'm creating OpenGL buffer objects like so:

private void CreateBuffer(Span<TDataType> data, BufferTargetARB bufferTarget, BufferUsageARB bufferUsage) { Bind(); context.BufferData<TDataType>(bufferTarget, data, bufferUsage); }

With 2.16, I have no problems rendering. With 2.17, it fails to render. Changing it to the following, however, works fine and renders as expected with 2.17.

private unsafe void CreateBufferUnsafe(Span<TDataType> data, BufferTargetARB bufferTargetARB, BufferUsageARB bufferUsageARB) { Bind(); fixed(void * d = data) { context.BufferData(bufferTargetARB, (nuint)(data.Length * sizeof(TDataType)), d, bufferUsageARB); } }

(Sorry - for some reason code formatting in the comment is not updating properly for me.)
For the sake of completeness I tested against the source examples, OpenGL Tutorial 4.1, and noted only one and one half faces of the cube rendered when I modified the code to using the safe Span data method as the vertex source. Changing the package dependencies back to 2.16 it renders fine.

Hope that helps. If you need me to transcribe this into a issue just let me know.

[Perksey]

Ah, great spot! I've opened #1397 which I propose should be released as an emergency patch provided the team agree.

Storytime:

Basically, any of the implicit count span overloads where the the length of the buffer being passed in was a multiple of its length parameter (like UniformMatrix4f, the buffer you pass in needs to be 16x as long as the length parameter you pass in) were completely broken as we just passed in the length of the buffer. In 2.17, I changed the generator such that it correctly interprets bufSize*16 to mean "the bufSize parameter is bufferSpan.Length/16". However, as part of this, I was also trying to refactor the generator such that we didn't generate those horrible in T implicit in overloads that trips up a good proportion of our userbase.

As part of this, I was refactoring the RefOverloader such that it does not operate on void* and adjusting the ImplicitCountSpanOverloader (and SpanOverloader) such that it operated on either the output of RefOverloader (as it does today) or a void*. However, couldn't make this work in a way that meant the overloader didn't take ages to generate its overloads, so I started manually reverting that refactor.

After I did this, I left one line in the ImplicitCountSpanOverloader that was still operating under the assumption that it operated on void*s, which was now never the case - we had gone back to depending on the output of RefOverloader where the parameter type would be a in/out/ref generic type parameter reference! This meant that the logic that, for void*s, will implicitly multiply the length parameter by the size of the type referenced by the generic type parameter was never being activated. So, one line changed later in #1397, this now works again.

[Perksey]

Just released 2.17.1 for you, thanks again for flagging this up. Will mark this as resolved now but let me know if there are any other issues!