A proposal for Bindings Owners to allow more bindings into Silk.NET #2030
Conversation
|
This is ready for a pre-WG review. |
| 3. An API developed by a multi-vendor standards team/body, or an API with notable industry presence otherwise implemented by multiple vendors and/or developed in collaboration with those vendors. | ||
| 2. The C API being bound to **must** have open-source headers that do not preclude the automated transformation to C# bindings without undue licensing provisions inflicted on users of such transformations. | ||
|
|
||
| All Khronos and DirectX APIs meet both requirements 1.1 and 1.3. OpenAL also meets this requirement based on its historical development. GLFW and SDL both meet these rqeuirements today given that the Windowing HLU requires both of them in 2.X, their continued status as "core binding" is dependent on what the final implementation of the Windowing 3.0 proposal [5] uses. |
There was a problem hiding this comment.
| All Khronos and DirectX APIs meet both requirements 1.1 and 1.3. OpenAL also meets this requirement based on its historical development. GLFW and SDL both meet these rqeuirements today given that the Windowing HLU requires both of them in 2.X, their continued status as "core binding" is dependent on what the final implementation of the Windowing 3.0 proposal [5] uses. | |
| All Khronos and DirectX APIs meet both requirements 1.1 and 1.3. OpenAL also meets this requirement based on its historical development. GLFW and SDL both meet these requirements today given that the Windowing HLU requires both of them in 2.X, their continued status as "core binding" is dependent on what the final implementation of the Windowing 3.0 proposal [5] uses. |
| 3. The C API **must** be a recognised industry standard multimedia or compute API, aid in the creation of applications making use of such APIs, and/or used to implement a Silk.NET High Level Utility. | ||
| - The "recognised industry standard multimedia or compute API" covers all Khronos APIs, OpenAL, and the 2.X portfolio of DirectX bindings. | ||
| - The "aid in the creation of applications making use of such APIs" covers Assimp and Shaderc. | ||
| - The "used to implement a Silk.NET High Level Utility" covers GLFW and SDL. |
There was a problem hiding this comment.
I understand why you write this, but seeing that Silk SDL bindings are the best ones available, is it there for the HLU or primarily for Standard Multimedia API?
There was a problem hiding this comment.
Basically, we will maintain our SDL bindings to the best of our ability so long as we're using them in our windowing/input HLU APIs. This does not preclude the bindings going beyond what is needed for the HLUs e.g. binding to the rendering APIs for instance, but it sets a tone for how we approach their maintenance.
Our approach in 2.X is not changing in 3.0.
There was a problem hiding this comment.
So if the HLU, which some might not use (preferring their own), switches to direct Mac/windows/X bindings, Silk SDL could be dropped according to the new proposal.
Or rather, it would have to become an Additional Binding.
According to https://www.nuget.org/profiles/Silk.NET, the most popular bindings are OGL/Vulkan, then LWGL, and then SDL. The HLU is actually less popular than SDL itself. Do I read that correctly?
There was a problem hiding this comment.
I think you're correct that we should likely make it so core bindings must remain core for the entirety of the major version's lifecycle.
Just read the proposal, I promise this isn't scope creep.