AI could bring my pie library to silk community 
S-_-
Syou want a broken ecs system?
Plol unironically sure haha
ALmao
AIt 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)
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)
Pyeah ofc
Pthere are probably requirements that prevent it going in in its current state anyway
Pi forget what we specifically wrote but i remember them being sensible
AYea
PAFair enough
AActually they are some really sensible requirements
ASomething I will def consider "applying" for once I add some more features
QIt was intended more as “general” information than dev news. But now you say it, it’s basically an infomercial 
QAlso 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….
Pwell yeah everything you're doing uses silk
Pbut it doesn't really matter what your community use it for
Psilk.net.maths could very easily be used in an opentk application
Pso it's the same difference really
Sspeaking of opentk,may i ask some questions related to opentk?
Ptheir server is the best place to get help using opentk
Snot help really tbh
Sthey are infact more related to silk
Sso
Slet me get an essay started/s
S-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?
-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?
P- 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.
P- 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.
AHaving 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
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
ABut I'm insane so I'll probably continue to write my own windowing system even if it provides literally the same functions lmao
Li have also written a very light wrapper around windowing to fit with the style of my code
Lits a really really nice interface
Pimagine if you couldn't trivially make it fit with the style of your code though
Lthat would be very slightly annoying but id probably figure it out after awhile
Lwoudlnt be as clean tho
Pexactly
PSilk.NET 1.0 was very strategically designed
PFor 2.0 we sorta forgot who we were a bit and rushed ahead to get loads more bindings and mobile support
Land it shows with the state of buildtools
PAnd in 3.0 we've returned to that strategic design (even better than last time as well)
L(still doesnt run under linux no matter how much fiddling ive done)
Simagine using......(i have been adivised to not continue this sentance to avoid a controverisy)
Li mean i think eventually being able to have a linux ci run the bindings regeneration on request then open a PR would be sick
AAt that point you could buy a dedicated server or two and have it run bindings generation
Lalso me being able to work on BuildTools at all would also be cool
Ldw DNF pays for our CI
AWould probably do it at twice the speed
Anice
AIdk what ci is but nice