Just remember if silk.net does not have what you are looking for, you can branch out to other providers and while they may not have integrations or easy wrappers like silk.net has, they work
Hi guys, I'm new to Silk.NET, can anybody give me an advice on the following. I want to create a very simple cross platform desktop 2D app which is to draw 2D primitives: lines, points, rectangles, polygons, circles. Which is the simplest approach to develop such an app with Silk.NET? I've spent quite time trying to find documentation or examples but haven't find anything helpful. I've already learned that Silk.NET provides bindings for SDL, GLFW and brings an abstract layer over it, but I haven't found any example on how to use any of these. So I'm confused about what is the best approach for in my case. Should I use SDL or GLFW? Does Silk.NET provide some higher level API to draw 2D primitives or I need to work directly on SDL or GLFW level? Or maybe it would be simpler to use OpenGL and use it for rendering 2D primitives? Any advice or code example is greatly appreciated!
i dont think GLFW even has the ability to draw primitives, and our SDL bindings dont have any of the renderer functions, the only thing our SDL bindings are used for is windowing (and thats all our GLFW abstraction does too, it only creates/manages windows), you'll have to use OpenGL/VK/D3D for rendering
I see, thanks for the explanation! Though, I'm a bit surprised because I've discovered through intellisense some methods that really looks like rendering bindings:
Hi all, I've noticed that OpenCL bindings are pretty much broken due to the fact that some enums need to be 64 bit, which leads to methods such as i.e. clGetDeviceIDs being toast due to wrong argument size
I swooped in hoping for an easy fix but oh boy was this rabbit hole deep
well, I still plan to submit a PR an easy dirty fix would be to typemap particular types to ulong and the hard way is to group enums first and typemap to correct base enum
actually it's OK now aside from couple typos and oddities, in fact I've been able to get the enums "grouped", correctly marked as deprecated and correctly marked as having ulong base types
there's still some open questions, especially around that "extensions" separation (those are not shipped, right?) but I guess that can be left as-is for now
now I need to wrangle the typemap to point to the new enums and probably even try to fix those stupid tagged arg lists
You mentioned you marked the old enums as deprecated? That's probably unnecessary. If any code that used them was broken anyways its fine to just break
This should add some basic enum generation support for OpenCL aside from the umbrella CLEnum type. The initial motivation is that some of the enum types have to be ulong-based causing OpenCL API ca...