I didn't know about these Vortice repositories, perfect for using windows APIs in c# thanks, this wi
I didn't know about these Vortice repositories, perfect for using windows APIs in c# thanks, this will help me a lot
RJust 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
RHi 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!
Li 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
Pthere are examples of how to use our high level windowing API in the examples folder
Pthese examples also show you how to render basic 2D quads using OpenGL
ROk, got it. Then I will try with OpenGL. Thanks!
RI 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:
RHere it is
Loh i guess they got added
Lmust have been when our generator got fixed
RBTW anyone know what the hell happened with that
RAll of a sudden constants got added and
Rwas just fucking weird
Li think perskey was messing with the generator
Land it just generated a bunch more after a random tweak
RI know
RHe pinged me LMAO
RSaying now the constants I asked about for ASSIMP were generated
RAnd that he had no idea what he changed to do that
Pthis is still true
Pno fucking idea how
PI wasn’t even touching that part of the generator
Pand had entirely unrelated objectives
Pand suddenly… hello constants!
Li think you are just so good at programming that the sheer aura of your code scares other code into working
Pmore like the sheer stench
RLOL Silktouch needs a fresh coat of fire
Kworking on that 
unit test all the things
unit test all the things
AHi 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
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
P@alexx999_ can you open an issue and I'll look into this for the May update
Awell, 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
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
PIn fact if I remember correctly that’s the only way without reinventing the OpenCL converter and/or adding additional metadata
Pfrom what I remember the cl.xml was pretty crap
Pbut I do welcome your enthusiasm to contribute! It is truly appreciated and a rare occurrence for us 
Aactually 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
PNice! Thank you so much!
Pthen I’m guessing this’ll be the biggest improvement to our CL bindings in a while
P@kaijellinghaus look at that someone other than me can navigate the mess that is BuildTools!
KHonestly impressed
Ayeah, tbh I've started typing a message saying that "I can see why there's not too many contributions" 
Athat is, because no sane person would want to figure out that LINQ spaghetti
too bad that I love spaghetti... and LINQ...
too bad that I love spaghetti... and LINQ...
Athere'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
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
KYou 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
Aactually... I fixed entire stack so it's marked as obsolete in the output files even with correct "obsolete in" versions
AGitHub
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...
The initial motivation is that some of the enum types have to be ulong-based causing OpenCL API ca...
Athere you go
Athere's some room for improvement but I guess this should do as a starting point
Ait's always better to make small PRs
Phaha, the rest of silk.net isn't that bad and we do get contributions there
Pbut BuildTools is the darkest corner of the codebase