It needs a lot of work first (and also it currently uses vortice for the d3d implementation) And I'd need to think of it a lot before I think about asking to put it in silk community (since it's built primarily for my engine)
Also I’m not conformant, haha. Because it works atop anything, silky doesn’t need silk … it’s just that all shipped renderers are built this way, but the name still sort of ties it….
-why is the GL not static like opentk? -why is window an interface instead of an abstract class? -why does silk use unsafe code? -why isn't there documation? -why isn't the silk website updated?
Because the function pointers are tied to the OpenGL context being use. The way OpenTK handled this was maintained some secret static state (mutable static state is evil!) that you needed to explicitly switch out if you were using multiple contexts, whereas we just tie the functions to the context themselves by virtue of having an instance. In addition, it means that all of the memory consumed by the function pointer table can be freed when you're done with the object, rather than have it always linger in static state.
Because it doesn't need to be an abstract class? The windowing interfaces just define a "contract" for what APIs windowing implementations need to implement, which is the very definition of an interface. We have an abstract class internally for helping us write our own first-party applications. Unless you mean why isn't it an abstract class _you_ can inherit from? The answer to that is we're not going to force all of our users to use our APIs in a specific way, especially if that's not how our APIs are represented internally. We're not going to use a design pattern just for the sake of using it, our users can do that.
Two answers to this:
If a function uses an unsafe function (i.e. literally any function that leaves C#'s managed land and/or uses raw memory management), the caller function is only as safe as the additional checks it provides prior to accessing the callee. Given Silk.NET provides no checks, philosophically **all of Silk.NET is unsafe, even functions that don't use pointers**. What I'm trying to say is: **don't be afraid of unsafe**.
Most of our OpenGL bindings have fully "safe" overloads (in/out/ref/Span) for functions that deal in single-dimension pointers. Pointers of two dimensions or more do not get overloaded into anything meaningful today. And for the other bindings, structs don't get overloaded and are always unsafe.
Because noone has made the time to add some. We welcome community contributions in this area, it is very hard for a maintainer to maintain the entirety of Silk.NET in their free time _and_ still have time left over to write documentation at the end of it.
Because noone has made the time to update it. We welcome community contributions in this area, it is very hard for a maintainer to maintain the entirety of Silk.NET in their free time _and_ still have time left over to update the website at the end of it.
Having the window system the way it is is literally 100x nicer than the OpenTK way I switched to GLFW for the sole reason that I hated OpenTK windowing, it was in my experience laggy and the fact that you had to inherit off it meant yeah I couldn't design it in the way I wanted it to be
The silk windowing makes it tempting just to write a minimal abstract around it so it can fit in with the current windowing system I already have